356
Views
0
Helpful
0
Comments
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 01-24-2014 03:58 PM
This document was generated from CDN thread
Created by: Gerard O'Rourke on 23-05-2012 10:26:49 AM
Hi,
I am wondering is anyone else has this issue and if there is any fix for it?
I am using the standard Database Action Element with a Microsoft SQL database.
version: CVP 7.0(2)
It all works fine for me ... except...
If you have not used the app for a while, the first call to it often gets the error below:
The root cause was: com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset by peer: socket write error.
I will attach full log.
It would appear that once the TCP connect is established all is OK, but on the initial establishment, it times out too quickly or some other issue occurs.
Its happened to me on mutiple servers and there are no network issues.
Any ideas on a workaround / fix for this issue?
Is it a Microsoft Java bug?
Regards,
Gerard
Subject: Re: New Message from Bill Webb in Customer Voice Portal (CVP) - General Dis
Replied by: Janine Graves on 23-05-2012 01:50:26 PM
Here's a trick if you don't know how to extend the db element.
Create a studio app named DB that you invoke using the subdialog invoke
element.
The DB app does a db select single. Something like select 1 from dual.
Exit back to your main app with subdialog return. Not cvp sub return. Just
subdialog return . Also create another subdialog return and right click to
make it an error element. This will catch db down errors and return to the
main app
In the main app., invoke the DB application to wake up the db connection at
the start of your call. Whether the db socket is fresh or stale the main app
won't be affected and will have a good connection after the subdialog invoke
returns.
Sent from a tiny keyboard and screen. Please excuse typos.
-----Original message-----
From: Cisco Developer Community Forums <cdicuser@developer.cisco.com>
To: "cdicuser@developer.cisco.com" <cdicuser@developer.cisco.com>
Sent: Wed, May 23, 2012 12:11:38 CDT
Subject: New Message from Bill Webb in Customer Voice Portal (CVP) - General
Discussion - All Versions: RE: CVP Database Elemenet - Connection reset by
peer: socket write error
Subject: RE: CVP Database Elemenet - Connection reset by peer: socket write error
Replied by: Bill Webb on 23-05-2012 01:11:38 PM
I've definitely seen this issue before, but I don't recall where the issue resided - SQL Server on Windows or something with Tomcat. The issue is basically that connections go stale - not like a socket rot, but just inactive and so I think the first attempt times out before the connection wakes back up.
Either way, the workaround I've used is a simple element that does a "test" connection and query prior to the Database element. Assuming you have a redundant server, then this can also handle failover gracefully.
It's probably a toss-up whether it is easier to do this or just create a complete new Database element that actually handles multiple connections and fail overs, but that's a fair amount more work.
- Bill
Subject: RE: CVP Database Elemenet - Connection reset by peer: socket write error
Replied by: Gerard O'Rourke on 25-05-2012 05:21:47 AM
Bill, Jainine,
Thank you for both of your responses.
Both were very helpful.
Bill using the standard DB element for a test connect prior to using the one i actually need would not work for me I think, as it would get a Java error on this socket failure,
so the app would abort.
At the moment I catch this error using the "on error" set in a CVP Subdialog Return.
But a custom DB would of course do the trick.
Jainine,
I really like your workaround. very clever and simple. This would allow me to use the standard DB element in a test CVP Studio script.
I am just upgrading from CVP 7.0 to CVP 8.0, and I have not got the issue todate with CVP 8.
But if I do, I will try your workaround. If I don't, it would appear the bug was in CVP 7 / Tomcat, which would make more sense, as this microsoft jar file would be used by a wide range of applications and it woudl be surprising if such an error was not found and corrected at this stage (I could be wrong!).
Gerard
Created by: Gerard O'Rourke on 23-05-2012 10:26:49 AM
Hi,
I am wondering is anyone else has this issue and if there is any fix for it?
I am using the standard Database Action Element with a Microsoft SQL database.
version: CVP 7.0(2)
It all works fine for me ... except...
If you have not used the app for a while, the first call to it often gets the error below:
The root cause was: com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset by peer: socket write error.
I will attach full log.
It would appear that once the TCP connect is established all is OK, but on the initial establishment, it times out too quickly or some other issue occurs.
Its happened to me on mutiple servers and there are no network issues.
Any ideas on a workaround / fix for this issue?
Is it a Microsoft Java bug?
Regards,
Gerard
Subject: Re: New Message from Bill Webb in Customer Voice Portal (CVP) - General Dis
Replied by: Janine Graves on 23-05-2012 01:50:26 PM
Here's a trick if you don't know how to extend the db element.
Create a studio app named DB that you invoke using the subdialog invoke
element.
The DB app does a db select single. Something like select 1 from dual.
Exit back to your main app with subdialog return. Not cvp sub return. Just
subdialog return . Also create another subdialog return and right click to
make it an error element. This will catch db down errors and return to the
main app
In the main app., invoke the DB application to wake up the db connection at
the start of your call. Whether the db socket is fresh or stale the main app
won't be affected and will have a good connection after the subdialog invoke
returns.
Sent from a tiny keyboard and screen. Please excuse typos.
-----Original message-----
From: Cisco Developer Community Forums <cdicuser@developer.cisco.com>
To: "cdicuser@developer.cisco.com" <cdicuser@developer.cisco.com>
Sent: Wed, May 23, 2012 12:11:38 CDT
Subject: New Message from Bill Webb in Customer Voice Portal (CVP) - General
Discussion - All Versions: RE: CVP Database Elemenet - Connection reset by
peer: socket write error
Subject: RE: CVP Database Elemenet - Connection reset by peer: socket write error
Replied by: Bill Webb on 23-05-2012 01:11:38 PM
I've definitely seen this issue before, but I don't recall where the issue resided - SQL Server on Windows or something with Tomcat. The issue is basically that connections go stale - not like a socket rot, but just inactive and so I think the first attempt times out before the connection wakes back up.
Either way, the workaround I've used is a simple element that does a "test" connection and query prior to the Database element. Assuming you have a redundant server, then this can also handle failover gracefully.
It's probably a toss-up whether it is easier to do this or just create a complete new Database element that actually handles multiple connections and fail overs, but that's a fair amount more work.
- Bill
Subject: RE: CVP Database Elemenet - Connection reset by peer: socket write error
Replied by: Gerard O'Rourke on 25-05-2012 05:21:47 AM
Bill, Jainine,
Thank you for both of your responses.
Both were very helpful.
Bill using the standard DB element for a test connect prior to using the one i actually need would not work for me I think, as it would get a Java error on this socket failure,
so the app would abort.
At the moment I catch this error using the "on error" set in a CVP Subdialog Return.
But a custom DB would of course do the trick.
Jainine,
I really like your workaround. very clever and simple. This would allow me to use the standard DB element in a test CVP Studio script.
I am just upgrading from CVP 7.0 to CVP 8.0, and I have not got the issue todate with CVP 8.
But if I do, I will try your workaround. If I don't, it would appear the bug was in CVP 7 / Tomcat, which would make more sense, as this microsoft jar file would be used by a wide range of applications and it woudl be surprising if such an error was not found and corrected at this stage (I could be wrong!).
Gerard
Labels:
