You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Kieran Kelleher <ki...@mac.com> on 2005/05/19 02:41:46 UTC
[HttpClient 3.0 RC2] executeMethod occasionly throws java.net.SocketException: Connection reset
Hi,
In brief, I get a SocketInputStream exception on
httpClient.executeMethod( postMethod ) intermittently and rarely, but
usually after connections to the host have been left idle for a few
minutes. My web application is using HttpClient library to process
multithreaded POST HTTPS requests to viaklix.com credit card service
provider. It seems the host is dropping the "keep-alive" connection
from the connection manager's pool so that that this exception is
thrown when the httpClient tries to use a connection that the
connection manager is trying to keep open.
Logging indicates that the method has isRequestSent=true and
hasBeenUsed=false and http status code is unset consistently after the
exception is thrown.
My short-term workaround (it works, but I don't longterm want to take
the chance of resending a credit card payment especially since
method.isRequestSent=true) is to use a retry handler on the method
since for the 1 in 50 times I have been able to reproduce the
exception, the cc service provider web application indicates that the
transaction was not processed. However rather than assuming that this
is going to always be the case, I really want to have some kind of
automatic stale connection checking done before my request is sent.
Googling the list archives and examination of the HttpClient docs seem
to indicate that the
httpClient.getHttpConnectionManager().getParams().isStaleCheckingEnabled
() being TRUE may not be effective for SSL connections.
Bottom line, is there anyway to have SSL connections checked reliably
by the connection manager (I'm using the
MultiThreadedHttpConnectionManager subclass) before it commits to
sending a request on a previously used SSL connection that it has in
its pool?
The exception stacktrace looks like this:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA12275)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
at
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:
77)
at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.jav
a:1110)
at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCon
nectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1391)
at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBa
se.java:1824)
at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
.java:1584)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
:995)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
thodDirector.java:393)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
dDirector.java:168)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
393)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
324)
at
ViaklixTransaction$TerminalTransactionProcess.run(ViaklixTransaction.jav
a:490)
at java.lang.Thread.run(Thread.java:552)
Regards, Kieran
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: [HttpClient 3.0 RC2] executeMethod occasionly throws java.net.SocketException: Connection reset
Posted by Kieran Kelleher <ki...@mac.com>.
Oleg,
I was afraid of that. Thanks for for your advice and for pointing out
that utility class ..... it saves me the time not having to write and
test my own.
Regards, Kieran
On May 19, 2005, at 10:05 AM, Oleg Kalnichevski wrote:
> Kieran,
>
> This problem is not uncommon. I know for a fact that the stale
> connection
> check does not work with older Sun JREs (< 1.4) when SSL is being used.
> I suspect the stale connection check is not always reliable with newer
> JREs as well.
>
> I am afraid the only alternative is to disable the stale connection
> check
> altogether and to run an eviction thread which drops idle connections
> after a specified period of inactivity
>
> http://jakarta.apache.org/commons/httpclient/3.0/apidocs/org/apache/
> commons/httpclient/util/IdleConnectionTimeoutThread.html
>
> Oleg
>
> On Wed, May 18, 2005 at 08:41:46PM -0400, Kieran Kelleher wrote:
>> Hi,
>>
>> In brief, I get a SocketInputStream exception on
>> httpClient.executeMethod( postMethod ) intermittently and rarely, but
>> usually after connections to the host have been left idle for a few
>> minutes. My web application is using HttpClient library to process
>> multithreaded POST HTTPS requests to viaklix.com credit card service
>> provider. It seems the host is dropping the "keep-alive" connection
>> from the connection manager's pool so that that this exception is
>> thrown when the httpClient tries to use a connection that the
>> connection manager is trying to keep open.
>>
>> Logging indicates that the method has isRequestSent=true and
>> hasBeenUsed=false and http status code is unset consistently after the
>> exception is thrown.
>>
>> My short-term workaround (it works, but I don't longterm want to take
>> the chance of resending a credit card payment especially since
>> method.isRequestSent=true) is to use a retry handler on the method
>> since for the 1 in 50 times I have been able to reproduce the
>> exception, the cc service provider web application indicates that the
>> transaction was not processed. However rather than assuming that this
>> is going to always be the case, I really want to have some kind of
>> automatic stale connection checking done before my request is sent.
>>
>> Googling the list archives and examination of the HttpClient docs seem
>> to indicate that the
>> httpClient.getHttpConnectionManager().getParams().isStaleCheckingEnabl
>> ed
>> () being TRUE may not be effective for SSL connections.
>>
>> Bottom line, is there anyway to have SSL connections checked reliably
>> by the connection manager (I'm using the
>> MultiThreadedHttpConnectionManager subclass) before it commits to
>> sending a request on a previously used SSL connection that it has in
>> its pool?
>>
>> The exception stacktrace looks like this:
>>
>> java.net.SocketException: Connection reset
>> at java.net.SocketInputStream.read(SocketInputStream.java:168)
>> at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275)
>> at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA12275)
>> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
>> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
>> at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA12275)
>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
>> at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
>> at
>> org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:
>> 77)
>> at
>> org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
>> at
>> org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.j
>> av
>> a:1110)
>> at
>> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpC
>> on
>> nectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1391)
>> at
>> org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethod
>> Ba
>> se.java:1824)
>> at
>> org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBa
>> se
>> .java:1584)
>> at
>> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.ja
>> va
>> :995)
>> at
>> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Http
>> Me
>> thodDirector.java:393)
>> at
>> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMet
>> ho
>> dDirector.java:168)
>> at
>> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java
>> :
>> 393)
>> at
>> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java
>> :
>> 324)
>> at
>> ViaklixTransaction$TerminalTransactionProcess.run(ViaklixTransaction.j
>> av
>> a:490)
>> at java.lang.Thread.run(Thread.java:552)
>>
>>
>> Regards, Kieran
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> httpclient-user-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpclient-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: [HttpClient 3.0 RC2] executeMethod occasionly throws java.net.SocketException: Connection reset
Posted by Oleg Kalnichevski <ol...@apache.org>.
Kieran,
This problem is not uncommon. I know for a fact that the stale connection
check does not work with older Sun JREs (< 1.4) when SSL is being used.
I suspect the stale connection check is not always reliable with newer
JREs as well.
I am afraid the only alternative is to disable the stale connection check
altogether and to run an eviction thread which drops idle connections
after a specified period of inactivity
http://jakarta.apache.org/commons/httpclient/3.0/apidocs/org/apache/commons/httpclient/util/IdleConnectionTimeoutThread.html
Oleg
On Wed, May 18, 2005 at 08:41:46PM -0400, Kieran Kelleher wrote:
> Hi,
>
> In brief, I get a SocketInputStream exception on
> httpClient.executeMethod( postMethod ) intermittently and rarely, but
> usually after connections to the host have been left idle for a few
> minutes. My web application is using HttpClient library to process
> multithreaded POST HTTPS requests to viaklix.com credit card service
> provider. It seems the host is dropping the "keep-alive" connection
> from the connection manager's pool so that that this exception is
> thrown when the httpClient tries to use a connection that the
> connection manager is trying to keep open.
>
> Logging indicates that the method has isRequestSent=true and
> hasBeenUsed=false and http status code is unset consistently after the
> exception is thrown.
>
> My short-term workaround (it works, but I don't longterm want to take
> the chance of resending a credit card payment especially since
> method.isRequestSent=true) is to use a retry handler on the method
> since for the 1 in 50 times I have been able to reproduce the
> exception, the cc service provider web application indicates that the
> transaction was not processed. However rather than assuming that this
> is going to always be the case, I really want to have some kind of
> automatic stale connection checking done before my request is sent.
>
> Googling the list archives and examination of the HttpClient docs seem
> to indicate that the
> httpClient.getHttpConnectionManager().getParams().isStaleCheckingEnabled
> () being TRUE may not be effective for SSL connections.
>
> Bottom line, is there anyway to have SSL connections checked reliably
> by the connection manager (I'm using the
> MultiThreadedHttpConnectionManager subclass) before it commits to
> sending a request on a previously used SSL connection that it has in
> its pool?
>
> The exception stacktrace looks like this:
>
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:168)
> at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275)
> at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA12275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
> at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA12275)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
> at
> org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:
> 77)
> at
> org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
> at
> org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.jav
> a:1110)
> at
> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpCon
> nectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1391)
> at
> org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBa
> se.java:1824)
> at
> org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
> .java:1584)
> at
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
> :995)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
> thodDirector.java:393)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
> dDirector.java:168)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 393)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 324)
> at
> ViaklixTransaction$TerminalTransactionProcess.run(ViaklixTransaction.jav
> a:490)
> at java.lang.Thread.run(Thread.java:552)
>
>
> Regards, Kieran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org