On Mon, 2020-06-29 at 17:07 -0300, Pablo Caballero wrote:
> Hi! I'm using httpclient to consume a rest service. Everything was
> (is)
> working like a charm but we had an episode last week:
> 
> - After a short outage in our network (blaming this outage is an
> assumption
> I can't confirm) we got 16 threads stuck in our app server on:
> 
> "[STUCK] ExecuteThread: '45' for queue: 'weblogic.kernel.Default
> (self-tuning)'" #29841 daemon prio=1 os_prio=0 tid=0x00007f07ac1e1800
> rc="DOMAIN" ac=2 nid=0x8c6d runnable [0x00007f077c1de000]
>                java.lang.Thread.State: RUNNABLE
>                 at java.net.SocketInputStream.socketRead0(Native
> Method)
>                 at
> java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
>                 at
> java.net.SocketInputStream.read(SocketInputStream.java:170)
>                 at
> java.net.SocketInputStream.read(SocketInputStream.java:141)
>                 at
> sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>                 at
> sun.security.ssl.InputRecord.read(InputRecord.java:503)
>                 at
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>                 - locked <0x0000000093d38470> (a java.lang.Object)
>                 at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.
> java:1375)
>                 - locked <0x0000000093d38530> (a java.lang.Object)
>                 at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403
> )
>                 at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387
> )
>                 at
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSock
> et(SSLConnectionSocketFactory.java:394)
>                 at
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.upgrade
> (DefaultHttpClientConnectionOperator.java:185)
>                 at
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.upgrade(
> PoolingHttpClientConnectionManager.java:369)
>                 at
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClie
> ntExec.java:415)
> 
> - 16 was the value we used for defaultMaxPerRoute
> (org.apache.http.impl.conn.PoolingHttpClientConnectionManager) so it
> makes
> sense that we got 16
> threads stuck.
> 
> - All subsequent threads trying to get a connection got an exception
> (after
> X seconds with X equal to our value for connectionRequestTimeout) as
> expected.
> 
> - I think I've narrowed the problem down to this part of the code
> (MainClientExec class)
> 
> if (!managedConn.isOpen()) {
>                 this.log.debug("Opening connection " + route);
>                 try {
>                                 establishRoute(proxyAuthState,
> managedConn,
> route, request, context);
>                 } catch (final TunnelRefusedException ex) {
>                                 if (this.log.isDebugEnabled()) {
> 
> this.log.debug(ex.getMessage());
>                                 }
>                                 response = ex.getResponse();
>                                 break;
>                 }
> }
> 
> final int timeout = config.getSocketTimeout();
> if (timeout >= 0) {
>                 managedConn.setSocketTimeout(timeout);
> }
> 
> It seems like socket timeout is set after establishRoute so the SSL
> handshake isn't affected by this setting.
> 
> I am right?

You are right. This is expected. `RequestConfig` settings apply to the
request execution and the response processing. They do not apply to the
route negotiation. What are your `SocketConfig` settings?

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Reply via email to