You might try a telnet, FTP, or some such request from the command line, and see if they also get reset after 15 minutes of no activity on the HP box.
I don't suppose it is possible for you to connect your application differently? For example, send in your requests, and the server responds immediately with an acknowledgement of the request received. On another connection, you can constantly reconnect a connection that waits 30-60s at most on the server to see if the activities have finished. Once an activity succeeds, return some indication on this connection of which activity finished. Then you can "call back" from your client application to get the results.
A little trickier that what you're doing, but not dramatically so. Perhaps you already thought of it, and were just wondering if there was a way to avoid the work? It would have the benefit that it could actually consistently and reliably through proxy servers and routers that might otherwise drop an idle connection.
-Eric Johnson.
David Webb wrote:
I have written a program that uses HttpClient to call servlets that do batch jobs and wait for their return...usually no more that 15 minutes. I have the Server timeout on the Web/App Server that the servlets reside on set to 1 hour or 3600 seconds. I have tested this in 2 environments using HttpClient to call the Servlets that are in the same environment.
1) Windows 2K / JDK1.4.X - Works Fine, calls servlet, receives return code 8-9 minutes later and exits without error
2) HP-UX / JDK1.4.X - Runs for about 15 minutes then throws the following exception:
Exception thrown: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:182) at org.apache.commons.httpclient.HttpConnection$WrappedInputStream.read (HttpConnection.java:1377) at java.io.FilterInputStream.read(FilterInputStream.java:66) at java.io.PushbackInputStream.read(PushbackInputStream.java:120) at org.apache.commons.httpclient.HttpParser.readRawLine (HttpParser.java:109) at org.apache.commons.httpclient.HttpParser.readLine (HttpParser.java:135) at org.apache.commons.httpclient.HttpConnection.readLine (HttpConnection.java:1037) at org.apache.commons.httpclient.HttpMethodBase.readStatusLine (HttpMethodBase.java:1842) at org.apache.commons.httpclient.HttpMethodBase.readResponse (HttpMethodBase.java:1611) at org.apache.commons.httpclient.HttpMethodBase.execute (HttpMethodBase.java:997) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry (HttpMethodDirector.java:316) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod (HttpMethodDirector.java:172) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:468) at org.apache.commons.httpclient.HttpClient.executeMethod (HttpClient.java:355) at com.bac.amg.acs.HTTPBatch.execute(HTTPBatch.java:157) at com.bac.amg.acs.HTTPBatch.main(HTTPBatch.java:75)
Is there anything I can do in HttpClient to prevent this from happening?
Thanks.
-- Sincerely, David Webb Vice-President Hurff-Webb, Inc. http://www.hurff-webb.com (904) 861-2366 (904) 534-8294 Mobile
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
