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 "Mark A. Claassen" <MC...@ocie.net> on 2015/05/08 22:49:08 UTC
Strange SSL error
We are having one user that is getting this sporadically. No one else can reproduce it. Any idea what might be causing it? Because it is hard to reproduce, I am having trouble knowing where to start? Everyone else who tries has no issues. He logs into our application, which involves lots of small network transactions, and then the next thing he does often causes this. I think the situation would be that there is a lot of transactions very quickly, then a slight delay. After this, the next transaction fails, and then it will be fine. Any ideas?
---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
Message (portal.cpfs.com:443 failed to respond)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
Re: Strange SSL error
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi,
I confirm there seem to be a bug in this field as per :
- https://bz.apache.org/bugzilla/show_bug.cgi?id=57921
Regards
On Wed, May 13, 2015 at 10:58 PM, Mark A. Claassen <MC...@ocie.net>
wrote:
> The 4.4.1 code doesn't seem to help.
>
> I have been able to reproduce the issue more regularly now. It seems to
> have to do with keep-alives and if the client takes longer to read the
> message than the keep alive value.
>
> In my test case I open the connection, read all the data, sleep for a
> while, then close the connection.
> If my sleep is a bit longer than the keep-alive value, I will get a
> org.apache.http.NoHttpResponseException. If my sleep value is larger, I
> will get a java.net.SocketException.
> (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a
> NoHttpResponseException. If I sleep for 11000, I will get a
> SocketException.
>
> If I use the NoConnectionReuseStrategy, the problem goes away.
>
> Is something set up for my keep alives? I put some breakpoints in
> CPool.java. I can see connections being created, but the validate() method
> of CPool is never getting called.
>
> I am curious this part of AbstractConnPool.java. This seems like if the
> server invalidated a connection early, the validate check would never
> happen.
>
> } else if (this.validateAfterInactivity > 0) {
> if (entry.getUpdated() +
> this.validateAfterInactivity <= System.currentTimeMillis()) {
> if (!validate(entry)) {
> entry.close();
> }
> }
> }
> Scenario:
> Server sends data.
> Client reads packet, processes it for 6 seconds
> Server senses that inactivity for 5 seconds, closes connection
> Client closes connection and places entry back in the pool
> Connection immediately leased to another thread
> Time between release and close is almost nothing
> Pool releases stale connection.
>
>
>
> ---- (1) ---- Throwable - Class (class java.net.SocketException)
> Message (Software caused connection abort: socket write error)
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
> at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
> at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
> at
> sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:864)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:835)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> at
> org.apache.http.impl.conn.LoggingOutputStream.write(LoggingOutputStream.java:77)
> at
> org.apache.http.impl.io.SessionOutputBufferImpl.streamWrite(SessionOutputBufferImpl.java:126)
> at
> org.apache.http.impl.io.SessionOutputBufferImpl.flushBuffer(SessionOutputBufferImpl.java:138)
> at
> org.apache.http.impl.io.SessionOutputBufferImpl.flush(SessionOutputBufferImpl.java:146)
>
>
> ---- (1) ---- Throwable - Class (class
> org.apache.http.NoHttpResponseException)
> Message (The target server failed to respond)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>
>
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) named in this message. This communication is
> intended to be and to remain confidential. If you are not the intended
> recipient of this message, or if this message has been addressed to you in
> error, please immediately alert the sender by reply e-mail and then delete
> this message and its attachments. Do not deliver, distribute, copy,
> disclose the contents or take any action in reliance upon the information
> contained in the communication or any attachments.
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Wednesday, May 13, 2015 3:25 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Tue, 2015-05-12 at 20:28 +0000, Mark A. Claassen wrote:
> > I was looking at the change log for 4.4 and 4.4.1. Count
> HTTPCLIENT-1609 be causing this?
>
> The issue was about detection of half-closed connections. If
> NoHttpResponseException you have been seeing is a result of the connection
> getting closed by the opposite endpoint, upgrading to 4.4.1
> might help resolve the issue.
>
> Oleg
>
> > Or does it have to be something on the network closing the connection?
> >
> > * [HTTPCLIENT-1609] Stale connection check in
> PoolingHttpClientConnectionManager has no effect.
> > Internal connection pool does not correctly implement connection
> validation.
> > Contributed by Charles Lip <rene1 at singnet.com.sg>
> >
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) named in this message. This communication is
> intended to be and to remain confidential. If you are not the intended
> recipient of this message, or if this message has been addressed to you in
> error, please immediately alert the sender by reply e-mail and then delete
> this message and its attachments. Do not deliver, distribute, copy,
> disclose the contents or take any action in reliance upon the information
> contained in the communication or any attachments.
> >
> >
> > -----Original Message-----
> > From: Mark A. Claassen [mailto:MClaassen@ocie.net]
> > Sent: Tuesday, May 12, 2015 8:58 AM
> > To: HttpClient User Discussion
> > Subject: RE: Strange SSL error
> >
> > The scenario is that he logs in to our Swing application, there is a
> burst of transactions, maybe a slight pause, and then the next one fails.
> The whole process probably takes around 10 seconds. I was actually
> wondering if this had something to do with bad connections in the pool, but
> it is hard to say since I can't reproduce it reliably.
> >
> > The communication is over SSL, and consists of readable XML and binary
> data. Most of the messages are < 10K, some bigger. We checked the
> firewall wall logs (since there is a firewall involved) and there is
> nothing. I connect through the same route and this never happens to me.
> >
> > Thanks again,
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) named in this message. This communication is
> intended to be and to remain confidential. If you are not the intended
> recipient of this message, or if this message has been addressed to you in
> error, please immediately alert the sender by reply e-mail and then delete
> this message and its attachments. Do not deliver, distribute, copy,
> disclose the contents or take any action in reliance upon the information
> contained in the communication or any attachments.
> >
> > -----Original Message-----
> > From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> > Sent: Monday, May 11, 2015 5:15 PM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > What kind of data is being transfered? Do you tend to keep connections
> open for a long time? Firewall killing connections?
> >
> > Sendt fra min iPhone
> >
> > > Den 11. mai 2015 kl. 21.36 skrev Mark A. Claassen <MClaassen@ocie.net
> >:
> > >
> > > What would cause the reset, and what would make it so seemingly
> random? Is there something I am doing wrong? Is there a setting I can set
> so that this doesn't randomly happen to him? It is not too often, but
> often enough to be annoying and look like a failure in the application.
> > >
> > > Thanks
> > >
> > > Mark Claassen
> > > Senior Software Engineer
> > >
> > > Donnell Systems, Inc.
> > > 130 South Main Street
> > > Leighton Plaza Suite 375
> > > South Bend, IN 46601
> > > E-mail: mailto:mclaassen@ocie.net
> > > Voice: (574)232-3784
> > > Fax: (574)232-4014
> > >
> > >
> > > -----Original Message-----
> > > From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> > > Sent: Friday, May 08, 2015 5:20 PM
> > > To: HttpClient User Discussion
> > > Subject: Re: Strange SSL error
> > >
> > > Looks like a tcp reset to me
> > >
> > > Sendt fra min iPhone
> > >
> > >> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MClaassen@ocie.net
> >:
> > >>
> > >> We are having one user that is getting this sporadically. No one
> else can reproduce it. Any idea what might be causing it? Because it is
> hard to reproduce, I am having trouble knowing where to start? Everyone
> else who tries has no issues. He logs into our application, which involves
> lots of small network transactions, and then the next thing he does often
> causes this. I think the situation would be that there is a lot of
> transactions very quickly, then a slight delay. After this, the next
> transaction fails, and then it will be fine. Any ideas?
> > >>
> > >>
> > >> ---- (1) ---- Throwable - Class (class
> org.apache.http.NoHttpResponseException)
> > >> Message (portal.cpfs.com:443 failed to respond)
> > >> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> > >> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> > >> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> > >> at
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> > >> at
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> > >> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> > >> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> > >> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> > >> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> > >> at
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> > >> at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> > >> at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> > >> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> > >> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> > >> at
> > >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt
> > >> tpClient.java:55)
> > >> Mark Claassen
> > >> Senior Software Engineer
> > >>
> > >> Donnell Systems, Inc.
> > >> 130 South Main Street
> > >> Leighton Plaza Suite 375
> > >> South Bend, IN 46601
> > >> E-mail: mailto:mclaassen@ocie.net
> > >> Voice: (574)232-3784
> > >> Fax: (574)232-4014
> > >>
> > >> -------------------------------------------
> > >> Confidentiality Notice: OCIESERVICE
> > >> -------------------------------------------
> > >> The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) named in this message. This communication is
> intended to be and to remain confidential. If you are not the intended
> recipient of this message, or if this message has been addressed to you in
> error, please immediately alert the sender by reply e-mail and then delete
> this message and its attachments. Do not deliver, distribute, copy,
> disclose the contents or take any action in reliance upon the information
> contained in the communication or any attachments.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> > B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > KCB [ X ܚX K K[XZ[
> > Y[
> > ]\ \ ][ X ܚX P ˘\ X K ܙ B ܈ Y ] [ۘ[ [X[ K[XZ[
> > Y[
> > ]\ \ Z [ ˘\ X K ܙ B B
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
--
Cordialement.
Philippe Mouawad.
Re: Strange SSL error
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2015-06-26 at 18:07 +0000, Mark A. Claassen wrote:
> This is from a pretty old thread, but I was called away for a bit.
>
> > With chunk coded content the end of stream should be generated when the closing chunk has been read. It looks like your application either does not read the closing chunk for some reason or something is still amiss.
>
> I know the size of the transmission before it goes on the socket, but not soon enough to put it in the Http header. So, I know the exact number of bytes and read exactly that many. Looking at the EOFSensorInputStream, it looks like it may be helpful for me to call read() one extra time so that the read() on the input stream returns a -1 at some point.
>
> Would this be advisable? Or is it ok for me to read just the exact number of bytes I know are there and then close my stream (without read ever returning -1)
>
It would. Generally I would consider reading to the end of message
content stream a good practice.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
This is from a pretty old thread, but I was called away for a bit.
> With chunk coded content the end of stream should be generated when the closing chunk has been read. It looks like your application either does not read the closing chunk for some reason or something is still amiss.
I know the size of the transmission before it goes on the socket, but not soon enough to put it in the Http header. So, I know the exact number of bytes and read exactly that many. Looking at the EOFSensorInputStream, it looks like it may be helpful for me to call read() one extra time so that the read() on the input stream returns a -1 at some point.
Would this be advisable? Or is it ok for me to read just the exact number of bytes I know are there and then close my stream (without read ever returning -1)
Mark
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Thursday, May 21, 2015 6:00 AM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
On Wed, 2015-05-20 at 18:40 +0000, Mark A. Claassen wrote:
> Got it. streamClosed in org.apache.http.impl.execchain.ResponseEntityProxy has this :
> // this assumes that closing the stream will
> // consume the remainder of the response body:
> try {
> wrapped.close();
> releaseConnection();
> }
> Wrapped is a ChunkedInputStream
> org.apache.http.impl.io.ChunkedInputStream does this to read the rest of the message:
> while (read(buff) >= 0) {
> }
>
> So, when I close the connection, the library makes sure that the connection is ready for reuse regardless. And, since the stream is already fully read, this does not cause any real activity on the socket.
>
Mark,
Please note that ResponseEntityProxy#eofDetected also triggers connection release. With chunk coded content the end of stream should be generated when the closing chunk has been read. It looks like your application either does not read the closing chunk for some reason or something is still amiss.
> Events:
> 1) Complete data is read
> 2) [Processing happens here for a length of time]
> 3) InputStream is closed explicitly by the program:
> Closes the HttpConnection
> Reads any unread data (which there is none)
> Resets "updated" to time of close
> Puts connection back in the pool.
> The expiration time will now be calculated using the step 3 time, but
> the server started counting right after step 1
>
> I certainly believe that, in general, step 2 should not take a lot of
> time. (And if it does, maybe make sure the connection is closed first.) The only reason I noticed this is because my test case had a sleep(6000) right after it read the data. Still, it seems the logic isn't quite correct; "updated" should be when the last byte was read, not when it was put back in the pool. Whether or not it is worth changing/fixing is a whole different question.
>
Generally, as long as the consumer always reads to the end of the message, the underlying connection should get released at the same time with the receipt of the last data chunk and the expiry time on the client side value should be fairly accurate. What can be done though is that when calculating expiry time the connection manager is to use the time of the last read operation instead of the time of connection release. Feel free to raise an enhancement request for that.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2015-05-20 at 18:40 +0000, Mark A. Claassen wrote:
> Got it. streamClosed in org.apache.http.impl.execchain.ResponseEntityProxy has this :
> // this assumes that closing the stream will
> // consume the remainder of the response body:
> try {
> wrapped.close();
> releaseConnection();
> }
> Wrapped is a ChunkedInputStream
> org.apache.http.impl.io.ChunkedInputStream does this to read the rest of the message:
> while (read(buff) >= 0) {
> }
>
> So, when I close the connection, the library makes sure that the connection is ready for reuse regardless. And, since the stream is already fully read, this does not cause any real activity on the socket.
>
Mark,
Please note that ResponseEntityProxy#eofDetected also triggers
connection release. With chunk coded content the end of stream should be
generated when the closing chunk has been read. It looks like your
application either does not read the closing chunk for some reason or
something is still amiss.
> Events:
> 1) Complete data is read
> 2) [Processing happens here for a length of time]
> 3) InputStream is closed explicitly by the program:
> Closes the HttpConnection
> Reads any unread data (which there is none)
> Resets "updated" to time of close
> Puts connection back in the pool.
> The expiration time will now be calculated using the step 3 time, but the server started counting right after step 1
>
> I certainly believe that, in general, step 2 should not take a lot of time. (And if it does, maybe make sure the connection is closed first.)
> The only reason I noticed this is because my test case had a sleep(6000) right after it read the data. Still, it seems the logic isn't quite correct; "updated" should be when the last byte was read, not when it was put back in the pool. Whether or not it is worth changing/fixing is a whole different question.
>
Generally, as long as the consumer always reads to the end of the
message, the underlying connection should get released at the same time
with the receipt of the last data chunk and the expiry time on the
client side value should be fairly accurate. What can be done though is
that when calculating expiry time the connection manager is to use the
time of the last read operation instead of the time of connection
release. Feel free to raise an enhancement request for that.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
Got it. streamClosed in org.apache.http.impl.execchain.ResponseEntityProxy has this :
// this assumes that closing the stream will
// consume the remainder of the response body:
try {
wrapped.close();
releaseConnection();
}
Wrapped is a ChunkedInputStream
org.apache.http.impl.io.ChunkedInputStream does this to read the rest of the message:
while (read(buff) >= 0) {
}
So, when I close the connection, the library makes sure that the connection is ready for reuse regardless. And, since the stream is already fully read, this does not cause any real activity on the socket.
Events:
1) Complete data is read
2) [Processing happens here for a length of time]
3) InputStream is closed explicitly by the program:
Closes the HttpConnection
Reads any unread data (which there is none)
Resets "updated" to time of close
Puts connection back in the pool.
The expiration time will now be calculated using the step 3 time, but the server started counting right after step 1
I certainly believe that, in general, step 2 should not take a lot of time. (And if it does, maybe make sure the connection is closed first.)
The only reason I noticed this is because my test case had a sleep(6000) right after it read the data. Still, it seems the logic isn't quite correct; "updated" should be when the last byte was read, not when it was put back in the pool. Whether or not it is worth changing/fixing is a whole different question.
Thanks,
Mark
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-----Original Message-----
From: Mark A. Claassen [mailto:MClaassen@ocie.net]
Sent: Wednesday, May 20, 2015 2:04 PM
To: HttpClient User Discussion
Subject: RE: Strange SSL error
> This does not seem to add up. HttpClient keeps connections alive only if it is sure the last message has been fully consumed. Otherwise it drops the connection as non-reusable.
Well, the connections are certainly being reused. Guess I need to investigate what exactly is happening.
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Wednesday, May 20, 2015 11:26 AM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
On Wed, 2015-05-20 at 14:53 +0000, Mark A. Claassen wrote:
> (3) or whenever message content is fully consumed.
> > response closure but at as soon as the content stream returns -1
>
> Nice. I never thought to check that. Unfortunately, this wasn't happening in my test case. We have our own message structure where we know how long the response is going to be and so never read past the end (getting the -1). However, because we don't know the length immediately, we can't put it in the content length header. I would imagine that this doesn't give HttpClient a chance to detect the EOF condition.
>
This does not seem to add up. HttpClient keeps connections alive only if it is sure the last message has been fully consumed. Otherwise it drops the connection as non-reusable.
Oleg
> I believe I am using the library "correctly", but I guess I found a condition use case that corrupts the pool a bit. Is this something that can be considered for a future version, or is this one of those things where making a slight change would cause a lot of complications?
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
>
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Wednesday, May 20, 2015 9:41 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Wed, 2015-05-20 at 13:30 +0000, Mark A. Claassen wrote:
> > > 'updated' represents the time of the last update on the client
> > side as opposed to 'expiry' which represents keep-alive period
> >
> > Maybe, but the expire time is then set based on the new value of "updated". So, even though no network activity occurred, the new expiration time is set as if there was.
> > The impact of this is that, after reading a response from the server, any processing time that is done between the reading of the data and the releasing of the connection is ignored.
>
> You see, the connection release is triggered whenever either of these events take place.
>
> (1) request is aborted
> (2) response is closed
> (3) or whenever message content is fully consumed.
>
> So, in the normal course of request execution the expiry time gets updated not at the time of response closure but at as soon as the content stream returns -1 (end of stream). That is, pretty much at the same time as the keep-alive timer starts ticking at the server side.
>
> Oleg
>
>
>
> > If the KeepAlive duration is 5 seconds, but some code takes 6 seconds to process the results, an expired entry will be placed back into the pool. This might not be a big deal, but it defeats the purpose of the check. It will also force a stale connection check on a connection that is known to be expired.
> >
> > This is assuming the pattern of:
> > Open Connection
> > try {
> > Send request
> > Read response
> > Do some initial processing of the response
> > }
> > finally {
> > Close connection
> > }
> >
> > Perhaps the "newExpiry" should be calculated before the "updated" is set to the current time?
> >
> > public synchronized void updateExpiry(final long time, final TimeUnit tunit) {
> > Args.notNull(tunit, "Time unit");
> > this.updated = System.currentTimeMillis();
> > final long newExpiry;
> > if (time > 0) {
> > newExpiry = this.updated + tunit.toMillis(time);
> > } else {
> > newExpiry = Long.MAX_VALUE;
> > }
> > this.expiry = Math.min(newExpiry, this.validityDeadline);
> > }
> >
> >
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> >
> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > Sent: Tuesday, May 19, 2015 4:26 AM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > On Fri, 2015-05-15 at 16:08 +0000, Mark A. Claassen wrote:
> > > Thanks. However, I am still getting the error; even when I do:
> > > connectionManager.setValidateAfterInactivity(1);
> > >
> > > I think this is just because the server can close a keepalive
> > > connection at any time. So, if the server decides to kill off the
> > > connection in that time slice, the request fails. This most often
> > > comes back as a org.apache.http.NoHttpResponseException which the
> > > default retry handler will not retry. It seems the only way I can
> > > be sure than my connections succeed is to disable keep-alives
> > > entirely with a ConnectionReuseStrategy. (Also, Using
> > > RequestConfig.setStaleConnectionCheckEnabled(true) seems works
> > > better than the setting the setValidateAfterInactivity to 1. I am
> > > not sure
> > > why.)
> > >
> > > Question:
> > > releaseConnection in PoolingHttpClientConnectionManager calls updateExpiry in PoolEntry. However, this method in PoolEntry also sets the "updated" time. What is "updated" supposed to represent? If it is mainly used to test the keepalive stuff, then it should be updated based on network activity. It doesn’t seem that changing a time to expire value should be counted as "activity" on the connection.
> > >
> > >
> >
> > 'updated' represents the time of the last update on the client side as opposed to 'expiry' which represents keep-alive period as communicated by the server. One might want to close connections after, say, 3 seconds of inactivity on client side even though the server's keep-alive is, say, 5 seconds.
> >
> > Oleg
> >
> > >
> > > Mark Claassen
> > > Senior Software Engineer
> > >
> > > Donnell Systems, Inc.
> > > 130 South Main Street
> > > Leighton Plaza Suite 375
> > > South Bend, IN 46601
> > > E-mail: mailto:mclaassen@ocie.net
> > > Voice: (574)232-3784
> > > Fax: (574)232-4014
> > >
> > > -------------------------------------------
> > > Confidentiality Notice: OCIESERVICE
> > > -------------------------------------------
> > > The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> > >
> > >
> > > -----Original Message-----
> > > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > > Sent: Thursday, May 14, 2015 4:38 AM
> > > To: HttpClient User Discussion
> > > Subject: Re: Strange SSL error
> > >
> > > On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> > > > The 4.4.1 code doesn't seem to help.
> > > >
> > > > I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
> > > >
> > >
> > > Hi Mark
> > >
> > > Then, it is all very simple. There are several ways to make HttpClient either discard potentially half-closed connections, test them for 'staleness' or automatically recover from NoHttpResponseException.
> > >
> > >
> > > > In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> > > > If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> > > > (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
> > > >
> > >
> > > The default maximum inactivity period used by the pooling
> > > connection manager is exactly 5000 ms. Please try reducing this
> > > value to, say,
> > > 2000 ms
> > >
> > > ---
> > > PoolingHttpClientConnectionManager cm = new
> > > PoolingHttpClientConnectionManager();
> > > cm.setValidateAfterInactivity(2000);
> > >
> > > CloseableHttpClient client = HttpClients.custom()
> > > .setConnectionManager(cm)
> > > .build();
> > > ---
> > >
> > > This should make the problem go away.
> > >
> > > > If I use the NoConnectionReuseStrategy, the problem goes away.
> > > >
> > > > Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
> > > >
> > > > I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
> > > >
> > > > } else if (this.validateAfterInactivity > 0) {
> > > > if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> > > > if (!validate(entry)) {
> > > > entry.close();
> > > > }
> > > > }
> > > > }
> > > > Scenario:
> > > > Server sends data.
> > > > Client reads packet, processes it for 6 seconds
> > > > Server senses that inactivity for 5 seconds, closes connection
> > > > Client closes connection and places entry back in the pool
> > > > Connection immediately leased to another thread
> > > > Time between release and close is almost nothing
> > > > Pool releases stale connection.
> > > >
> > >
> > > You can force TTL (total time to live) for connections to avoid
> > > this problem
> > >
> > > ---
> > > PoolingHttpClientConnectionManager cm = new
> > > PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS);
> > > cm.setValidateAfterInactivity(1000);
> > >
> > > CloseableHttpClient client = HttpClients.custom()
> > > .setConnectionManager(cm)
> > > .build();
> > > ---
> > >
> > > Hope this helps
> > >
> > > Oleg
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail:
> > > httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail:
> > > httpclient-users-help@hc.apache.org
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail:
> > > httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail:
> > > httpclient-users-help@hc.apache.org
> > >
> >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
> This does not seem to add up. HttpClient keeps connections alive only if it is sure the last message has been fully consumed. Otherwise it drops the connection as non-reusable.
Well, the connections are certainly being reused. Guess I need to investigate what exactly is happening.
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Wednesday, May 20, 2015 11:26 AM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
On Wed, 2015-05-20 at 14:53 +0000, Mark A. Claassen wrote:
> (3) or whenever message content is fully consumed.
> > response closure but at as soon as the content stream returns -1
>
> Nice. I never thought to check that. Unfortunately, this wasn't happening in my test case. We have our own message structure where we know how long the response is going to be and so never read past the end (getting the -1). However, because we don't know the length immediately, we can't put it in the content length header. I would imagine that this doesn't give HttpClient a chance to detect the EOF condition.
>
This does not seem to add up. HttpClient keeps connections alive only if it is sure the last message has been fully consumed. Otherwise it drops the connection as non-reusable.
Oleg
> I believe I am using the library "correctly", but I guess I found a condition use case that corrupts the pool a bit. Is this something that can be considered for a future version, or is this one of those things where making a slight change would cause a lot of complications?
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
>
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Wednesday, May 20, 2015 9:41 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Wed, 2015-05-20 at 13:30 +0000, Mark A. Claassen wrote:
> > > 'updated' represents the time of the last update on the client
> > side as opposed to 'expiry' which represents keep-alive period
> >
> > Maybe, but the expire time is then set based on the new value of "updated". So, even though no network activity occurred, the new expiration time is set as if there was.
> > The impact of this is that, after reading a response from the server, any processing time that is done between the reading of the data and the releasing of the connection is ignored.
>
> You see, the connection release is triggered whenever either of these events take place.
>
> (1) request is aborted
> (2) response is closed
> (3) or whenever message content is fully consumed.
>
> So, in the normal course of request execution the expiry time gets updated not at the time of response closure but at as soon as the content stream returns -1 (end of stream). That is, pretty much at the same time as the keep-alive timer starts ticking at the server side.
>
> Oleg
>
>
>
> > If the KeepAlive duration is 5 seconds, but some code takes 6 seconds to process the results, an expired entry will be placed back into the pool. This might not be a big deal, but it defeats the purpose of the check. It will also force a stale connection check on a connection that is known to be expired.
> >
> > This is assuming the pattern of:
> > Open Connection
> > try {
> > Send request
> > Read response
> > Do some initial processing of the response
> > }
> > finally {
> > Close connection
> > }
> >
> > Perhaps the "newExpiry" should be calculated before the "updated" is set to the current time?
> >
> > public synchronized void updateExpiry(final long time, final TimeUnit tunit) {
> > Args.notNull(tunit, "Time unit");
> > this.updated = System.currentTimeMillis();
> > final long newExpiry;
> > if (time > 0) {
> > newExpiry = this.updated + tunit.toMillis(time);
> > } else {
> > newExpiry = Long.MAX_VALUE;
> > }
> > this.expiry = Math.min(newExpiry, this.validityDeadline);
> > }
> >
> >
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> >
> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > Sent: Tuesday, May 19, 2015 4:26 AM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > On Fri, 2015-05-15 at 16:08 +0000, Mark A. Claassen wrote:
> > > Thanks. However, I am still getting the error; even when I do:
> > > connectionManager.setValidateAfterInactivity(1);
> > >
> > > I think this is just because the server can close a keepalive
> > > connection at any time. So, if the server decides to kill off the
> > > connection in that time slice, the request fails. This most often
> > > comes back as a org.apache.http.NoHttpResponseException which the
> > > default retry handler will not retry. It seems the only way I can
> > > be sure than my connections succeed is to disable keep-alives
> > > entirely with a ConnectionReuseStrategy. (Also, Using
> > > RequestConfig.setStaleConnectionCheckEnabled(true) seems works
> > > better than the setting the setValidateAfterInactivity to 1. I am
> > > not sure
> > > why.)
> > >
> > > Question:
> > > releaseConnection in PoolingHttpClientConnectionManager calls updateExpiry in PoolEntry. However, this method in PoolEntry also sets the "updated" time. What is "updated" supposed to represent? If it is mainly used to test the keepalive stuff, then it should be updated based on network activity. It doesn’t seem that changing a time to expire value should be counted as "activity" on the connection.
> > >
> > >
> >
> > 'updated' represents the time of the last update on the client side as opposed to 'expiry' which represents keep-alive period as communicated by the server. One might want to close connections after, say, 3 seconds of inactivity on client side even though the server's keep-alive is, say, 5 seconds.
> >
> > Oleg
> >
> > >
> > > Mark Claassen
> > > Senior Software Engineer
> > >
> > > Donnell Systems, Inc.
> > > 130 South Main Street
> > > Leighton Plaza Suite 375
> > > South Bend, IN 46601
> > > E-mail: mailto:mclaassen@ocie.net
> > > Voice: (574)232-3784
> > > Fax: (574)232-4014
> > >
> > > -------------------------------------------
> > > Confidentiality Notice: OCIESERVICE
> > > -------------------------------------------
> > > The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> > >
> > >
> > > -----Original Message-----
> > > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > > Sent: Thursday, May 14, 2015 4:38 AM
> > > To: HttpClient User Discussion
> > > Subject: Re: Strange SSL error
> > >
> > > On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> > > > The 4.4.1 code doesn't seem to help.
> > > >
> > > > I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
> > > >
> > >
> > > Hi Mark
> > >
> > > Then, it is all very simple. There are several ways to make HttpClient either discard potentially half-closed connections, test them for 'staleness' or automatically recover from NoHttpResponseException.
> > >
> > >
> > > > In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> > > > If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> > > > (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
> > > >
> > >
> > > The default maximum inactivity period used by the pooling
> > > connection manager is exactly 5000 ms. Please try reducing this
> > > value to, say,
> > > 2000 ms
> > >
> > > ---
> > > PoolingHttpClientConnectionManager cm = new
> > > PoolingHttpClientConnectionManager();
> > > cm.setValidateAfterInactivity(2000);
> > >
> > > CloseableHttpClient client = HttpClients.custom()
> > > .setConnectionManager(cm)
> > > .build();
> > > ---
> > >
> > > This should make the problem go away.
> > >
> > > > If I use the NoConnectionReuseStrategy, the problem goes away.
> > > >
> > > > Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
> > > >
> > > > I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
> > > >
> > > > } else if (this.validateAfterInactivity > 0) {
> > > > if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> > > > if (!validate(entry)) {
> > > > entry.close();
> > > > }
> > > > }
> > > > }
> > > > Scenario:
> > > > Server sends data.
> > > > Client reads packet, processes it for 6 seconds
> > > > Server senses that inactivity for 5 seconds, closes connection
> > > > Client closes connection and places entry back in the pool
> > > > Connection immediately leased to another thread
> > > > Time between release and close is almost nothing
> > > > Pool releases stale connection.
> > > >
> > >
> > > You can force TTL (total time to live) for connections to avoid
> > > this problem
> > >
> > > ---
> > > PoolingHttpClientConnectionManager cm = new
> > > PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS);
> > > cm.setValidateAfterInactivity(1000);
> > >
> > > CloseableHttpClient client = HttpClients.custom()
> > > .setConnectionManager(cm)
> > > .build();
> > > ---
> > >
> > > Hope this helps
> > >
> > > Oleg
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail:
> > > httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail:
> > > httpclient-users-help@hc.apache.org
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail:
> > > httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail:
> > > httpclient-users-help@hc.apache.org
> > >
> >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2015-05-20 at 14:53 +0000, Mark A. Claassen wrote:
> (3) or whenever message content is fully consumed.
> > response closure but at as soon as the content stream returns -1
>
> Nice. I never thought to check that. Unfortunately, this wasn't happening in my test case. We have our own message structure where we know how long the response is going to be and so never read past the end (getting the -1). However, because we don't know the length immediately, we can't put it in the content length header. I would imagine that this doesn't give HttpClient a chance to detect the EOF condition.
>
This does not seem to add up. HttpClient keeps connections alive only if
it is sure the last message has been fully consumed. Otherwise it drops
the connection as non-reusable.
Oleg
> I believe I am using the library "correctly", but I guess I found a condition use case that corrupts the pool a bit. Is this something that can be considered for a future version, or is this one of those things where making a slight change would cause a lot of complications?
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
>
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Wednesday, May 20, 2015 9:41 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Wed, 2015-05-20 at 13:30 +0000, Mark A. Claassen wrote:
> > > 'updated' represents the time of the last update on the client
> > side as opposed to 'expiry' which represents keep-alive period
> >
> > Maybe, but the expire time is then set based on the new value of "updated". So, even though no network activity occurred, the new expiration time is set as if there was.
> > The impact of this is that, after reading a response from the server, any processing time that is done between the reading of the data and the releasing of the connection is ignored.
>
> You see, the connection release is triggered whenever either of these events take place.
>
> (1) request is aborted
> (2) response is closed
> (3) or whenever message content is fully consumed.
>
> So, in the normal course of request execution the expiry time gets updated not at the time of response closure but at as soon as the content stream returns -1 (end of stream). That is, pretty much at the same time as the keep-alive timer starts ticking at the server side.
>
> Oleg
>
>
>
> > If the KeepAlive duration is 5 seconds, but some code takes 6 seconds to process the results, an expired entry will be placed back into the pool. This might not be a big deal, but it defeats the purpose of the check. It will also force a stale connection check on a connection that is known to be expired.
> >
> > This is assuming the pattern of:
> > Open Connection
> > try {
> > Send request
> > Read response
> > Do some initial processing of the response
> > }
> > finally {
> > Close connection
> > }
> >
> > Perhaps the "newExpiry" should be calculated before the "updated" is set to the current time?
> >
> > public synchronized void updateExpiry(final long time, final TimeUnit tunit) {
> > Args.notNull(tunit, "Time unit");
> > this.updated = System.currentTimeMillis();
> > final long newExpiry;
> > if (time > 0) {
> > newExpiry = this.updated + tunit.toMillis(time);
> > } else {
> > newExpiry = Long.MAX_VALUE;
> > }
> > this.expiry = Math.min(newExpiry, this.validityDeadline);
> > }
> >
> >
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> >
> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > Sent: Tuesday, May 19, 2015 4:26 AM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > On Fri, 2015-05-15 at 16:08 +0000, Mark A. Claassen wrote:
> > > Thanks. However, I am still getting the error; even when I do:
> > > connectionManager.setValidateAfterInactivity(1);
> > >
> > > I think this is just because the server can close a keepalive
> > > connection at any time. So, if the server decides to kill off the
> > > connection in that time slice, the request fails. This most often
> > > comes back as a org.apache.http.NoHttpResponseException which the
> > > default retry handler will not retry. It seems the only way I can
> > > be sure than my connections succeed is to disable keep-alives
> > > entirely with a ConnectionReuseStrategy. (Also, Using
> > > RequestConfig.setStaleConnectionCheckEnabled(true) seems works
> > > better than the setting the setValidateAfterInactivity to 1. I am
> > > not sure
> > > why.)
> > >
> > > Question:
> > > releaseConnection in PoolingHttpClientConnectionManager calls updateExpiry in PoolEntry. However, this method in PoolEntry also sets the "updated" time. What is "updated" supposed to represent? If it is mainly used to test the keepalive stuff, then it should be updated based on network activity. It doesn’t seem that changing a time to expire value should be counted as "activity" on the connection.
> > >
> > >
> >
> > 'updated' represents the time of the last update on the client side as opposed to 'expiry' which represents keep-alive period as communicated by the server. One might want to close connections after, say, 3 seconds of inactivity on client side even though the server's keep-alive is, say, 5 seconds.
> >
> > Oleg
> >
> > >
> > > Mark Claassen
> > > Senior Software Engineer
> > >
> > > Donnell Systems, Inc.
> > > 130 South Main Street
> > > Leighton Plaza Suite 375
> > > South Bend, IN 46601
> > > E-mail: mailto:mclaassen@ocie.net
> > > Voice: (574)232-3784
> > > Fax: (574)232-4014
> > >
> > > -------------------------------------------
> > > Confidentiality Notice: OCIESERVICE
> > > -------------------------------------------
> > > The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> > >
> > >
> > > -----Original Message-----
> > > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > > Sent: Thursday, May 14, 2015 4:38 AM
> > > To: HttpClient User Discussion
> > > Subject: Re: Strange SSL error
> > >
> > > On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> > > > The 4.4.1 code doesn't seem to help.
> > > >
> > > > I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
> > > >
> > >
> > > Hi Mark
> > >
> > > Then, it is all very simple. There are several ways to make HttpClient either discard potentially half-closed connections, test them for 'staleness' or automatically recover from NoHttpResponseException.
> > >
> > >
> > > > In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> > > > If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> > > > (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
> > > >
> > >
> > > The default maximum inactivity period used by the pooling connection
> > > manager is exactly 5000 ms. Please try reducing this value to, say,
> > > 2000 ms
> > >
> > > ---
> > > PoolingHttpClientConnectionManager cm = new
> > > PoolingHttpClientConnectionManager();
> > > cm.setValidateAfterInactivity(2000);
> > >
> > > CloseableHttpClient client = HttpClients.custom()
> > > .setConnectionManager(cm)
> > > .build();
> > > ---
> > >
> > > This should make the problem go away.
> > >
> > > > If I use the NoConnectionReuseStrategy, the problem goes away.
> > > >
> > > > Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
> > > >
> > > > I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
> > > >
> > > > } else if (this.validateAfterInactivity > 0) {
> > > > if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> > > > if (!validate(entry)) {
> > > > entry.close();
> > > > }
> > > > }
> > > > }
> > > > Scenario:
> > > > Server sends data.
> > > > Client reads packet, processes it for 6 seconds
> > > > Server senses that inactivity for 5 seconds, closes connection
> > > > Client closes connection and places entry back in the pool
> > > > Connection immediately leased to another thread
> > > > Time between release and close is almost nothing
> > > > Pool releases stale connection.
> > > >
> > >
> > > You can force TTL (total time to live) for connections to avoid this
> > > problem
> > >
> > > ---
> > > PoolingHttpClientConnectionManager cm = new
> > > PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS);
> > > cm.setValidateAfterInactivity(1000);
> > >
> > > CloseableHttpClient client = HttpClients.custom()
> > > .setConnectionManager(cm)
> > > .build();
> > > ---
> > >
> > > Hope this helps
> > >
> > > Oleg
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
(3) or whenever message content is fully consumed.
> response closure but at as soon as the content stream returns -1
Nice. I never thought to check that. Unfortunately, this wasn't happening in my test case. We have our own message structure where we know how long the response is going to be and so never read past the end (getting the -1). However, because we don't know the length immediately, we can't put it in the content length header. I would imagine that this doesn't give HttpClient a chance to detect the EOF condition.
I believe I am using the library "correctly", but I guess I found a condition use case that corrupts the pool a bit. Is this something that can be considered for a future version, or is this one of those things where making a slight change would cause a lot of complications?
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Wednesday, May 20, 2015 9:41 AM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
On Wed, 2015-05-20 at 13:30 +0000, Mark A. Claassen wrote:
> > 'updated' represents the time of the last update on the client
> side as opposed to 'expiry' which represents keep-alive period
>
> Maybe, but the expire time is then set based on the new value of "updated". So, even though no network activity occurred, the new expiration time is set as if there was.
> The impact of this is that, after reading a response from the server, any processing time that is done between the reading of the data and the releasing of the connection is ignored.
You see, the connection release is triggered whenever either of these events take place.
(1) request is aborted
(2) response is closed
(3) or whenever message content is fully consumed.
So, in the normal course of request execution the expiry time gets updated not at the time of response closure but at as soon as the content stream returns -1 (end of stream). That is, pretty much at the same time as the keep-alive timer starts ticking at the server side.
Oleg
> If the KeepAlive duration is 5 seconds, but some code takes 6 seconds to process the results, an expired entry will be placed back into the pool. This might not be a big deal, but it defeats the purpose of the check. It will also force a stale connection check on a connection that is known to be expired.
>
> This is assuming the pattern of:
> Open Connection
> try {
> Send request
> Read response
> Do some initial processing of the response
> }
> finally {
> Close connection
> }
>
> Perhaps the "newExpiry" should be calculated before the "updated" is set to the current time?
>
> public synchronized void updateExpiry(final long time, final TimeUnit tunit) {
> Args.notNull(tunit, "Time unit");
> this.updated = System.currentTimeMillis();
> final long newExpiry;
> if (time > 0) {
> newExpiry = this.updated + tunit.toMillis(time);
> } else {
> newExpiry = Long.MAX_VALUE;
> }
> this.expiry = Math.min(newExpiry, this.validityDeadline);
> }
>
>
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Tuesday, May 19, 2015 4:26 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Fri, 2015-05-15 at 16:08 +0000, Mark A. Claassen wrote:
> > Thanks. However, I am still getting the error; even when I do:
> > connectionManager.setValidateAfterInactivity(1);
> >
> > I think this is just because the server can close a keepalive
> > connection at any time. So, if the server decides to kill off the
> > connection in that time slice, the request fails. This most often
> > comes back as a org.apache.http.NoHttpResponseException which the
> > default retry handler will not retry. It seems the only way I can
> > be sure than my connections succeed is to disable keep-alives
> > entirely with a ConnectionReuseStrategy. (Also, Using
> > RequestConfig.setStaleConnectionCheckEnabled(true) seems works
> > better than the setting the setValidateAfterInactivity to 1. I am
> > not sure
> > why.)
> >
> > Question:
> > releaseConnection in PoolingHttpClientConnectionManager calls updateExpiry in PoolEntry. However, this method in PoolEntry also sets the "updated" time. What is "updated" supposed to represent? If it is mainly used to test the keepalive stuff, then it should be updated based on network activity. It doesn’t seem that changing a time to expire value should be counted as "activity" on the connection.
> >
> >
>
> 'updated' represents the time of the last update on the client side as opposed to 'expiry' which represents keep-alive period as communicated by the server. One might want to close connections after, say, 3 seconds of inactivity on client side even though the server's keep-alive is, say, 5 seconds.
>
> Oleg
>
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> >
> >
> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > Sent: Thursday, May 14, 2015 4:38 AM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> > > The 4.4.1 code doesn't seem to help.
> > >
> > > I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
> > >
> >
> > Hi Mark
> >
> > Then, it is all very simple. There are several ways to make HttpClient either discard potentially half-closed connections, test them for 'staleness' or automatically recover from NoHttpResponseException.
> >
> >
> > > In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> > > If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> > > (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
> > >
> >
> > The default maximum inactivity period used by the pooling connection
> > manager is exactly 5000 ms. Please try reducing this value to, say,
> > 2000 ms
> >
> > ---
> > PoolingHttpClientConnectionManager cm = new
> > PoolingHttpClientConnectionManager();
> > cm.setValidateAfterInactivity(2000);
> >
> > CloseableHttpClient client = HttpClients.custom()
> > .setConnectionManager(cm)
> > .build();
> > ---
> >
> > This should make the problem go away.
> >
> > > If I use the NoConnectionReuseStrategy, the problem goes away.
> > >
> > > Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
> > >
> > > I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
> > >
> > > } else if (this.validateAfterInactivity > 0) {
> > > if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> > > if (!validate(entry)) {
> > > entry.close();
> > > }
> > > }
> > > }
> > > Scenario:
> > > Server sends data.
> > > Client reads packet, processes it for 6 seconds
> > > Server senses that inactivity for 5 seconds, closes connection
> > > Client closes connection and places entry back in the pool
> > > Connection immediately leased to another thread
> > > Time between release and close is almost nothing
> > > Pool releases stale connection.
> > >
> >
> > You can force TTL (total time to live) for connections to avoid this
> > problem
> >
> > ---
> > PoolingHttpClientConnectionManager cm = new
> > PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS);
> > cm.setValidateAfterInactivity(1000);
> >
> > CloseableHttpClient client = HttpClients.custom()
> > .setConnectionManager(cm)
> > .build();
> > ---
> >
> > Hope this helps
> >
> > Oleg
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2015-05-20 at 13:30 +0000, Mark A. Claassen wrote:
> > 'updated' represents the time of the last update on the client side as opposed to 'expiry' which represents keep-alive period
>
> Maybe, but the expire time is then set based on the new value of "updated". So, even though no network activity occurred, the new expiration time is set as if there was.
> The impact of this is that, after reading a response from the server, any processing time that is done between the reading of the data and the releasing of the connection is ignored.
You see, the connection release is triggered whenever either of these
events take place.
(1) request is aborted
(2) response is closed
(3) or whenever message content is fully consumed.
So, in the normal course of request execution the expiry time gets
updated not at the time of response closure but at as soon as the
content stream returns -1 (end of stream). That is, pretty much at the
same time as the keep-alive timer starts ticking at the server side.
Oleg
> If the KeepAlive duration is 5 seconds, but some code takes 6 seconds to process the results, an expired entry will be placed back into the pool. This might not be a big deal, but it defeats the purpose of the check. It will also force a stale connection check on a connection that is known to be expired.
>
> This is assuming the pattern of:
> Open Connection
> try {
> Send request
> Read response
> Do some initial processing of the response
> }
> finally {
> Close connection
> }
>
> Perhaps the "newExpiry" should be calculated before the "updated" is set to the current time?
>
> public synchronized void updateExpiry(final long time, final TimeUnit tunit) {
> Args.notNull(tunit, "Time unit");
> this.updated = System.currentTimeMillis();
> final long newExpiry;
> if (time > 0) {
> newExpiry = this.updated + tunit.toMillis(time);
> } else {
> newExpiry = Long.MAX_VALUE;
> }
> this.expiry = Math.min(newExpiry, this.validityDeadline);
> }
>
>
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Tuesday, May 19, 2015 4:26 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Fri, 2015-05-15 at 16:08 +0000, Mark A. Claassen wrote:
> > Thanks. However, I am still getting the error; even when I do:
> > connectionManager.setValidateAfterInactivity(1);
> >
> > I think this is just because the server can close a keepalive
> > connection at any time. So, if the server decides to kill off the
> > connection in that time slice, the request fails. This most often
> > comes back as a org.apache.http.NoHttpResponseException which the
> > default retry handler will not retry. It seems the only way I can be
> > sure than my connections succeed is to disable keep-alives entirely
> > with a ConnectionReuseStrategy. (Also, Using
> > RequestConfig.setStaleConnectionCheckEnabled(true) seems works better
> > than the setting the setValidateAfterInactivity to 1. I am not sure
> > why.)
> >
> > Question:
> > releaseConnection in PoolingHttpClientConnectionManager calls updateExpiry in PoolEntry. However, this method in PoolEntry also sets the "updated" time. What is "updated" supposed to represent? If it is mainly used to test the keepalive stuff, then it should be updated based on network activity. It doesn’t seem that changing a time to expire value should be counted as "activity" on the connection.
> >
> >
>
> 'updated' represents the time of the last update on the client side as opposed to 'expiry' which represents keep-alive period as communicated by the server. One might want to close connections after, say, 3 seconds of inactivity on client side even though the server's keep-alive is, say, 5 seconds.
>
> Oleg
>
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> >
> >
> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > Sent: Thursday, May 14, 2015 4:38 AM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> > > The 4.4.1 code doesn't seem to help.
> > >
> > > I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
> > >
> >
> > Hi Mark
> >
> > Then, it is all very simple. There are several ways to make HttpClient either discard potentially half-closed connections, test them for 'staleness' or automatically recover from NoHttpResponseException.
> >
> >
> > > In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> > > If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> > > (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
> > >
> >
> > The default maximum inactivity period used by the pooling connection
> > manager is exactly 5000 ms. Please try reducing this value to, say,
> > 2000 ms
> >
> > ---
> > PoolingHttpClientConnectionManager cm = new
> > PoolingHttpClientConnectionManager();
> > cm.setValidateAfterInactivity(2000);
> >
> > CloseableHttpClient client = HttpClients.custom()
> > .setConnectionManager(cm)
> > .build();
> > ---
> >
> > This should make the problem go away.
> >
> > > If I use the NoConnectionReuseStrategy, the problem goes away.
> > >
> > > Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
> > >
> > > I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
> > >
> > > } else if (this.validateAfterInactivity > 0) {
> > > if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> > > if (!validate(entry)) {
> > > entry.close();
> > > }
> > > }
> > > }
> > > Scenario:
> > > Server sends data.
> > > Client reads packet, processes it for 6 seconds
> > > Server senses that inactivity for 5 seconds, closes connection
> > > Client closes connection and places entry back in the pool
> > > Connection immediately leased to another thread
> > > Time between release and close is almost nothing
> > > Pool releases stale connection.
> > >
> >
> > You can force TTL (total time to live) for connections to avoid this
> > problem
> >
> > ---
> > PoolingHttpClientConnectionManager cm = new
> > PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS);
> > cm.setValidateAfterInactivity(1000);
> >
> > CloseableHttpClient client = HttpClients.custom()
> > .setConnectionManager(cm)
> > .build();
> > ---
> >
> > Hope this helps
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
> 'updated' represents the time of the last update on the client side as opposed to 'expiry' which represents keep-alive period
Maybe, but the expire time is then set based on the new value of "updated". So, even though no network activity occurred, the new expiration time is set as if there was.
The impact of this is that, after reading a response from the server, any processing time that is done between the reading of the data and the releasing of the connection is ignored. If the KeepAlive duration is 5 seconds, but some code takes 6 seconds to process the results, an expired entry will be placed back into the pool. This might not be a big deal, but it defeats the purpose of the check. It will also force a stale connection check on a connection that is known to be expired.
This is assuming the pattern of:
Open Connection
try {
Send request
Read response
Do some initial processing of the response
}
finally {
Close connection
}
Perhaps the "newExpiry" should be calculated before the "updated" is set to the current time?
public synchronized void updateExpiry(final long time, final TimeUnit tunit) {
Args.notNull(tunit, "Time unit");
this.updated = System.currentTimeMillis();
final long newExpiry;
if (time > 0) {
newExpiry = this.updated + tunit.toMillis(time);
} else {
newExpiry = Long.MAX_VALUE;
}
this.expiry = Math.min(newExpiry, this.validityDeadline);
}
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Tuesday, May 19, 2015 4:26 AM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
On Fri, 2015-05-15 at 16:08 +0000, Mark A. Claassen wrote:
> Thanks. However, I am still getting the error; even when I do:
> connectionManager.setValidateAfterInactivity(1);
>
> I think this is just because the server can close a keepalive
> connection at any time. So, if the server decides to kill off the
> connection in that time slice, the request fails. This most often
> comes back as a org.apache.http.NoHttpResponseException which the
> default retry handler will not retry. It seems the only way I can be
> sure than my connections succeed is to disable keep-alives entirely
> with a ConnectionReuseStrategy. (Also, Using
> RequestConfig.setStaleConnectionCheckEnabled(true) seems works better
> than the setting the setValidateAfterInactivity to 1. I am not sure
> why.)
>
> Question:
> releaseConnection in PoolingHttpClientConnectionManager calls updateExpiry in PoolEntry. However, this method in PoolEntry also sets the "updated" time. What is "updated" supposed to represent? If it is mainly used to test the keepalive stuff, then it should be updated based on network activity. It doesn’t seem that changing a time to expire value should be counted as "activity" on the connection.
>
>
'updated' represents the time of the last update on the client side as opposed to 'expiry' which represents keep-alive period as communicated by the server. One might want to close connections after, say, 3 seconds of inactivity on client side even though the server's keep-alive is, say, 5 seconds.
Oleg
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Thursday, May 14, 2015 4:38 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> > The 4.4.1 code doesn't seem to help.
> >
> > I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
> >
>
> Hi Mark
>
> Then, it is all very simple. There are several ways to make HttpClient either discard potentially half-closed connections, test them for 'staleness' or automatically recover from NoHttpResponseException.
>
>
> > In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> > If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> > (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
> >
>
> The default maximum inactivity period used by the pooling connection
> manager is exactly 5000 ms. Please try reducing this value to, say,
> 2000 ms
>
> ---
> PoolingHttpClientConnectionManager cm = new
> PoolingHttpClientConnectionManager();
> cm.setValidateAfterInactivity(2000);
>
> CloseableHttpClient client = HttpClients.custom()
> .setConnectionManager(cm)
> .build();
> ---
>
> This should make the problem go away.
>
> > If I use the NoConnectionReuseStrategy, the problem goes away.
> >
> > Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
> >
> > I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
> >
> > } else if (this.validateAfterInactivity > 0) {
> > if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> > if (!validate(entry)) {
> > entry.close();
> > }
> > }
> > }
> > Scenario:
> > Server sends data.
> > Client reads packet, processes it for 6 seconds
> > Server senses that inactivity for 5 seconds, closes connection
> > Client closes connection and places entry back in the pool
> > Connection immediately leased to another thread
> > Time between release and close is almost nothing
> > Pool releases stale connection.
> >
>
> You can force TTL (total time to live) for connections to avoid this
> problem
>
> ---
> PoolingHttpClientConnectionManager cm = new
> PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS);
> cm.setValidateAfterInactivity(1000);
>
> CloseableHttpClient client = HttpClients.custom()
> .setConnectionManager(cm)
> .build();
> ---
>
> Hope this helps
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2015-05-15 at 16:08 +0000, Mark A. Claassen wrote:
> Thanks. However, I am still getting the error; even when I do: connectionManager.setValidateAfterInactivity(1);
>
> I think this is just because the server can close a keepalive connection at any time. So, if the server decides to kill off the connection in that time slice, the request fails. This most often comes back as a org.apache.http.NoHttpResponseException which the default retry handler will not retry. It seems the only way I can be sure than my connections succeed is to disable keep-alives entirely with a ConnectionReuseStrategy. (Also, Using RequestConfig.setStaleConnectionCheckEnabled(true) seems works better than the setting the setValidateAfterInactivity to 1. I am not sure why.)
>
> Question:
> releaseConnection in PoolingHttpClientConnectionManager calls updateExpiry in PoolEntry. However, this method in PoolEntry also sets the "updated" time. What is "updated" supposed to represent? If it is mainly used to test the keepalive stuff, then it should be updated based on network activity. It doesn’t seem that changing a time to expire value should be counted as "activity" on the connection.
>
>
'updated' represents the time of the last update on the client side as
opposed to 'expiry' which represents keep-alive period as communicated
by the server. One might want to close connections after, say, 3 seconds
of inactivity on client side even though the server's keep-alive is,
say, 5 seconds.
Oleg
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Thursday, May 14, 2015 4:38 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> > The 4.4.1 code doesn't seem to help.
> >
> > I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
> >
>
> Hi Mark
>
> Then, it is all very simple. There are several ways to make HttpClient either discard potentially half-closed connections, test them for 'staleness' or automatically recover from NoHttpResponseException.
>
>
> > In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> > If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> > (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
> >
>
> The default maximum inactivity period used by the pooling connection manager is exactly 5000 ms. Please try reducing this value to, say, 2000 ms
>
> ---
> PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
> cm.setValidateAfterInactivity(2000);
>
> CloseableHttpClient client = HttpClients.custom()
> .setConnectionManager(cm)
> .build();
> ---
>
> This should make the problem go away.
>
> > If I use the NoConnectionReuseStrategy, the problem goes away.
> >
> > Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
> >
> > I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
> >
> > } else if (this.validateAfterInactivity > 0) {
> > if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> > if (!validate(entry)) {
> > entry.close();
> > }
> > }
> > }
> > Scenario:
> > Server sends data.
> > Client reads packet, processes it for 6 seconds
> > Server senses that inactivity for 5 seconds, closes connection
> > Client closes connection and places entry back in the pool
> > Connection immediately leased to another thread
> > Time between release and close is almost nothing
> > Pool releases stale connection.
> >
>
> You can force TTL (total time to live) for connections to avoid this problem
>
> ---
> PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS); cm.setValidateAfterInactivity(1000);
>
> CloseableHttpClient client = HttpClients.custom()
> .setConnectionManager(cm)
> .build();
> ---
>
> Hope this helps
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
Thanks. However, I am still getting the error; even when I do: connectionManager.setValidateAfterInactivity(1);
I think this is just because the server can close a keepalive connection at any time. So, if the server decides to kill off the connection in that time slice, the request fails. This most often comes back as a org.apache.http.NoHttpResponseException which the default retry handler will not retry. It seems the only way I can be sure than my connections succeed is to disable keep-alives entirely with a ConnectionReuseStrategy. (Also, Using RequestConfig.setStaleConnectionCheckEnabled(true) seems works better than the setting the setValidateAfterInactivity to 1. I am not sure why.)
Question:
releaseConnection in PoolingHttpClientConnectionManager calls updateExpiry in PoolEntry. However, this method in PoolEntry also sets the "updated" time. What is "updated" supposed to represent? If it is mainly used to test the keepalive stuff, then it should be updated based on network activity. It doesn’t seem that changing a time to expire value should be counted as "activity" on the connection.
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Thursday, May 14, 2015 4:38 AM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> The 4.4.1 code doesn't seem to help.
>
> I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
>
Hi Mark
Then, it is all very simple. There are several ways to make HttpClient either discard potentially half-closed connections, test them for 'staleness' or automatically recover from NoHttpResponseException.
> In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
>
The default maximum inactivity period used by the pooling connection manager is exactly 5000 ms. Please try reducing this value to, say, 2000 ms
---
PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
cm.setValidateAfterInactivity(2000);
CloseableHttpClient client = HttpClients.custom()
.setConnectionManager(cm)
.build();
---
This should make the problem go away.
> If I use the NoConnectionReuseStrategy, the problem goes away.
>
> Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
>
> I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
>
> } else if (this.validateAfterInactivity > 0) {
> if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> if (!validate(entry)) {
> entry.close();
> }
> }
> }
> Scenario:
> Server sends data.
> Client reads packet, processes it for 6 seconds
> Server senses that inactivity for 5 seconds, closes connection
> Client closes connection and places entry back in the pool
> Connection immediately leased to another thread
> Time between release and close is almost nothing
> Pool releases stale connection.
>
You can force TTL (total time to live) for connections to avoid this problem
---
PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS); cm.setValidateAfterInactivity(1000);
CloseableHttpClient client = HttpClients.custom()
.setConnectionManager(cm)
.build();
---
Hope this helps
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2015-05-13 at 20:58 +0000, Mark A. Claassen wrote:
> The 4.4.1 code doesn't seem to help.
>
> I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
>
Hi Mark
Then, it is all very simple. There are several ways to make HttpClient
either discard potentially half-closed connections, test them for
'staleness' or automatically recover from NoHttpResponseException.
> In my test case I open the connection, read all the data, sleep for a while, then close the connection.
> If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
> (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
>
The default maximum inactivity period used by the pooling connection
manager is exactly 5000 ms. Please try reducing this value to, say, 2000
ms
---
PoolingHttpClientConnectionManager cm = new
PoolingHttpClientConnectionManager();
cm.setValidateAfterInactivity(2000);
CloseableHttpClient client = HttpClients.custom()
.setConnectionManager(cm)
.build();
---
This should make the problem go away.
> If I use the NoConnectionReuseStrategy, the problem goes away.
>
> Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
>
> I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
>
> } else if (this.validateAfterInactivity > 0) {
> if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
> if (!validate(entry)) {
> entry.close();
> }
> }
> }
> Scenario:
> Server sends data.
> Client reads packet, processes it for 6 seconds
> Server senses that inactivity for 5 seconds, closes connection
> Client closes connection and places entry back in the pool
> Connection immediately leased to another thread
> Time between release and close is almost nothing
> Pool releases stale connection.
>
You can force TTL (total time to live) for connections to avoid this
problem
---
PoolingHttpClientConnectionManager cm = new
PoolingHttpClientConnectionManager(3000, TimeUnit.MILLISECONDS);
cm.setValidateAfterInactivity(1000);
CloseableHttpClient client = HttpClients.custom()
.setConnectionManager(cm)
.build();
---
Hope this helps
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi,
I confirm there seem to be a bug in this field as per :
- https://bz.apache.org/bugzilla/show_bug.cgi?id=57921
Regards
On Wed, May 13, 2015 at 10:58 PM, Mark A. Claassen <MC...@ocie.net>
wrote:
> The 4.4.1 code doesn't seem to help.
>
> I have been able to reproduce the issue more regularly now. It seems to
> have to do with keep-alives and if the client takes longer to read the
> message than the keep alive value.
>
> In my test case I open the connection, read all the data, sleep for a
> while, then close the connection.
> If my sleep is a bit longer than the keep-alive value, I will get a
> org.apache.http.NoHttpResponseException. If my sleep value is larger, I
> will get a java.net.SocketException.
> (Keep-Alive is 5000 millis. If I sleep for 6000, I will get a
> NoHttpResponseException. If I sleep for 11000, I will get a
> SocketException.
>
> If I use the NoConnectionReuseStrategy, the problem goes away.
>
> Is something set up for my keep alives? I put some breakpoints in
> CPool.java. I can see connections being created, but the validate() method
> of CPool is never getting called.
>
> I am curious this part of AbstractConnPool.java. This seems like if the
> server invalidated a connection early, the validate check would never
> happen.
>
> } else if (this.validateAfterInactivity > 0) {
> if (entry.getUpdated() +
> this.validateAfterInactivity <= System.currentTimeMillis()) {
> if (!validate(entry)) {
> entry.close();
> }
> }
> }
> Scenario:
> Server sends data.
> Client reads packet, processes it for 6 seconds
> Server senses that inactivity for 5 seconds, closes connection
> Client closes connection and places entry back in the pool
> Connection immediately leased to another thread
> Time between release and close is almost nothing
> Pool releases stale connection.
>
>
>
> ---- (1) ---- Throwable - Class (class java.net.SocketException)
> Message (Software caused connection abort: socket write error)
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
> at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
> at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
> at
> sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:864)
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:835)
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> at
> org.apache.http.impl.conn.LoggingOutputStream.write(LoggingOutputStream.java:77)
> at
> org.apache.http.impl.io.SessionOutputBufferImpl.streamWrite(SessionOutputBufferImpl.java:126)
> at
> org.apache.http.impl.io.SessionOutputBufferImpl.flushBuffer(SessionOutputBufferImpl.java:138)
> at
> org.apache.http.impl.io.SessionOutputBufferImpl.flush(SessionOutputBufferImpl.java:146)
>
>
> ---- (1) ---- Throwable - Class (class
> org.apache.http.NoHttpResponseException)
> Message (The target server failed to respond)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>
>
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) named in this message. This communication is
> intended to be and to remain confidential. If you are not the intended
> recipient of this message, or if this message has been addressed to you in
> error, please immediately alert the sender by reply e-mail and then delete
> this message and its attachments. Do not deliver, distribute, copy,
> disclose the contents or take any action in reliance upon the information
> contained in the communication or any attachments.
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Wednesday, May 13, 2015 3:25 AM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> On Tue, 2015-05-12 at 20:28 +0000, Mark A. Claassen wrote:
> > I was looking at the change log for 4.4 and 4.4.1. Count
> HTTPCLIENT-1609 be causing this?
>
> The issue was about detection of half-closed connections. If
> NoHttpResponseException you have been seeing is a result of the connection
> getting closed by the opposite endpoint, upgrading to 4.4.1
> might help resolve the issue.
>
> Oleg
>
> > Or does it have to be something on the network closing the connection?
> >
> > * [HTTPCLIENT-1609] Stale connection check in
> PoolingHttpClientConnectionManager has no effect.
> > Internal connection pool does not correctly implement connection
> validation.
> > Contributed by Charles Lip <rene1 at singnet.com.sg>
> >
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) named in this message. This communication is
> intended to be and to remain confidential. If you are not the intended
> recipient of this message, or if this message has been addressed to you in
> error, please immediately alert the sender by reply e-mail and then delete
> this message and its attachments. Do not deliver, distribute, copy,
> disclose the contents or take any action in reliance upon the information
> contained in the communication or any attachments.
> >
> >
> > -----Original Message-----
> > From: Mark A. Claassen [mailto:MClaassen@ocie.net]
> > Sent: Tuesday, May 12, 2015 8:58 AM
> > To: HttpClient User Discussion
> > Subject: RE: Strange SSL error
> >
> > The scenario is that he logs in to our Swing application, there is a
> burst of transactions, maybe a slight pause, and then the next one fails.
> The whole process probably takes around 10 seconds. I was actually
> wondering if this had something to do with bad connections in the pool, but
> it is hard to say since I can't reproduce it reliably.
> >
> > The communication is over SSL, and consists of readable XML and binary
> data. Most of the messages are < 10K, some bigger. We checked the
> firewall wall logs (since there is a firewall involved) and there is
> nothing. I connect through the same route and this never happens to me.
> >
> > Thanks again,
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> > -------------------------------------------
> > Confidentiality Notice: OCIESERVICE
> > -------------------------------------------
> > The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) named in this message. This communication is
> intended to be and to remain confidential. If you are not the intended
> recipient of this message, or if this message has been addressed to you in
> error, please immediately alert the sender by reply e-mail and then delete
> this message and its attachments. Do not deliver, distribute, copy,
> disclose the contents or take any action in reliance upon the information
> contained in the communication or any attachments.
> >
> > -----Original Message-----
> > From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> > Sent: Monday, May 11, 2015 5:15 PM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > What kind of data is being transfered? Do you tend to keep connections
> open for a long time? Firewall killing connections?
> >
> > Sendt fra min iPhone
> >
> > > Den 11. mai 2015 kl. 21.36 skrev Mark A. Claassen <MClaassen@ocie.net
> >:
> > >
> > > What would cause the reset, and what would make it so seemingly
> random? Is there something I am doing wrong? Is there a setting I can set
> so that this doesn't randomly happen to him? It is not too often, but
> often enough to be annoying and look like a failure in the application.
> > >
> > > Thanks
> > >
> > > Mark Claassen
> > > Senior Software Engineer
> > >
> > > Donnell Systems, Inc.
> > > 130 South Main Street
> > > Leighton Plaza Suite 375
> > > South Bend, IN 46601
> > > E-mail: mailto:mclaassen@ocie.net
> > > Voice: (574)232-3784
> > > Fax: (574)232-4014
> > >
> > >
> > > -----Original Message-----
> > > From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> > > Sent: Friday, May 08, 2015 5:20 PM
> > > To: HttpClient User Discussion
> > > Subject: Re: Strange SSL error
> > >
> > > Looks like a tcp reset to me
> > >
> > > Sendt fra min iPhone
> > >
> > >> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MClaassen@ocie.net
> >:
> > >>
> > >> We are having one user that is getting this sporadically. No one
> else can reproduce it. Any idea what might be causing it? Because it is
> hard to reproduce, I am having trouble knowing where to start? Everyone
> else who tries has no issues. He logs into our application, which involves
> lots of small network transactions, and then the next thing he does often
> causes this. I think the situation would be that there is a lot of
> transactions very quickly, then a slight delay. After this, the next
> transaction fails, and then it will be fine. Any ideas?
> > >>
> > >>
> > >> ---- (1) ---- Throwable - Class (class
> org.apache.http.NoHttpResponseException)
> > >> Message (portal.cpfs.com:443 failed to respond)
> > >> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> > >> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> > >> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> > >> at
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> > >> at
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> > >> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> > >> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> > >> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> > >> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> > >> at
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> > >> at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> > >> at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> > >> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> > >> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> > >> at
> > >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt
> > >> tpClient.java:55)
> > >> Mark Claassen
> > >> Senior Software Engineer
> > >>
> > >> Donnell Systems, Inc.
> > >> 130 South Main Street
> > >> Leighton Plaza Suite 375
> > >> South Bend, IN 46601
> > >> E-mail: mailto:mclaassen@ocie.net
> > >> Voice: (574)232-3784
> > >> Fax: (574)232-4014
> > >>
> > >> -------------------------------------------
> > >> Confidentiality Notice: OCIESERVICE
> > >> -------------------------------------------
> > >> The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) named in this message. This communication is
> intended to be and to remain confidential. If you are not the intended
> recipient of this message, or if this message has been addressed to you in
> error, please immediately alert the sender by reply e-mail and then delete
> this message and its attachments. Do not deliver, distribute, copy,
> disclose the contents or take any action in reliance upon the information
> contained in the communication or any attachments.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> > B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > KCB [ X ܚX K K[XZ[
> > Y[
> > ]\ \ ][ X ܚX P ˘\ X K ܙ B ܈ Y ] [ۘ[ [X[ K[XZ[
> > Y[
> > ]\ \ Z [ ˘\ X K ܙ B B
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
--
Cordialement.
Philippe Mouawad.
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
The 4.4.1 code doesn't seem to help.
I have been able to reproduce the issue more regularly now. It seems to have to do with keep-alives and if the client takes longer to read the message than the keep alive value.
In my test case I open the connection, read all the data, sleep for a while, then close the connection.
If my sleep is a bit longer than the keep-alive value, I will get a org.apache.http.NoHttpResponseException. If my sleep value is larger, I will get a java.net.SocketException.
(Keep-Alive is 5000 millis. If I sleep for 6000, I will get a NoHttpResponseException. If I sleep for 11000, I will get a SocketException.
If I use the NoConnectionReuseStrategy, the problem goes away.
Is something set up for my keep alives? I put some breakpoints in CPool.java. I can see connections being created, but the validate() method of CPool is never getting called.
I am curious this part of AbstractConnPool.java. This seems like if the server invalidated a connection early, the validate check would never happen.
} else if (this.validateAfterInactivity > 0) {
if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
if (!validate(entry)) {
entry.close();
}
}
}
Scenario:
Server sends data.
Client reads packet, processes it for 6 seconds
Server senses that inactivity for 5 seconds, closes connection
Client closes connection and places entry back in the pool
Connection immediately leased to another thread
Time between release and close is almost nothing
Pool releases stale connection.
---- (1) ---- Throwable - Class (class java.net.SocketException)
Message (Software caused connection abort: socket write error)
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:864)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:835)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
at org.apache.http.impl.conn.LoggingOutputStream.write(LoggingOutputStream.java:77)
at org.apache.http.impl.io.SessionOutputBufferImpl.streamWrite(SessionOutputBufferImpl.java:126)
at org.apache.http.impl.io.SessionOutputBufferImpl.flushBuffer(SessionOutputBufferImpl.java:138)
at org.apache.http.impl.io.SessionOutputBufferImpl.flush(SessionOutputBufferImpl.java:146)
---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
Message (The target server failed to respond)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Wednesday, May 13, 2015 3:25 AM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
On Tue, 2015-05-12 at 20:28 +0000, Mark A. Claassen wrote:
> I was looking at the change log for 4.4 and 4.4.1. Count HTTPCLIENT-1609 be causing this?
The issue was about detection of half-closed connections. If NoHttpResponseException you have been seeing is a result of the connection getting closed by the opposite endpoint, upgrading to 4.4.1
might help resolve the issue.
Oleg
> Or does it have to be something on the network closing the connection?
>
> * [HTTPCLIENT-1609] Stale connection check in PoolingHttpClientConnectionManager has no effect.
> Internal connection pool does not correctly implement connection validation.
> Contributed by Charles Lip <rene1 at singnet.com.sg>
>
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
>
> -----Original Message-----
> From: Mark A. Claassen [mailto:MClaassen@ocie.net]
> Sent: Tuesday, May 12, 2015 8:58 AM
> To: HttpClient User Discussion
> Subject: RE: Strange SSL error
>
> The scenario is that he logs in to our Swing application, there is a burst of transactions, maybe a slight pause, and then the next one fails. The whole process probably takes around 10 seconds. I was actually wondering if this had something to do with bad connections in the pool, but it is hard to say since I can't reproduce it reliably.
>
> The communication is over SSL, and consists of readable XML and binary data. Most of the messages are < 10K, some bigger. We checked the firewall wall logs (since there is a firewall involved) and there is nothing. I connect through the same route and this never happens to me.
>
> Thanks again,
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
> -----Original Message-----
> From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> Sent: Monday, May 11, 2015 5:15 PM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> What kind of data is being transfered? Do you tend to keep connections open for a long time? Firewall killing connections?
>
> Sendt fra min iPhone
>
> > Den 11. mai 2015 kl. 21.36 skrev Mark A. Claassen <MC...@ocie.net>:
> >
> > What would cause the reset, and what would make it so seemingly random? Is there something I am doing wrong? Is there a setting I can set so that this doesn't randomly happen to him? It is not too often, but often enough to be annoying and look like a failure in the application.
> >
> > Thanks
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> >
> > -----Original Message-----
> > From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> > Sent: Friday, May 08, 2015 5:20 PM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > Looks like a tcp reset to me
> >
> > Sendt fra min iPhone
> >
> >> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MC...@ocie.net>:
> >>
> >> We are having one user that is getting this sporadically. No one else can reproduce it. Any idea what might be causing it? Because it is hard to reproduce, I am having trouble knowing where to start? Everyone else who tries has no issues. He logs into our application, which involves lots of small network transactions, and then the next thing he does often causes this. I think the situation would be that there is a lot of transactions very quickly, then a slight delay. After this, the next transaction fails, and then it will be fine. Any ideas?
> >>
> >>
> >> ---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
> >> Message (portal.cpfs.com:443 failed to respond)
> >> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> >> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> >> at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> >> at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> >> at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> >> at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> >> at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> >> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> >> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> >> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> >> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> >> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> >> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> >> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> >> at
> >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt
> >> tpClient.java:55)
> >> Mark Claassen
> >> Senior Software Engineer
> >>
> >> Donnell Systems, Inc.
> >> 130 South Main Street
> >> Leighton Plaza Suite 375
> >> South Bend, IN 46601
> >> E-mail: mailto:mclaassen@ocie.net
> >> Voice: (574)232-3784
> >> Fax: (574)232-4014
> >>
> >> -------------------------------------------
> >> Confidentiality Notice: OCIESERVICE
> >> -------------------------------------------
> >> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
> B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> KCB [ X ܚX KK[XZ[
> Y[
> ]\ \ ][ X ܚX P˘\X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
> Y[
> ]\ \ Z[ ˘\X K ܙ B B
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2015-05-12 at 20:28 +0000, Mark A. Claassen wrote:
> I was looking at the change log for 4.4 and 4.4.1. Count HTTPCLIENT-1609 be causing this?
The issue was about detection of half-closed connections. If
NoHttpResponseException you have been seeing is a result of the
connection getting closed by the opposite endpoint, upgrading to 4.4.1
might help resolve the issue.
Oleg
> Or does it have to be something on the network closing the connection?
>
> * [HTTPCLIENT-1609] Stale connection check in PoolingHttpClientConnectionManager has no effect.
> Internal connection pool does not correctly implement connection validation.
> Contributed by Charles Lip <rene1 at singnet.com.sg>
>
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
>
> -----Original Message-----
> From: Mark A. Claassen [mailto:MClaassen@ocie.net]
> Sent: Tuesday, May 12, 2015 8:58 AM
> To: HttpClient User Discussion
> Subject: RE: Strange SSL error
>
> The scenario is that he logs in to our Swing application, there is a burst of transactions, maybe a slight pause, and then the next one fails. The whole process probably takes around 10 seconds. I was actually wondering if this had something to do with bad connections in the pool, but it is hard to say since I can't reproduce it reliably.
>
> The communication is over SSL, and consists of readable XML and binary data. Most of the messages are < 10K, some bigger. We checked the firewall wall logs (since there is a firewall involved) and there is nothing. I connect through the same route and this never happens to me.
>
> Thanks again,
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
> -----Original Message-----
> From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> Sent: Monday, May 11, 2015 5:15 PM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> What kind of data is being transfered? Do you tend to keep connections open for a long time? Firewall killing connections?
>
> Sendt fra min iPhone
>
> > Den 11. mai 2015 kl. 21.36 skrev Mark A. Claassen <MC...@ocie.net>:
> >
> > What would cause the reset, and what would make it so seemingly random? Is there something I am doing wrong? Is there a setting I can set so that this doesn't randomly happen to him? It is not too often, but often enough to be annoying and look like a failure in the application.
> >
> > Thanks
> >
> > Mark Claassen
> > Senior Software Engineer
> >
> > Donnell Systems, Inc.
> > 130 South Main Street
> > Leighton Plaza Suite 375
> > South Bend, IN 46601
> > E-mail: mailto:mclaassen@ocie.net
> > Voice: (574)232-3784
> > Fax: (574)232-4014
> >
> >
> > -----Original Message-----
> > From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> > Sent: Friday, May 08, 2015 5:20 PM
> > To: HttpClient User Discussion
> > Subject: Re: Strange SSL error
> >
> > Looks like a tcp reset to me
> >
> > Sendt fra min iPhone
> >
> >> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MC...@ocie.net>:
> >>
> >> We are having one user that is getting this sporadically. No one else can reproduce it. Any idea what might be causing it? Because it is hard to reproduce, I am having trouble knowing where to start? Everyone else who tries has no issues. He logs into our application, which involves lots of small network transactions, and then the next thing he does often causes this. I think the situation would be that there is a lot of transactions very quickly, then a slight delay. After this, the next transaction fails, and then it will be fine. Any ideas?
> >>
> >>
> >> ---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
> >> Message (portal.cpfs.com:443 failed to respond)
> >> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> >> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> >> at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> >> at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> >> at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> >> at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> >> at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> >> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> >> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> >> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> >> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> >> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> >> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> >> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> >> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> >> Mark Claassen
> >> Senior Software Engineer
> >>
> >> Donnell Systems, Inc.
> >> 130 South Main Street
> >> Leighton Plaza Suite 375
> >> South Bend, IN 46601
> >> E-mail: mailto:mclaassen@ocie.net
> >> Voice: (574)232-3784
> >> Fax: (574)232-4014
> >>
> >> -------------------------------------------
> >> Confidentiality Notice: OCIESERVICE
> >> -------------------------------------------
> >> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
> B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��X��ܚX�KK[XZ[
> � �Y[�
> ]\�\��][��X��ܚX�P˘\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[
> � �Y[�
> ]\�\��Z[ ˘\X�K�ܙ�B�B
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
I was looking at the change log for 4.4 and 4.4.1. Count HTTPCLIENT-1609 be causing this? Or does it have to be something on the network closing the connection?
* [HTTPCLIENT-1609] Stale connection check in PoolingHttpClientConnectionManager has no effect.
Internal connection pool does not correctly implement connection validation.
Contributed by Charles Lip <rene1 at singnet.com.sg>
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
-----Original Message-----
From: Mark A. Claassen [mailto:MClaassen@ocie.net]
Sent: Tuesday, May 12, 2015 8:58 AM
To: HttpClient User Discussion
Subject: RE: Strange SSL error
The scenario is that he logs in to our Swing application, there is a burst of transactions, maybe a slight pause, and then the next one fails. The whole process probably takes around 10 seconds. I was actually wondering if this had something to do with bad connections in the pool, but it is hard to say since I can't reproduce it reliably.
The communication is over SSL, and consists of readable XML and binary data. Most of the messages are < 10K, some bigger. We checked the firewall wall logs (since there is a firewall involved) and there is nothing. I connect through the same route and this never happens to me.
Thanks again,
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
-----Original Message-----
From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
Sent: Monday, May 11, 2015 5:15 PM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
What kind of data is being transfered? Do you tend to keep connections open for a long time? Firewall killing connections?
Sendt fra min iPhone
> Den 11. mai 2015 kl. 21.36 skrev Mark A. Claassen <MC...@ocie.net>:
>
> What would cause the reset, and what would make it so seemingly random? Is there something I am doing wrong? Is there a setting I can set so that this doesn't randomly happen to him? It is not too often, but often enough to be annoying and look like a failure in the application.
>
> Thanks
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
>
> -----Original Message-----
> From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> Sent: Friday, May 08, 2015 5:20 PM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> Looks like a tcp reset to me
>
> Sendt fra min iPhone
>
>> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MC...@ocie.net>:
>>
>> We are having one user that is getting this sporadically. No one else can reproduce it. Any idea what might be causing it? Because it is hard to reproduce, I am having trouble knowing where to start? Everyone else who tries has no issues. He logs into our application, which involves lots of small network transactions, and then the next thing he does often causes this. I think the situation would be that there is a lot of transactions very quickly, then a slight delay. After this, the next transaction fails, and then it will be fine. Any ideas?
>>
>>
>> ---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
>> Message (portal.cpfs.com:443 failed to respond)
>> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
>> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
>> at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
>> at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
>> at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
>> at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
>> at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
>> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
>> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
>> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>> Mark Claassen
>> Senior Software Engineer
>>
>> Donnell Systems, Inc.
>> 130 South Main Street
>> Leighton Plaza Suite 375
>> South Bend, IN 46601
>> E-mail: mailto:mclaassen@ocie.net
>> Voice: (574)232-3784
>> Fax: (574)232-4014
>>
>> -------------------------------------------
>> Confidentiality Notice: OCIESERVICE
>> -------------------------------------------
>> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��X��ܚX�KK[XZ[
� �Y[�
]\�\��][��X��ܚX�P˘\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[
� �Y[�
]\�\��Z[ ˘\X�K�ܙ�B�B
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
The scenario is that he logs in to our Swing application, there is a burst of transactions, maybe a slight pause, and then the next one fails. The whole process probably takes around 10 seconds. I was actually wondering if this had something to do with bad connections in the pool, but it is hard to say since I can't reproduce it reliably.
The communication is over SSL, and consists of readable XML and binary data. Most of the messages are < 10K, some bigger. We checked the firewall wall logs (since there is a firewall involved) and there is nothing. I connect through the same route and this never happens to me.
Thanks again,
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-------------------------------------------
Confidentiality Notice: OCIESERVICE
-------------------------------------------
The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
-----Original Message-----
From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
Sent: Monday, May 11, 2015 5:15 PM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
What kind of data is being transfered? Do you tend to keep connections open for a long time? Firewall killing connections?
Sendt fra min iPhone
> Den 11. mai 2015 kl. 21.36 skrev Mark A. Claassen <MC...@ocie.net>:
>
> What would cause the reset, and what would make it so seemingly random? Is there something I am doing wrong? Is there a setting I can set so that this doesn't randomly happen to him? It is not too often, but often enough to be annoying and look like a failure in the application.
>
> Thanks
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
>
> -----Original Message-----
> From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> Sent: Friday, May 08, 2015 5:20 PM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> Looks like a tcp reset to me
>
> Sendt fra min iPhone
>
>> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MC...@ocie.net>:
>>
>> We are having one user that is getting this sporadically. No one else can reproduce it. Any idea what might be causing it? Because it is hard to reproduce, I am having trouble knowing where to start? Everyone else who tries has no issues. He logs into our application, which involves lots of small network transactions, and then the next thing he does often causes this. I think the situation would be that there is a lot of transactions very quickly, then a slight delay. After this, the next transaction fails, and then it will be fine. Any ideas?
>>
>>
>> ---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
>> Message (portal.cpfs.com:443 failed to respond)
>> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
>> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
>> at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
>> at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
>> at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
>> at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
>> at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
>> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
>> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
>> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>> Mark Claassen
>> Senior Software Engineer
>>
>> Donnell Systems, Inc.
>> 130 South Main Street
>> Leighton Plaza Suite 375
>> South Bend, IN 46601
>> E-mail: mailto:mclaassen@ocie.net
>> Voice: (574)232-3784
>> Fax: (574)232-4014
>>
>> -------------------------------------------
>> Confidentiality Notice: OCIESERVICE
>> -------------------------------------------
>> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Stefan Magnus Landrø <st...@gmail.com>.
What kind of data is being transfered? Do you tend to keep connections open for a long time? Firewall killing connections?
Sendt fra min iPhone
> Den 11. mai 2015 kl. 21.36 skrev Mark A. Claassen <MC...@ocie.net>:
>
> What would cause the reset, and what would make it so seemingly random? Is there something I am doing wrong? Is there a setting I can set so that this doesn't randomly happen to him? It is not too often, but often enough to be annoying and look like a failure in the application.
>
> Thanks
>
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
>
> -----Original Message-----
> From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
> Sent: Friday, May 08, 2015 5:20 PM
> To: HttpClient User Discussion
> Subject: Re: Strange SSL error
>
> Looks like a tcp reset to me
>
> Sendt fra min iPhone
>
>> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MC...@ocie.net>:
>>
>> We are having one user that is getting this sporadically. No one else can reproduce it. Any idea what might be causing it? Because it is hard to reproduce, I am having trouble knowing where to start? Everyone else who tries has no issues. He logs into our application, which involves lots of small network transactions, and then the next thing he does often causes this. I think the situation would be that there is a lot of transactions very quickly, then a slight delay. After this, the next transaction fails, and then it will be fine. Any ideas?
>>
>>
>> ---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
>> Message (portal.cpfs.com:443 failed to respond)
>> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
>> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
>> at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
>> at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
>> at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
>> at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
>> at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
>> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
>> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
>> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>> Mark Claassen
>> Senior Software Engineer
>>
>> Donnell Systems, Inc.
>> 130 South Main Street
>> Leighton Plaza Suite 375
>> South Bend, IN 46601
>> E-mail: mailto:mclaassen@ocie.net
>> Voice: (574)232-3784
>> Fax: (574)232-4014
>>
>> -------------------------------------------
>> Confidentiality Notice: OCIESERVICE
>> -------------------------------------------
>> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Strange SSL error
Posted by "Mark A. Claassen" <MC...@ocie.net>.
What would cause the reset, and what would make it so seemingly random? Is there something I am doing wrong? Is there a setting I can set so that this doesn't randomly happen to him? It is not too often, but often enough to be annoying and look like a failure in the application.
Thanks
Mark Claassen
Senior Software Engineer
Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN 46601
E-mail: mailto:mclaassen@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
-----Original Message-----
From: Stefan Magnus Landrø [mailto:stefan.landro@gmail.com]
Sent: Friday, May 08, 2015 5:20 PM
To: HttpClient User Discussion
Subject: Re: Strange SSL error
Looks like a tcp reset to me
Sendt fra min iPhone
> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MC...@ocie.net>:
>
> We are having one user that is getting this sporadically. No one else can reproduce it. Any idea what might be causing it? Because it is hard to reproduce, I am having trouble knowing where to start? Everyone else who tries has no issues. He logs into our application, which involves lots of small network transactions, and then the next thing he does often causes this. I think the situation would be that there is a lot of transactions very quickly, then a slight delay. After this, the next transaction fails, and then it will be fine. Any ideas?
>
>
> ---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
> Message (portal.cpfs.com:443 failed to respond)
> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Strange SSL error
Posted by Stefan Magnus Landrø <st...@gmail.com>.
Looks like a tcp reset to me
Sendt fra min iPhone
> Den 8. mai 2015 kl. 22.49 skrev Mark A. Claassen <MC...@ocie.net>:
>
> We are having one user that is getting this sporadically. No one else can reproduce it. Any idea what might be causing it? Because it is hard to reproduce, I am having trouble knowing where to start? Everyone else who tries has no issues. He logs into our application, which involves lots of small network transactions, and then the next thing he does often causes this. I think the situation would be that there is a lot of transactions very quickly, then a slight delay. After this, the next transaction fails, and then it will be fine. Any ideas?
>
>
> ---- (1) ---- Throwable - Class (class org.apache.http.NoHttpResponseException)
> Message (portal.cpfs.com:443 failed to respond)
> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> Mark Claassen
> Senior Software Engineer
>
> Donnell Systems, Inc.
> 130 South Main Street
> Leighton Plaza Suite 375
> South Bend, IN 46601
> E-mail: mailto:mclaassen@ocie.net
> Voice: (574)232-3784
> Fax: (574)232-4014
>
> -------------------------------------------
> Confidentiality Notice: OCIESERVICE
> -------------------------------------------
> The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and its attachments. Do not deliver, distribute, copy, disclose the contents or take any action in reliance upon the information contained in the communication or any attachments.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org