RE: Question about max connections

[Joan grupoventus]

ed: Deadline: 
2023-06-26T08:48:49.445+, -2006 MILLISECONDS overdue
08:48:51.451
org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManager 
org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManager release 
413 ep-03 connection released [route: 
{}->http://receiver01:8080][total available: 1; route allocated: 1 of 1; total 
allocated: 1 of 1]
08:48:51.451org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient   
org.apache.hc.client5.http.impl.async.HttpAsyncClientProtocolNegotiationStarter$1
   onExchangeComplete  150 c-02 Connection is kept 
alive

So it works perfectly, 1 request sent OK and the another fails because 
max_connections was exceeded.

It seems that changing the maxConnectionPerRoute does not work on runtime ONLY 
when the concurrency policy is LAX.

Anyways maybe I'm doing something wrong ... just let me know what you think.

Thanks,

Joan.



-Original Message-
From: Oleg Kalnichevski  
Sent: Friday, June 23, 2023 12:04 PM
To: HttpClient User Discussion 
Subject: Re: Question about max connections

On Fri, 2023-06-23 at 11:52 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> In the lax mode the pool manager supports the per route max limit, but 
> not total max limit. The total max setting has no effect.
> --> Thanks, I can see that when I print the values, the total max is
> always 0.
> 
> But the question is if I can modify the per route max limit on the 
> fly, or after modifying it I need to restart the pool to apply the new 
> value.
> 

One can modify the per route max at runtime.

Oleg


> Thanks,
> 
> Joan.
> 
> -Original Message-
> From: Oleg Kalnichevski 
> Sent: Friday, June 23, 2023 11:28 AM
> To: HttpClient User Discussion 
> Subject: Re: Question about max connections
> 
> On Fri, 2023-06-23 at 11:23 +0200, Joan grupoventus wrote:
> > Hello,
> > 
> > We have an async http pool with LAX concurrency (httpclient 5.2.1):
> > this.phccm =
> > PoolingAsyncClientConnectionManagerBuilder.create().setPoolConcurre
> > nc
> > yPolicy(PoolConcurrencyPolicy.LAX).build();
> > 
> > We set the max connections in this way:
> > public void setMaxConnections(int maxConnections) {
> >   this.phccm.setMaxTotal(maxConnections);
> >   this.phccm.setDefaultMaxPerRoute(maxConnections);
> > }
> > 
> > I'm not sure if we are having an issue with this, but before 
> > starting to analyse http traces just one question: will it work to 
> > call the 'setMaxConnections' method to modify these parameters on 
> > the fly, or must I restart the pool to apply the new values?
> > 
> > Thanks,
> > 
> > Joan.
> > 
> 
> Hi Joan
> 
> In the lax mode the pool manager supports the per route max limit, but 
> not total max limit. The total max setting has no effect.
> 
> Oleg
> 
> 
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 


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




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

RE: Question about max connections

[Joan grupoventus]

Hi Oleg,

In the lax mode the pool manager supports the per route max limit, but not 
total max limit. The total max setting has no effect.
--> Thanks, I can see that when I print the values, the total max is always 0.

But the question is if I can modify the per route max limit on the fly, or 
after modifying it I need to restart the pool to apply the new value.

Thanks,

Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Friday, June 23, 2023 11:28 AM
To: HttpClient User Discussion 
Subject: Re: Question about max connections

On Fri, 2023-06-23 at 11:23 +0200, Joan grupoventus wrote:
> Hello,
> 
> We have an async http pool with LAX concurrency (httpclient 5.2.1):
> this.phccm =
> PoolingAsyncClientConnectionManagerBuilder.create().setPoolConcurrenc
> yPolicy(PoolConcurrencyPolicy.LAX).build();
> 
> We set the max connections in this way:
> public void setMaxConnections(int maxConnections) {
>   this.phccm.setMaxTotal(maxConnections);
>   this.phccm.setDefaultMaxPerRoute(maxConnections);
> }
> 
> I'm not sure if we are having an issue with this, but before starting 
> to analyse http traces just one question: will it work to call the 
> 'setMaxConnections' method to modify these parameters on the fly, or 
> must I restart the pool to apply the new values?
> 
> Thanks,
> 
> Joan.
> 

Hi Joan

In the lax mode the pool manager supports the per route max limit, but not 
total max limit. The total max setting has no effect.

Oleg


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




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

Question about max connections

[Joan grupoventus]

Hello,

We have an async http pool with LAX concurrency (httpclient 5.2.1):
this.phccm = 
PoolingAsyncClientConnectionManagerBuilder.create().setPoolConcurrencyPolicy(PoolConcurrencyPolicy.LAX).build();

We set the max connections in this way:
public void setMaxConnections(int maxConnections) {
  this.phccm.setMaxTotal(maxConnections);
  this.phccm.setDefaultMaxPerRoute(maxConnections);
}

I'm not sure if we are having an issue with this, but before starting to 
analyse http traces just one question: will it work to call the 
'setMaxConnections' method to modify these parameters on the fly, or must I 
restart the pool to apply the new values?

Thanks,

Joan.



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

RE: Httpclient issue with https "org.apache.hc.core5.http2.impl.nio.ClientH2StreamMultiplexer"

[Joan grupoventus]

Hi Oleg,

After changing this method from:
private TlsStrategy getTLSStrategy() throws Exception {
  return (DefaultClientTlsStrategy.getDefault());
}

To:
private TlsStrategy getTLSStrategy() throws Exception {
   return 
ClientTlsStrategyBuilder.create().setSslBufferMode(SSLBufferMode.DYNAMIC).build();
}

And set this strategy to the pool:
this.phccm = 
PoolingAsyncClientConnectionManagerBuilder.create().setPoolConcurrencyPolicy(PoolConcurrencyPolicy.LAX).setTlsStrategy(this.getTLSStrategy()).build();


The histogram shows the same:
num #instances #bytes  class name
--
   1:233151 3208489352  [B
   2:182882   52757328  


This chart shows the execution under http and the change to https at 11:23:35: 
http://www.grupoventus.com/resources/spike.png

With http, at the end of each GC cycle the amount of heap used is around 1,5GB.
At the moment we dynamically change to https you can see a spike from 3GB to 
7GB. Next GC cycles frees memory until around 5GB, and remains there. 

Here the chart with the execution already with https during several minutes, 
never lows from the 5GB:
http://www.grupoventus.com/resources/https.png

The point is that here traffic is very low, in production this traffic is much 
higher so the spike is about 20GB and the heap becomes exhausted.

Joan.


-Original Message-
From: Oleg Kalnichevski  
Sent: Friday, May 12, 2023 9:47 AM
To: HttpClient User Discussion 
Subject: Re: Httpclient issue with https 
"org.apache.hc.core5.http2.impl.nio.ClientH2StreamMultiplexer"

On Thu, 2023-05-11 at 19:17 +0200, Joan grupoventus wrote:
> Hello Oleg,
> 
> We are finding an issue in a new installation of our app that is using 
> httpclient5-5.2.1 and httpcore5-5.2.
> 
> Our app is a proxy that receives protobuf requests that are sent to an 
> amazon endpoint that is responding with protobuf responses. We started 
> this communication by using plain http, processing around
> 4.000 req/s. Everything OK.
> 
> But when we move to live https must be used to communicate with this 
> endpoint, just changing the url from http:// to https://
> 
> So we changed it and after 30 seconds testing we got an 
> OutOfMemoryException, the heap was exhausted.
> 
> Below an histogram using http (just the first 2 items):
> num #instances #bytes  class name
> --
>1:181753   52412760  
>2:218819   46398592  [B
> 
> 
> And the histogram using https after 30s:
> num #instances #bytes  class name
> --
>1:224873 3216328416  [B
>2:182417   52604088  
> 
> 
> So the space occupied by byte arrays moves from 46Mb to 3GB. So we 
> decided to perform a heap dump and analyze it to find out where these 
> 3GB byte arrays are coming from, and we have seen this:
> 
> 178 instances of
> "org.apache.hc.core5.http2.impl.nio.ClientH2StreamMultiplexer",
> loaded by "org.apache.catalina.loader.ParallelWebappClassLoader @ 
> 0x400768258e8" occupy 2.999.171.840 (88,20 %) bytes 
> http://www.grupoventus.com/resources/top_dominator_class.png
> 
> 
> If we analyze each one of these 178 instances of 
> ClientH2StreamMultiplexer, it seems the OutputBuffer is holding around 
> 16Mb for each instance, multiplied by 178 gives as a result these 3GB:
> http://www.grupoventus.com/resources/output_buffer.png
> 
> 
> I’m not sure if this is a bug, we have been using https with these 
> same versions against other endpoints and we never had a problem.
> Anyways it does not seem a memory leak, because if you keep the 
> traffic stable, the space occupied by these instances seems to not be 
> growing.
> 
> Let me know what you think, and if you need more information (logs 
> about http traffic, etc).
> 
> Thanks,
> 
> Joan.
> 

Hi Joan

This sounds odd. I see no reason why FrameOutputBuffer should ever grow beyond 
the size of the maximum frame size and do not see how this could be possibly be 
related to TLS. Nevertheless, this may well be a bug that gets triggered by the 
use of the transport encryption. 

Please do one thing, though, first. Please make sure you configure the I/O 
reactors to use a custom TLS strategy with SSLBufferMode set to DYNAMIC. This 
will make the I/O reactor release intermediate TLS buffers which should 
substantially decrease the total memory footprint of TLS connections at the 
cost of extra memory allocation / de- allocation.

Oleg 


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




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

Httpclient issue with https "org.apache.hc.core5.http2.impl.nio.ClientH2StreamMultiplexer"

[Joan grupoventus]

Hello Oleg,

We are finding an issue in a new installation of our app that is using 
httpclient5-5.2.1 and httpcore5-5.2.

Our app is a proxy that receives protobuf requests that are sent to an amazon 
endpoint that is responding with protobuf responses. We started this 
communication by using plain http, processing around 4.000 req/s. Everything OK.

But when we move to live https must be used to communicate with this endpoint, 
just changing the url from http:// to https://

So we changed it and after 30 seconds testing we got an OutOfMemoryException, 
the heap was exhausted.

Below an histogram using http (just the first 2 items):
num #instances #bytes  class name
--
   1:181753   52412760  
   2:218819   46398592  [B


And the histogram using https after 30s:
num #instances #bytes  class name
--
   1:224873 3216328416  [B
   2:182417   52604088  


So the space occupied by byte arrays moves from 46Mb to 3GB. So we decided to 
perform a heap dump and analyze it to find out where these 3GB byte arrays are 
coming from, and we have seen this:

178 instances of 
"org.apache.hc.core5.http2.impl.nio.ClientH2StreamMultiplexer", loaded by 
"org.apache.catalina.loader.ParallelWebappClassLoader @ 0x400768258e8" occupy 
2.999.171.840 (88,20 %) bytes
http://www.grupoventus.com/resources/top_dominator_class.png


If we analyze each one of these 178 instances of ClientH2StreamMultiplexer, it 
seems the OutputBuffer is holding around 16Mb for each instance, multiplied by 
178 gives as a result these 3GB:
http://www.grupoventus.com/resources/output_buffer.png


I’m not sure if this is a bug, we have been using https with these same 
versions against other endpoints and we never had a problem. Anyways it does 
not seem a memory leak, because if you keep the traffic stable, the space 
occupied by these instances seems to not be growing.

Let me know what you think, and if you need more information (logs about http 
traffic, etc).

Thanks,

Joan.






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

Response buffer size

[Joan grupoventus]

Hello,

 �

I’m using HttpClient 4.5.7. reading responses from a backend through a 
‘HttpAsyncResponseConsumer’ on the ‘consumeContent’ method  in this way:

 �

while ( (numBytesRead = decoder.read(this.bbuf)) > 0 ) {

( . . . )

}

  

where  this.bbuf = ByteBuffer.allocate(32768);

  

  

The buffer size in the async http instance is configured in this way (‘phccm’ 
is  a ‘PoolingNHttpClientConnectionManager’):

this.phccm.setDefaultConnectionConfig(ConnectionConfig.custom().setBufferSize(32768).setFragmentSizeHint(32768).build()

  

And on the IOReactor:

IOReactorConfig ioReactorConfig = IOReactorConfig.custom().setRcvBufSize(32768) 
...

  

  

But when we start reading the response on the consume content method, the byte 
buffer is filled out just with 16K of data:

Cycle 0 :: bytes read = 15812, total size (K) = 15

Cycle 1 :: bytes read = 16368, total size (K) = 31

Cycle 2 :: bytes read = 16376, total size (K) = 47

Cycle 3 :: bytes read = 16384, total size (K) = 63

Cycle 4 :: bytes read = 16376, total size (K) = 79

Cycle 5 :: bytes read = 16384, total size (K) = 95

Cycle 6 :: bytes read = 16376, total size (K) = 111

Cycle 7 :: bytes read = 16384, total size (K) = 127

 �

What am I missing?

 �

Thanks,

 �

Joan.

 �

RE: Issue sending https to an http endpoint

[Joan grupoventus]

Hi,

Ok, I will have to wait for my docker expert to return from his holidays this 
September. When he's back we will build the container.

Thanks,
Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Tuesday, August 27, 2019 11:30 AM
To: HttpClient User Discussion 
Subject: Re: Issue sending https to an http endpoint

On Tue, 2019-08-27 at 11:27 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> I uploaded the httpcore-5b9 we generated to the git. Is it possible 
> you download it and try just one test with async Http5 to check if it 
> works for you?
> We have checked the jar and it seems to be correct, so if you are 
> using the same version I don't understand why it works for you and not 
> for us.
> 
> Thanks,
> Joan.
> 

Could you please try to reproduce the issue inside a docker container?

Oleg



> -Original Message-
> From: Oleg Kalnichevski 
> Sent: Friday, August 23, 2019 5:32 PM
> To: HttpClient User Discussion 
> Subject: Re: Issue sending https to an http endpoint
> 
> On Fri, 2019-08-23 at 17:24 +0200, Joan grupoventus wrote:
> > Hi Oleg,
> > 
> > Is this the right link to build the httpcore-b9? 
> > https://github.com/apache/httpcomponents-core
> > 
> 
> Yes, it is. 
> 
> Oleg
> 
> > We checked the version of our jar and it seems to be correctly. Is 
> > there something else we have to build? We are already using the 
> > latest httpclient (httpclient5-5.0-beta5)
> > 
> > Thanks,
> > Joan.
> > 
> > -Original Message-
> > From: Oleg Kalnichevski 
> > Sent: Friday, August 23, 2019 9:49 AM
> > To: HttpClient User Discussion 
> > Subject: Re: Issue sending https to an http endpoint
> > 
> > On Thu, 2019-08-22 at 23:12 +0200, Joan grupoventus wrote:
> > > Hi Oleg,
> > > 
> > > Well, not sure what's happening.  In "our" git
> > > (https://github.com/joanbalaguero/HttpClient)  I have uploaded  4 
> > > files that connect by https to the problematic url.
> > > 
> > > The "TestSync" is using a sync http5 client and works, ends with 
> > > an exception "javax.net.ssl.SSLException: Unrecognized SSL 
> > > message, plaintext connection?"
> > > The " TestAsync41ResponseConsumer.java" is using the async http
> > > 4.1.3
> > > client with an "HttpAsyncResponseConsumer" and works, ends with an 
> > > exception
> > > "javax.net.ssl.SSLException: Unrecognized SSL message, plaintext 
> > > connection?"
> > > 
> > > The "TestAsync5FutureCallback" and "TestAsync5ResponseConsumer"
> > > are
> > > using an async http5 client (httpclient5-5-beta5 and 
> > > httpcore5-5-beta9), the first one with a 
> > > "FutureCallback" and the second with a 
> > > "AsyncResponseConsumer". Both hang forever.
> > > 
> > > So if this is not a bug in http5, what's wrong with these two last 
> > > samples?
> > > The code there is minimal. 
> > > 
> > 
> > Joan,
> > 
> > I see nothing wrong with those samples and they all work for me 
> > (HttpClient 5.0b5 + HttpCore 5.0b9-SNAPSHOT).
> > 
> > Oleg
> > ---
> > 2019-08-23 09:46:30,669 DEBUG
> > [main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClien
> > t]
> > ex-0001: preparing request execution
> > 2019-08-23 09:46:30,676 DEBUG
> > [main][org.apache.hc.client5.http.protocol.RequestAddCookies]
> > CookieSpec selected: standard
> > 2019-08-23 09:46:30,680 DEBUG
> > [main][org.apache.hc.client5.http.protocol.RequestAuthCache] Auth 
> > cache not set in the context
> > 2019-08-23 09:46:30,680 DEBUG
> > [main][org.apache.hc.client5.http.impl.async.AsyncProtocolExec] ex-
> > 0001: target auth state: UNCHALLENGED
> > 2019-08-23 09:46:30,681 DEBUG
> > [main][org.apache.hc.client5.http.impl.async.AsyncProtocolExec] ex-
> > 0001: proxy auth state: UNCHALLENGED
> > 2019-08-23 09:46:30,683 DEBUG
> > [main][org.apache.hc.client5.http.impl.async.AsyncConnectExec] ex-
> > 0001: acquiring connection with route {s}->
> > https://54.38.179.182:8083
> > 2019-08-23 09:46:30,684 DEBUG
> > [main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClien
> > t]
> > ex-0001: acquiring endpoint (3 MINUTES)
> > 2019-08-23 09:46:30,685 DEBUG
> > [main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnec
> > ti
> > onManager] ex-0001: endpoint lease request (3 MINUTES)

RE: Issue sending https to an http endpoint

[Joan grupoventus]

Hi Oleg,

I uploaded the httpcore-5b9 we generated to the git. Is it possible you 
download it and try just one test with async Http5 to check if it works for you?
We have checked the jar and it seems to be correct, so if you are using the 
same version I don't understand why it works for you and not for us.

Thanks,
Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Friday, August 23, 2019 5:32 PM
To: HttpClient User Discussion 
Subject: Re: Issue sending https to an http endpoint

On Fri, 2019-08-23 at 17:24 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> Is this the right link to build the httpcore-b9? 
> https://github.com/apache/httpcomponents-core
> 

Yes, it is. 

Oleg

> We checked the version of our jar and it seems to be correctly. Is 
> there something else we have to build? We are already using the latest 
> httpclient (httpclient5-5.0-beta5)
> 
> Thanks,
> Joan.
> 
> -Original Message-
> From: Oleg Kalnichevski 
> Sent: Friday, August 23, 2019 9:49 AM
> To: HttpClient User Discussion 
> Subject: Re: Issue sending https to an http endpoint
> 
> On Thu, 2019-08-22 at 23:12 +0200, Joan grupoventus wrote:
> > Hi Oleg,
> > 
> > Well, not sure what's happening.  In "our" git
> > (https://github.com/joanbalaguero/HttpClient)  I have uploaded  4 
> > files that connect by https to the problematic url.
> > 
> > The "TestSync" is using a sync http5 client and works, ends with an 
> > exception "javax.net.ssl.SSLException: Unrecognized SSL message, 
> > plaintext connection?"
> > The " TestAsync41ResponseConsumer.java" is using the async http
> > 4.1.3
> > client with an "HttpAsyncResponseConsumer" and works, ends with an 
> > exception
> > "javax.net.ssl.SSLException: Unrecognized SSL message, plaintext 
> > connection?"
> > 
> > The "TestAsync5FutureCallback" and "TestAsync5ResponseConsumer"
> > are
> > using an async http5 client (httpclient5-5-beta5 and 
> > httpcore5-5-beta9), the first one with a 
> > "FutureCallback" and the second with a 
> > "AsyncResponseConsumer". Both hang forever.
> > 
> > So if this is not a bug in http5, what's wrong with these two last 
> > samples?
> > The code there is minimal. 
> > 
> 
> Joan,
> 
> I see nothing wrong with those samples and they all work for me 
> (HttpClient 5.0b5 + HttpCore 5.0b9-SNAPSHOT).
> 
> Oleg
> ---
> 2019-08-23 09:46:30,669 DEBUG
> [main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient]
> ex-0001: preparing request execution
> 2019-08-23 09:46:30,676 DEBUG
> [main][org.apache.hc.client5.http.protocol.RequestAddCookies]
> CookieSpec selected: standard
> 2019-08-23 09:46:30,680 DEBUG
> [main][org.apache.hc.client5.http.protocol.RequestAuthCache] Auth 
> cache not set in the context
> 2019-08-23 09:46:30,680 DEBUG
> [main][org.apache.hc.client5.http.impl.async.AsyncProtocolExec] ex-
> 0001: target auth state: UNCHALLENGED
> 2019-08-23 09:46:30,681 DEBUG
> [main][org.apache.hc.client5.http.impl.async.AsyncProtocolExec] ex-
> 0001: proxy auth state: UNCHALLENGED
> 2019-08-23 09:46:30,683 DEBUG
> [main][org.apache.hc.client5.http.impl.async.AsyncConnectExec] ex-
> 0001: acquiring connection with route {s}->
> https://54.38.179.182:8083
> 2019-08-23 09:46:30,684 DEBUG
> [main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient]
> ex-0001: acquiring endpoint (3 MINUTES)
> 2019-08-23 09:46:30,685 DEBUG
> [main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnecti
> onManager] ex-0001: endpoint lease request (3 MINUTES) [route:
> {s}->https://54.38.179.182:8083][total kept alive: 0; route
> allocated: 0 of 5; total allocated: 0 of 25]
> 2019-08-23 09:46:30,689 DEBUG
> [main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnecti
> onManager] ex-0001: endpoint leased [route: {s}-> 
> https://54.38.179.182:8083][total kept alive: 0; route allocated: 1 of 
> 5; total allocated: 1 of 25]
> 2019-08-23 09:46:30,690 DEBUG
> [main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnecti
> onManager] ex-0001: acquired ep-
> 2019-08-23 09:46:30,690 DEBUG
> [main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient]
> ex-0001: acquired endpoint ep-
> 2019-08-23 09:46:30,691 DEBUG
> [main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient]
> ep-: connecting endpoint (3 MINUTES)
> 2019-08-23 09:46:30,692 DEBUG
> [main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnecti
> onManager] ep-: connect

RE: Issue sending https to an http endpoint

[Joan grupoventus]

Hi Oleg,

Is this the right link to build the httpcore-b9? 
https://github.com/apache/httpcomponents-core

We checked the version of our jar and it seems to be correctly. Is there 
something else we have to build? We are already using the latest httpclient 
(httpclient5-5.0-beta5)

Thanks,
Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Friday, August 23, 2019 9:49 AM
To: HttpClient User Discussion 
Subject: Re: Issue sending https to an http endpoint

On Thu, 2019-08-22 at 23:12 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> Well, not sure what's happening.  In "our" git
> (https://github.com/joanbalaguero/HttpClient)  I have uploaded  4 
> files that connect by https to the problematic url.
> 
> The "TestSync" is using a sync http5 client and works, ends with an 
> exception "javax.net.ssl.SSLException: Unrecognized SSL message, 
> plaintext connection?"
> The " TestAsync41ResponseConsumer.java" is using the async http 4.1.3 
> client with an "HttpAsyncResponseConsumer" and works, ends with an 
> exception
> "javax.net.ssl.SSLException: Unrecognized SSL message, plaintext 
> connection?"
> 
> The "TestAsync5FutureCallback" and "TestAsync5ResponseConsumer" are 
> using an async http5 client (httpclient5-5-beta5 and 
> httpcore5-5-beta9), the first one with a 
> "FutureCallback" and the second with a 
> "AsyncResponseConsumer". Both hang forever.
> 
> So if this is not a bug in http5, what's wrong with these two last 
> samples?
> The code there is minimal. 
> 

Joan,

I see nothing wrong with those samples and they all work for me (HttpClient 
5.0b5 + HttpCore 5.0b9-SNAPSHOT).

Oleg
---
2019-08-23 09:46:30,669 DEBUG 
[main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient] 
ex-0001: preparing request execution
2019-08-23 09:46:30,676 DEBUG 
[main][org.apache.hc.client5.http.protocol.RequestAddCookies] CookieSpec 
selected: standard
2019-08-23 09:46:30,680 DEBUG 
[main][org.apache.hc.client5.http.protocol.RequestAuthCache] Auth cache not set 
in the context
2019-08-23 09:46:30,680 DEBUG 
[main][org.apache.hc.client5.http.impl.async.AsyncProtocolExec] ex-0001: 
target auth state: UNCHALLENGED
2019-08-23 09:46:30,681 DEBUG 
[main][org.apache.hc.client5.http.impl.async.AsyncProtocolExec] ex-0001: 
proxy auth state: UNCHALLENGED
2019-08-23 09:46:30,683 DEBUG 
[main][org.apache.hc.client5.http.impl.async.AsyncConnectExec] ex-0001: 
acquiring connection with route {s}->https://54.38.179.182:8083
2019-08-23 09:46:30,684 DEBUG 
[main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient] 
ex-0001: acquiring endpoint (3 MINUTES)
2019-08-23 09:46:30,685 DEBUG 
[main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManager] 
ex-0001: endpoint lease request (3 MINUTES) [route: 
{s}->https://54.38.179.182:8083][total kept alive: 0; route allocated: 0 of 5; 
total allocated: 0 of 25]
2019-08-23 09:46:30,689 DEBUG 
[main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManager] 
ex-0001: endpoint leased [route: {s}->https://54.38.179.182:8083][total 
kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 25]
2019-08-23 09:46:30,690 DEBUG 
[main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManager] 
ex-0001: acquired ep-
2019-08-23 09:46:30,690 DEBUG 
[main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient] 
ex-0001: acquired endpoint ep-
2019-08-23 09:46:30,691 DEBUG 
[main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient] 
ep-: connecting endpoint (3 MINUTES)
2019-08-23 09:46:30,692 DEBUG 
[main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManager] 
ep-: connecting endpoint to https://54.38.179.182:8083 (3 MINUTES)
2019-08-23 09:46:30,692 DEBUG 
[main][org.apache.hc.client5.http.impl.nio.MultihomeIOSessionRequester] 
https://54.38.179.182:8083: resolving remote address
2019-08-23 09:46:30,692 DEBUG 
[main][org.apache.hc.client5.http.impl.nio.MultihomeIOSessionRequester] 
https://54.38.179.182:8083: resolved to [/54.38.179.182]
2019-08-23 09:46:30,693 DEBUG 
[main][org.apache.hc.client5.http.impl.nio.MultihomeIOSessionRequester] 
https://54.38.179.182:8083: connecting null to /54.38.179.182:8083 (3 MINUTES)
2019-08-23 09:46:30,907 DEBUG 
[httpclient-dispatch-1][org.apache.hc.client5.http.impl.nio.MultihomeIOSessionRequester]
 https://54.38.179.182:8083: connected i/o- 
/192.168.43.142:48810->/54.38.179.182:8083
2019-08-23 09:46:30,912 DEBUG 
[httpclient-dispatch-1][org.apache.hc.client5.http.impl.nio.DefaultManagedAsyncClientConnection]
 i/o-: start TLS
2019-08-23 09:46:30,963 DEBUG 
[httpclient-dispatch-1][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManager]
 ep-: connec

RE: Issue sending https to an http endpoint

[Joan grupoventus]

Hi Oleg,

Well, not sure what's happening.  In "our" git
(https://github.com/joanbalaguero/HttpClient)  I have uploaded  4 files that
connect by https to the problematic url.

The "TestSync" is using a sync http5 client and works, ends with an
exception "javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?" 
The " TestAsync41ResponseConsumer.java" is using the async http 4.1.3 client
with an "HttpAsyncResponseConsumer" and works, ends with an exception
"javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?"

The "TestAsync5FutureCallback" and "TestAsync5ResponseConsumer" are using an
async http5 client (httpclient5-5-beta5 and httpcore5-5-beta9), the first
one with a "FutureCallback" and the second with a
"AsyncResponseConsumer". Both hang forever.

So if this is not a bug in http5, what's wrong with these two last samples?
The code there is minimal. 

Thanks,
Joan.


-Original Message-
From: Oleg Kalnichevski  
Sent: Thursday, August 22, 2019 12:05 PM
To: HttpClient User Discussion 
Subject: Re: Issue sending https to an http endpoint

On Wed, 2019-08-21 at 22:24 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> Tried with httpcore5-5.0-beta9.jar. The same result.
> 

I am sorry, Joan, but I am unable to reproduce the problem with HttpClient
5.0-beta5 and the latest HttpCore 5.0-beta9-SNAPSHOT. It works as expected
for me.

Oleg 

---
2019-08-22 12:02:43,978 DEBUG
[main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient]
ex-0001: preparing request execution
2019-08-22 12:02:43,986 DEBUG
[main][org.apache.hc.client5.http.protocol.RequestAddCookies] CookieSpec
selected: standard
2019-08-22 12:02:43,990 DEBUG
[main][org.apache.hc.client5.http.protocol.RequestAuthCache] Auth cache not
set in the context
2019-08-22 12:02:43,991 DEBUG
[main][org.apache.hc.client5.http.impl.async.AsyncProtocolExec] ex-0001:
target auth state: UNCHALLENGED
2019-08-22 12:02:43,991 DEBUG
[main][org.apache.hc.client5.http.impl.async.AsyncProtocolExec] ex-0001:
proxy auth state: UNCHALLENGED
2019-08-22 12:02:43,993 DEBUG
[main][org.apache.hc.client5.http.impl.async.AsyncConnectExec] ex-0001:
acquiring connection with route {s}->https://localhost:8080
2019-08-22 12:02:43,993 DEBUG
[main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient]
ex-0001: acquiring endpoint (3 MINUTES)
2019-08-22 12:02:43,995 DEBUG
[main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManag
er] ex-0001: endpoint lease request (3 MINUTES) [route:
{s}->https://localhost:8080][total kept alive: 0; route allocated: 0 of 5;
total allocated: 0 of 25]
2019-08-22 12:02:43,998 DEBUG
[main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManag
er] ex-0001: endpoint leased [route: {s}->https://localhost:8080][total
kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 25]
2019-08-22 12:02:43,998 DEBUG
[main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManag
er] ex-0001: acquired ep-
2019-08-22 12:02:43,999 DEBUG
[main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient]
ex-0001: acquired endpoint ep-
2019-08-22 12:02:43,999 DEBUG
[main][org.apache.hc.client5.http.impl.async.InternalHttpAsyncClient]
ep-: connecting endpoint (3 MINUTES)
2019-08-22 12:02:44,000 DEBUG
[main][org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManag
er] ep-: connecting endpoint to https://localhost:8080 (3 MINUTES)
2019-08-22 12:02:44,000 DEBUG
[main][org.apache.hc.client5.http.impl.nio.MultihomeIOSessionRequester]
https://localhost:8080: resolving remote address
2019-08-22 12:02:44,001 DEBUG
[main][org.apache.hc.client5.http.impl.nio.MultihomeIOSessionRequester]
https://localhost:8080: resolved to [localhost/127.0.0.1]
2019-08-22 12:02:44,001 DEBUG
[main][org.apache.hc.client5.http.impl.nio.MultihomeIOSessionRequester]
https://localhost:8080: connecting null to localhost/127.0.0.1:8080 (3
MINUTES)
2019-08-22 12:02:44,023 DEBUG
[httpclient-dispatch-1][org.apache.hc.client5.http.impl.nio.MultihomeIOSessi
onRequester] https://localhost:8080: connected i/o-
/127.0.0.1:50902->localhost/127.0.0.1:8080
2019-08-22 12:02:44,025 DEBUG
[httpclient-dispatch-1][org.apache.hc.client5.http.impl.nio.DefaultManagedAs
yncClientConnection] i/o-: start TLS
2019-08-22 12:02:44,042 DEBUG
[httpclient-dispatch-1][org.apache.hc.client5.http.impl.nio.PoolingAsyncClie
ntConnectionManager] ep-: connected i/o-
2019-08-22 12:02:44,042 DEBUG
[httpclient-dispatch-1][org.apache.hc.client5.http.impl.async.InternalHttpAs
yncClient] ep-: endpoint connected
2019-08-22 12:02:44,043 DEBUG
[httpclient-dispatch-1][org.apache.hc.client5.http.impl.async.AsyncConnectEx
ec] ex-0001: connected to target
2019-08-22 12:02:44,043 DEBUG

RE: Issue sending https to an http endpoint

[Joan grupoventus]

Hi Oleg,

Tried with httpcore5-5.0-beta9.jar. The same result.

Thanks,
Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Monday, August 19, 2019 9:15 AM
To: HttpClient User Discussion 
Subject: Re: Issue sending https to an http endpoint

On Sun, 2019-08-18 at 21:05 +0200, Joan grupoventus wrote:
> Hello,
> 
>   
> 
> A mistake made by one of our clients has brought us a possible issue 
> to our attention. We have been able to reproduce it on our test 
> environment.
> 
>   
> 
> The client has an endpoint that only listens on http connections on 
> ports 8080,8081,8082 and 8083. By mistake all traffic from our gateway 
> to their backend has been sent by https instead of http, and this 
> provoked the pool to have all connections allocated (pool exhausted).
> 

Hi Joan

I think this issue has already been resolved in HttpCore master. Could you 
please try to reproduce the issue the latest HttpCore snapshot? You will need 
to build HttpCore from source to do so.

https://github.com/apache/httpcomponents-core

Oleg

>   
> 
> We have tried to send https requests to an http endpoint using post 
> methods through a “  INF%5C/lib%5C/httpclient5-5.0-beta5.jar%3Corg> org.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache> apache.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc> hc.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc.client5> client5.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc.client5.http> http.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc.client5.http.impl> impl.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc.client5.http.impl.io>
> io.PoolingHttpClientConnectionManager”. Just send the request 
> synchronously and await the response … and the error we immediately 
> get is: javax.net.ssl.SSLException: Unrecognized SSL message, 
> plaintext connection?
> 
>   
> 
> That’s ok. Now we have tried the real situation, sending a request 
> asynchronously to the same endpoint using a “  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg> org.  INF%5C/lib%5C/httpclient5-5.0-beta5.jar%3Corg.apache> apache.
>  5.0-beta5.jar%3Corg.apache.hc> hc.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc.client5> client5.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc.client5.http> http.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc.client5.http.impl> impl.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpclient5-5.0-
> beta5.jar%3Corg.apache.hc.client5.http.impl.nio>
> nio.PoolingAsyncClientConnectionManager” and trying to manage the 
> response in a “  INF%5C/lib%5C/httpcore5-5.0-beta8.jar%3Corg> org.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpcore5-5.0-
> beta8.jar%3Corg.apache> apache.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpcore5-5.0-
> beta8.jar%3Corg.apache.hc> hc.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpcore5-5.0-
> beta8.jar%3Corg.apache.hc.core5> core5.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpcore5-5.0-
> beta8.jar%3Corg.apache.hc.core5.http> http.  javadoc:%E2%98%82=vpfw/web%5C/WEB-INF%5C/lib%5C/httpcore5-5.0-
> beta8.jar%3Corg.apache.hc.core5.http.nio> nio.AsyncResponseConsumer”.
> The result is the request never finishes (the thread is only released 
> when the container asynchronous timeout is reached) and the connection 
> is never returned to the pool.
> 
>   
> 
> This is the trace for the first request sent at 20:30:51 that finished 
> after 120s when the container asynchronous timeout was
> reached:
> 
>   
> 
> App trace:
> 
> 20:30:51.379,120419,response.noResponse,20:32:51.798
> 
>   
> 
> Http5 trace:
> 
> 20:30:51.381   ex-0004: preparing request execution
> 
> 20:30:51.381   ex-0004: target auth state: UNCHALLENGED
> 
> 20:30:51.381   ex-0004: proxy auth state: UNCHALLENGED
> 
> 20:30:51.381   ex-0004: acquiring connection with route {s}->
> https://54.38.179.182:8080
> 
> 20:30:51.381   ex-0004: acquiring endpoint (1 MILLISECONDS)
> 
> 20:30:51.382   ex-0004: endpoint lease request (1
> MILLISECONDS) [route: {s}->https://54.38.179.182:8080][total kept
> alive: 0; route allocated: 0 of 50; total allocated: 0 of 50]
> 
> 20:30:51.382   ex-0004: endpoint leased [route: {s}-> 
> https://54.38.179.182:8080][total k

Issue sending https to an http endpoint

[Joan grupoventus]

Hello,

 �

A mistake made by one of our clients has brought us a possible issue to our 
attention. We have been able to reproduce it on our test environment.

 �

The client has an endpoint that only listens on http connections on ports 
8080,8081,8082 and 8083. By mistake all traffic from our gateway to their 
backend has been sent by https instead of http, and this provoked the pool to 
have all connections allocated (pool exhausted).

 �

We have tried to send https requests to an http endpoint using post methods 
through a “ 

 org. 

 apache. 

 hc. 

 client5. 

 http. 

 impl. 

 io.PoolingHttpClientConnectionManager”. Just send the request synchronously 
and await the response … and the error we immediately get is: 
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

 �

That’s ok. Now we have tried the real situation, sending a request 
asynchronously to the same endpoint using a “ 

 org. 

 apache. 

 hc. 

 client5. 

 http. 

 impl. 

 nio.PoolingAsyncClientConnectionManager” and trying to manage the response in 
a “ 

 org. 

 apache. 

 hc. 

 core5. 

 http. 

 nio.AsyncResponseConsumer”. The result is the request never finishes (the 
thread is only released when the container asynchronous timeout is reached) and 
the connection is never returned to the pool. 

 �

This is the trace for the first request sent at 20:30:51 that finished after 
120s when the container asynchronous timeout was reached:

 �

App trace:

20:30:51.379,120419,response.noResponse,20:32:51.798

 �

Http5 trace:

20:30:51.381 � � � ex-0004: preparing request execution

20:30:51.381 � � � ex-0004: target auth state: UNCHALLENGED

20:30:51.381 � � � ex-0004: proxy auth state: UNCHALLENGED

20:30:51.381 � � � ex-0004: acquiring connection with route 
{s}->https://54.38.179.182:8080

20:30:51.381 � � � ex-0004: acquiring endpoint (1 MILLISECONDS)

20:30:51.382 � � � ex-0004: endpoint lease request (1 MILLISECONDS) [route: 
{s}->https://54.38.179.182:8080][total kept alive: 0; route allocated: 0 of 50; 
total allocated: 0 of 50]

20:30:51.382 � � � ex-0004: endpoint leased [route: 
{s}->https://54.38.179.182:8080][total kept alive: 0; route allocated: 1 of 50; 
total allocated: 1 of 50]

20:30:51.382 � � � ex-0004: acquired ep-0003

20:30:51.382 � � � ex-0004: acquired endpoint ep-0003

20:30:51.382 � � � ep-0003: connecting endpoint (2,000 MILLISECONDS)

20:30:51.382 � � � ep-0003: connecting endpoint to 
https://54.38.179.182:8080 (2,000 MILLISECONDS)

20:30:51.382 � � � https://54.38.179.182:8080: resolving remote address

20:30:51.382 � � � https://54.38.179.182:8080: resolved to [/54.38.179.182]

20:30:51.382 � � � https://54.38.179.182:8080: connecting null to 
/54.38.179.182:8080 (2,000 MILLISECONDS)

20:30:51.383 � � � https://54.38.179.182:8080: connected i/o-0003 
/54.36.51.138:45374->/54.38.179.182:8080

20:30:51.383 � � � i/o-0003: start TLS

20:30:51.383 � � � ep-0003: connected i/o-0003

20:30:51.383 � � � ep-0003: endpoint connected

20:30:51.383 � � � ex-0004: connected to target

20:30:51.383 � � � ex-0004: route fully established

20:30:51.383 � � � ex-0004: executing POST /serhs HTTP/1.1

20:30:51.383 � � � ep-0003: start execution ex-0004

20:30:51.383 � � � ep-0003: executing exchange ex-0004 over i/o-0003

20:30:51.383 � � � i/o-0003: RequestExecutionCommand with NORMAL priority

20:30:51.383 � � � Enabled protocols: [TLSv1.2]

20:30:51.383 � � � Enabled cipher 
suites:[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, 
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256]

 �

 �

And this is the trace for the second request sent at 20:30:51. A second 
connection is allocated:

 �

App trace:

20:33:11.636,120173,response.noResponse,20:35:11.809

 �

Http5 trace:

20:33:11.638 � � � ex-0005: preparing request execution

20:33:11.638 � � � ex-0005: target auth state: UNCHALLENGED

20:33:11.638 � � � ex-0005: proxy auth state: UNCHALLENGED

20:33:11.638 � � � ex-0005: acquiring connection with route 
{s}->https://54.38.179.182:8081

20:33:11.638 � � � ex-0005: acquiring endpoint (1 MILLISECONDS)

20:33:11.638 � � � ex-0005: endpoint lease request (1 MILLISECONDS) [route: 
{s}->https://54.38.179.182:8081][total kept alive: 0; route allocated: 0 of 50; 
total allocated: 1 of 50]

20:33:11.638 � � � ex-0005: endpoint leased [route: 
{s}->https://54.38.179.182:8081][total kept alive: 0; route allocated: 1 of 50; 
total allocated: 2 of 50]

20:33:11.638 � � � ex-0005: acquired ep-0004

20:33:11.639 � � � ex-0005: acquired endpoint ep-0004

20:33:11.639 � � � ep-0004: connecting endpoint (2,000 MILLISECONDS)

20:33:11.639 � � 

RE: AsyncRequestBuilder deprecated

[Joan grupoventus]

Hello,

 �

It seems I should use the 
‘org.apache.hc.core5.http.nio.support.AsyncRequestBuilder’ class. Replacing the 
import works except for the ‘setConfig’ method that we use to replace the 
connection/response timeout for each request sent to the backend. What should I 
use now to replace these 2 values at request level?

 �

Thanks,

Joan.

 �

From: Joan grupoventus  
Sent: Thursday, August 1, 2019 10:20 AM
To: 'HttpClient User Discussion' 
Subject: AsyncRequestBuilder deprecated

 �

Hello,

 �

With the latest HttpClient5 release the AsyncRequestBuilder class is 
deprecated. Checking the api docs it’s telling to use ‘AsyncRequestBuilder’

 �

org.apache.hc.client5.http.async.methods


Class AsyncRequestBuilder


* 
<https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html?is-external=true>
 java.lang.Object

*org.apache.hc.client5.http.async.methods.AsyncRequestBuilder

Deprecated.  

Use  AsyncRequestBuilder

 �

What class should I use now?

 �

Thanks,

 �

Joan.

AsyncRequestBuilder deprecated

[Joan grupoventus]

Hello,

 �

With the latest HttpClient5 release the AsyncRequestBuilder class is 
deprecated. Checking the api docs it’s telling to use ‘AsyncRequestBuilder’

 �

org.apache.hc.client5.http.async.methods


Class AsyncRequestBuilder


* 

 java.lang.Object

*org.apache.hc.client5.http.async.methods.AsyncRequestBuilder

Deprecated.  

Use  AsyncRequestBuilder

 �

What class should I use now?

 �

Thanks,

 �

Joan.

RE: Question about DNSResolver

[Joan grupoventus]

Hi,

Ok, solved. Instead of implementing a DNS resolver extending the 
SystemDefaultDnsResolver.

Thanks,
Joan.

-Original Message-
From: Joan grupoventus  
Sent: Tuesday, July 2, 2019 3:57 PM
To: 'HttpClient User Discussion' 
Subject: Question about DNSResolver

Hello,

We have an http pool that is shared by 2 apis:

- The api “A” load balances requests by IP address against a farm of internal 
servers. In this case we want to resolve the ip addresses by using an in memory 
dns resolver, and thus bypassing the JRE hostname resolution.

- The api “B” sends requests directly to an external endpoint by http protocol 
(http://domain/...). In this case we want to rely on the JRE hostname 
resolution.

Is there anyway to rely on JRE hostname resolution if the ‘resolve’ method does 
not find the hostname, instead of throwing a ‘UnknownHostException’? Or any 
chance to tell HttpClient to use our dns resolver only for certain kind of 
requests (in this case request from “A” api)?


Thanks,
Joan.


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

Question about DNSResolver

[Joan grupoventus]

Hello,

 �

We have an http pool that is shared by 2 apis:

 �

- The api “A” load balances requests by IP address against a farm of internal 
servers. In this case we want to resolve the ip addresses by using an in memory 
dns resolver, and thus bypassing the JRE hostname resolution.

- The api “B” sends requests directly to an external endpoint by http protocol 
(http://domain/...). In this case we want to rely on the JRE hostname 
resolution.

 �

Is there anyway to rely on JRE hostname resolution if the ‘resolve’ method does 
not find the hostname, instead of throwing a ‘UnknownHostException’? Or any 
chance to tell HttpClient to use our dns resolver only for certain kind of 
requests (in this case request from “A” api)?

 �

Thanks,

 �

Joan.

 �

 �

RE: Response timeout issue

[Joan grupoventus]

Great Oleg!

Issue raised: https://issues.apache.org/jira/browse/HTTPCLIENT-1998

Thanks,
Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Thursday, June 27, 2019 11:58 AM
To: httpclient-users@hc.apache.org
Subject: Re: Response timeout issue

On Wed, 2019-06-26 at 15:52 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> Regarding this pending issue about response timeout, I could finally 
> get traces.
> 
> Our response timeout is set to 2,000ms. This is a request that ended 
> up with a response timeout:
> 62.xxx.xxx.xxx,23:59:47.606,A,1,A,5,A,4,B,,10.15.15.18:8081,,273,569,
> 0,776,http.responseTimeout,23:59:48.382
> 
> If we log this error that means the 'failed' method of our 
> AsyncResponseConsumer received an exception that is an instance of a 
> 'java.net.SocketTimeoutException'.
> 
> Here the trace in our error log:
> 2019-06-25 23:59:48 [62.xxx.xxx.xxx] ventusproxy : ToDi 2.1 :
> x : GetAccomodationAvail Response timeout
> java.net.SocketTimeoutException: 2,000 MILLISECONDS
> at
> org.apache.hc.core5.io.SocketTimeoutExceptionFactory.create(SocketTim
> eoutExceptionFactory.java:50)
> at
> org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onTimeo
> ut(AbstractHttp1StreamDuplexer.java:378)
> at
> org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEventHandler.timeout
> (AbstractHttp1IOEventHandler.java:81)
> at
> org.apache.hc.core5.http.impl.nio.ClientHttp1IOEventHandler.timeout(C
> lientHttp1IOEventHandler.java:39)
> at
> org.apache.hc.core5.reactor.InternalDataChannel.onTimeout(InternalDat
> aChannel.java:188)
> at
> org.apache.hc.core5.reactor.InternalChannel.checkTimeout(InternalChan
> nel.java:67)
> at
> org.apache.hc.core5.reactor.SingleCoreIOReactor.checkTimeout(SingleCo
> reIOReactor.java:232)
> at
> org.apache.hc.core5.reactor.SingleCoreIOReactor.validateActiveChannel
> s(SingleCoreIOReactor.java:165)
> at
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreI
> OReactor.java:127)
> at
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(Abstr
> actSingleCoreIOReactor.java:81)
> at
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:
> 44)
> at java.lang.Thread.run(Thread.java:748)
> 
> The point is that the total time consumed by the request/response is 
> just 776ms (end = 23:59:48.382, start = 23:59:47.606).
> 

Hi Juan

I found the culprit. Presently the internal data channel calculates the 
deadline of read operation based on the last read access. Naturally the last 
read operation timestamp on a persistent (kept-alive) HTTP connection usually 
points back at the previous message exchange 

https://github.com/apache/httpcomponents-core/blob/master/httpcore5/src/main/java/org/apache/hc/core5/reactor/InternalChannel.java#L64

Please raise a JIRA for this defect.

Oleg


> Finally the http traces belonging to this request/response, where the 
> start and end dates match perfectly:
> 23:59:47.606ex-017E91C3: preparing request execution
> 23:59:47.606ex-017E91C3: target auth state: UNCHALLENGED
> 23:59:47.606ex-017E91C3: proxy auth state: UNCHALLENGED
> 23:59:47.606ex-017E91C3: acquiring connection with route {}->
> http://10.15.15.18:8081
> 23:59:47.606ex-017E91C3: acquiring endpoint (1,000 MILLISECONDS)
> 23:59:47.606ex-017E91C3: endpoint lease request (1,000
> MILLISECONDS) [route: {}->http://10.15.15.18:8081][total kept alive:
> 131; route allocated: 2 of 1500; total allocated: 208 of 1500]
> 23:59:47.606ex-017E91C3: endpoint leased [route: {}->
> http://10.15.15.18:8081][total kept alive: 130; route allocated: 2 of 
> 1500; total allocated: 208 of 1500]
> 23:59:47.606ex-017E91C3: acquired ep-017E91C2
> 23:59:47.606ex-017E91C3: acquired endpoint ep-017E91C2
> 23:59:47.606ex-017E91C3: executing POST /ApiServlet.Srv HTTP/1.1
> 23:59:47.606ep-017E91C2: start execution ex-017E91C3
> 23:59:47.606ep-017E91C2: executing exchange ex-017E91C3 over i/o-
> 00970788
> 23:59:47.607ex-017E91C3: send request POST /ApiServlet.Srv
> HTTP/1.1, entity len 810
> 23:59:47.607ex-017E91C3: produce request data
> 23:59:47.607ex-017E91C3: produce request data, len 810 bytes
> 23:59:47.607ex-017E91C3: end of request data
> 23:59:48.382ex-017E91C3: execution failed: 2,000 MILLISECONDS
> 23:59:48.382ex-017E91C3: request failed: 2,000 MILLISECONDS
> 23:59:48.382ep-017E91C2: close IMMEDIATE
> 23:59:48.382ep-017E91C2: endpoint closed
> 23:59:48.382ep-017E91C2: discarding endpoint
> 23:59:48.382ep-017E91C2: releasing endpoint
> 23:59:48.382ep-

RE: Response timeout issue

[Joan grupoventus]

Hi Oleg,

Regarding this pending issue about response timeout, I could finally get traces.

Our response timeout is set to 2,000ms. This is a request that ended up with a 
response timeout:
62.xxx.xxx.xxx,23:59:47.606,A,1,A,5,A,4,B,,10.15.15.18:8081,,273,569,0,776,http.responseTimeout,23:59:48.382

If we log this error that means the 'failed' method of our 
AsyncResponseConsumer received an exception that is an instance of a 
'java.net.SocketTimeoutException'.

Here the trace in our error log:
2019-06-25 23:59:48 [62.xxx.xxx.xxx] ventusproxy : ToDi 2.1 : x : 
GetAccomodationAvail Response timeout
java.net.SocketTimeoutException: 2,000 MILLISECONDS
at 
org.apache.hc.core5.io.SocketTimeoutExceptionFactory.create(SocketTimeoutExceptionFactory.java:50)
at 
org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onTimeout(AbstractHttp1StreamDuplexer.java:378)
at 
org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEventHandler.timeout(AbstractHttp1IOEventHandler.java:81)
at 
org.apache.hc.core5.http.impl.nio.ClientHttp1IOEventHandler.timeout(ClientHttp1IOEventHandler.java:39)
at 
org.apache.hc.core5.reactor.InternalDataChannel.onTimeout(InternalDataChannel.java:188)
at 
org.apache.hc.core5.reactor.InternalChannel.checkTimeout(InternalChannel.java:67)
at 
org.apache.hc.core5.reactor.SingleCoreIOReactor.checkTimeout(SingleCoreIOReactor.java:232)
at 
org.apache.hc.core5.reactor.SingleCoreIOReactor.validateActiveChannels(SingleCoreIOReactor.java:165)
at 
org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
at 
org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:81)
at 
org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
at java.lang.Thread.run(Thread.java:748)

The point is that the total time consumed by the request/response is just 776ms 
(end = 23:59:48.382, start = 23:59:47.606).

Finally the http traces belonging to this request/response, where the start and 
end dates match perfectly:
23:59:47.606ex-017E91C3: preparing request execution
23:59:47.606ex-017E91C3: target auth state: UNCHALLENGED
23:59:47.606ex-017E91C3: proxy auth state: UNCHALLENGED
23:59:47.606ex-017E91C3: acquiring connection with route 
{}->http://10.15.15.18:8081
23:59:47.606ex-017E91C3: acquiring endpoint (1,000 MILLISECONDS)
23:59:47.606ex-017E91C3: endpoint lease request (1,000 MILLISECONDS) 
[route: {}->http://10.15.15.18:8081][total kept alive: 131; route allocated: 2 
of 1500; total allocated: 208 of 1500]
23:59:47.606ex-017E91C3: endpoint leased [route: 
{}->http://10.15.15.18:8081][total kept alive: 130; route allocated: 2 of 1500; 
total allocated: 208 of 1500]
23:59:47.606ex-017E91C3: acquired ep-017E91C2
23:59:47.606ex-017E91C3: acquired endpoint ep-017E91C2
23:59:47.606ex-017E91C3: executing POST /ApiServlet.Srv HTTP/1.1
23:59:47.606ep-017E91C2: start execution ex-017E91C3
23:59:47.606ep-017E91C2: executing exchange ex-017E91C3 over i/o-00970788
23:59:47.607ex-017E91C3: send request POST /ApiServlet.Srv HTTP/1.1, entity 
len 810
23:59:47.607ex-017E91C3: produce request data
23:59:47.607ex-017E91C3: produce request data, len 810 bytes
23:59:47.607ex-017E91C3: end of request data
23:59:48.382ex-017E91C3: execution failed: 2,000 MILLISECONDS
23:59:48.382ex-017E91C3: request failed: 2,000 MILLISECONDS
23:59:48.382ep-017E91C2: close IMMEDIATE
23:59:48.382ep-017E91C2: endpoint closed
23:59:48.382ep-017E91C2: discarding endpoint
23:59:48.382ep-017E91C2: releasing endpoint
23:59:48.382ep-017E91C2: connection released [route: 
{}->http://10.15.15.18:8081][total kept alive: 106; route allocated: 1 of 1500; 
total allocated: 211 of 1500]

Important: if we are not wrong, it seems this is only happening when keep alive 
connections are used. If we disable keep alive from the pool, all response 
timeouts disappear.

Let me know if you need further information.

Thanks,
Joan.




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

RE: Response timeout issue

[Joan grupoventus]

Hi,

> Now the current issue. Something similar is happening. After several 
> days of execution, requests start to throw an exception because the 
> container asynchronous timeout is reached. Tracing http, we saw the 
> pool exhausted ... so it's a behavior similar to issue nr. 1.
> 08:14:03.054Connection request: [route: {}->
> http://10.15.15.53:8083][total kept alive: 0; route allocated: 107 of 
> 1500; total allocated: 1500 of 1500]
> 

I could not find it anywhere in the logs that you have provided. 
--> It's here, https://github.com/joanbalaguero/HttpClient , in the http.log I 
uploaded.

> That's why I asked you if it's possible the 'updateCapacity' method to 
> be called but without previously calling the 'consumeResponse'
> method with a non-null entity.

No, I do not think it is possible.
--> Ok.

>  In this case the variable 'this.capacityToPerform' we use to extend 
> the buffer will be 0 and we will be again in the first issue.
> 
> So I think the pool exhausted is a consequence the thread that is 
> managing the 'AsyncResponseConsumer' is not ending for some reason 
> (like in the first issue).
> 

Again, I need to see a _complete_ wire / context log of such message exchange.

Is there something else (like updating the capacity) I have to take
> into account in the ' AsyncResponseConsumer ' to avoid hanging the 
> execution?
> 

I need to see a log of such 'hanging' message exchnage.
--> Ok, to do this I need to enable the http traces for days waiting the "hang" 
to happen. But with the log I have enabled now there is a significant increase 
in cpu and io (because the responses are usually quite big). Is there any way 
to enable a kind of logging useful for you but avoiding trace the request and 
response messages?

Joan.


> Thanks,
> 
> Joan.
> 
> -Original Message-----
> From: Oleg Kalnichevski 
> Sent: Friday, June 7, 2019 4:00 PM
> To: HttpClient User Discussion 
> Subject: Re: Response timeout issue
> 
> On Thu, 2019-06-06 at 18:56 +0200, Joan grupoventus wrote:
> > Hi again,
> > 
> > Not sure if we have seen something strange in the current test with 
> > the keep alive connections. It's just a GET method to get a gif 
> > (this pool has no keep-alive, that means a 100ms keep-alive). Here 
> > the complete http log: 
> > https://github.com/joanbalaguero/HttpClient.git
> > (it's the "http_get.log")
> 
> Joan
> 
> I am confused. I looked at http_get.log and I can see the exact same 
> number of connection lease requests and that of released connections.
> There are two 253 message exchanges and the same number of connection 
> lease / release operations.
> 
> I am not seeing any evidence of connections being leaked. I am lost 
> now. What is exactly the issue you are having?
> 
> Oleg
> 
> 
> > Previously to this test, this pool received 4 requests today
> > 06/06/2019 around 11:15:00 (so 6 hours before the test), these 4 
> > requests ended up with a 4xx status code.
> > 
> > This is the first request we sent to this pool using this route.
> > Should not keep-alive be 0 and total allocated 1 of 1000?
> > ---
> > 
> > 17:23:02.692ex-0105B9B8: preparing request execution
> > 17:23:02.692Target auth state: UNCHALLENGED
> > 17:23:02.692Proxy auth state: UNCHALLENGED
> > 17:23:02.692ex-0105B9B8: acquiring connection with route {}->
> > http://andalucia.viajesolympia.com:80
> > 17:23:02.692Connection request: [route: {}->
> > http://andalucia.viajesolympia.com:80][total kept alive: 1; route
> > allocated: 0 of 1000; total allocated: 1 of 1000]
> > 17:23:02.692Connection leased: [route: {}->
> > http://andalucia.viajesolympia.com:80][total kept alive: 1; route
> > allocated: 1 of 1000; total allocated: 2 of 1000]
> > 17:23:02.692ep-010526BF: acquired null
> > 17:23:02.692ex-0105B9B8: connection acquired
> > 
> > This is the second:
> > 
> > 17:23:02.954ex-0105B9B9: preparing request execution
> > 17:23:02.955Target auth state: UNCHALLENGED
> > 17:23:02.955Proxy auth state: UNCHALLENGED
> > 17:23:02.955ex-0105B9B9: acquiring connection with route {}->
> > http://andalucia.viajesolympia.com:80
> > 17:23:02.955Connection request: [route: {}->
> > http://andalucia.viajesolympia.com:80][total kept alive: 2; route
> > allocated: 1 of 1000; total allocated: 2 of 1000] 
> > 17:23:02.955Connection leased: [route: {}->
&g

RE: Response timeout issue

[Joan grupoventus]

Hi Oleg,

Ok, let me explain a bit more. This comes from a previous mistake in our 
AsyncResponseConsumer.

Some weeks ago I wrote you an email because we were having an issue where 
threads got stuck, streamEnd and failed methods were never called, and the 
thread was released when the container asynchronous timeout was reached. As you 
notice, the issue was in our updateCapacity method because we were doing 
nothing on it, instead of extending the capacity of the buffer. This was fixed.

Now the current issue. Something similar is happening. After several days of 
execution, requests start to throw an exception because the container 
asynchronous timeout is reached. Tracing http, we saw the pool exhausted ... so 
it's a behavior similar to issue nr. 1. 
08:14:03.054Connection request: [route: {}->http://10.15.15.53:8083][total 
kept alive: 0; route allocated: 107 of 1500; total allocated: 1500 of 1500]

That's why I asked you if it's possible the 'updateCapacity' method to be 
called but without previously calling the 'consumeResponse' method with a 
non-null entity. In this case the variable 'this.capacityToPerform' we use to 
extend the buffer will be 0 and we will be again in the first issue.

So I think the pool exhausted is a consequence the thread that is managing the 
'AsyncResponseConsumer' is not ending for some reason (like in the first issue).

Is there something else (like updating the capacity) I have to take into 
account in the ' AsyncResponseConsumer ' to avoid hanging the execution?

Thanks,

Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Friday, June 7, 2019 4:00 PM
To: HttpClient User Discussion 
Subject: Re: Response timeout issue

On Thu, 2019-06-06 at 18:56 +0200, Joan grupoventus wrote:
> Hi again,
> 
> Not sure if we have seen something strange in the current test with 
> the keep alive connections. It's just a GET method to get a gif (this 
> pool has no keep-alive, that means a 100ms keep-alive). Here the 
> complete http log: https://github.com/joanbalaguero/HttpClient.git
> (it's the "http_get.log")

Joan

I am confused. I looked at http_get.log and I can see the exact same number of 
connection lease requests and that of released connections.
There are two 253 message exchanges and the same number of connection lease / 
release operations. 

I am not seeing any evidence of connections being leaked. I am lost now. What 
is exactly the issue you are having?

Oleg 


> Previously to this test, this pool received 4 requests today
> 06/06/2019 around 11:15:00 (so 6 hours before the test), these 4 
> requests ended up with a 4xx status code.
> 
> This is the first request we sent to this pool using this route.
> Should not keep-alive be 0 and total allocated 1 of 1000?
> ---
> 
> 17:23:02.692ex-0105B9B8: preparing request execution
> 17:23:02.692Target auth state: UNCHALLENGED
> 17:23:02.692Proxy auth state: UNCHALLENGED
> 17:23:02.692ex-0105B9B8: acquiring connection with route {}->
> http://andalucia.viajesolympia.com:80
> 17:23:02.692Connection request: [route: {}->
> http://andalucia.viajesolympia.com:80][total kept alive: 1; route
> allocated: 0 of 1000; total allocated: 1 of 1000]
> 17:23:02.692Connection leased: [route: {}->
> http://andalucia.viajesolympia.com:80][total kept alive: 1; route
> allocated: 1 of 1000; total allocated: 2 of 1000]
> 17:23:02.692ep-010526BF: acquired null
> 17:23:02.692ex-0105B9B8: connection acquired
> 
> This is the second:
> 
> 17:23:02.954ex-0105B9B9: preparing request execution
> 17:23:02.955Target auth state: UNCHALLENGED
> 17:23:02.955Proxy auth state: UNCHALLENGED
> 17:23:02.955ex-0105B9B9: acquiring connection with route {}->
> http://andalucia.viajesolympia.com:80
> 17:23:02.955Connection request: [route: {}->
> http://andalucia.viajesolympia.com:80][total kept alive: 2; route
> allocated: 1 of 1000; total allocated: 2 of 1000] 
> 17:23:02.955Connection leased: [route: {}->
> http://andalucia.viajesolympia.com:80][total kept alive: 1; route
> allocated: 1 of 1000; total allocated: 2 of 1000]
> 17:23:02.955ep-010526C0: acquired null
> 17:23:02.955ex-0105B9B9: connection acquired
> 17:23:02.976ep-010526C0: connected i/o-434A
> 17:23:02.976Connected to target
> 17:23:02.976Route fully established
> 
> ( . . . )
> 
> Now a pool reboot
> -
> 17:27:29.996Shutdown connection pool GRACEFUL
> 17:27:29.996i/o-43AF: Shutdown connection GRACEFUL
> 17:27:29.996i/o-2D9A: Shutdown connection GRACEFUL
> 17:27:29.996Connection pool sh

RE: Response timeout issue

[Joan grupoventus]

Hi again,

Not sure if we have seen something strange in the current test with the keep 
alive connections. It's just a GET method to get a gif (this pool has no 
keep-alive, that means a 100ms keep-alive). Here the complete http log: 
https://github.com/joanbalaguero/HttpClient.git (it's the "http_get.log")
Previously to this test, this pool received 4 requests today 06/06/2019 around 
11:15:00 (so 6 hours before the test), these 4 requests ended up with a 4xx 
status code.

This is the first request we sent to this pool using this route. Should not 
keep-alive be 0 and total allocated 1 of 1000?
---
17:23:02.692ex-0105B9B8: preparing request execution
17:23:02.692Target auth state: UNCHALLENGED
17:23:02.692Proxy auth state: UNCHALLENGED
17:23:02.692ex-0105B9B8: acquiring connection with route 
{}->http://andalucia.viajesolympia.com:80
17:23:02.692Connection request: [route: 
{}->http://andalucia.viajesolympia.com:80][total kept alive: 1; route 
allocated: 0 of 1000; total allocated: 1 of 1000]
17:23:02.692Connection leased: [route: 
{}->http://andalucia.viajesolympia.com:80][total kept alive: 1; route 
allocated: 1 of 1000; total allocated: 2 of 1000]
17:23:02.692ep-010526BF: acquired null
17:23:02.692ex-0105B9B8: connection acquired

This is the second:

17:23:02.954ex-0105B9B9: preparing request execution
17:23:02.955Target auth state: UNCHALLENGED
17:23:02.955Proxy auth state: UNCHALLENGED
17:23:02.955ex-0105B9B9: acquiring connection with route 
{}->http://andalucia.viajesolympia.com:80
17:23:02.955Connection request: [route: 
{}->http://andalucia.viajesolympia.com:80][total kept alive: 2; route 
allocated: 1 of 1000; total allocated: 2 of 1000] 
17:23:02.955Connection leased: [route: 
{}->http://andalucia.viajesolympia.com:80][total kept alive: 1; route 
allocated: 1 of 1000; total allocated: 2 of 1000]
17:23:02.955ep-010526C0: acquired null
17:23:02.955ex-0105B9B9: connection acquired
17:23:02.976ep-010526C0: connected i/o-434A
17:23:02.976Connected to target
17:23:02.976Route fully established

( . . . )

Now a pool reboot
-
17:27:29.996Shutdown connection pool GRACEFUL
17:27:29.996i/o-43AF: Shutdown connection GRACEFUL
17:27:29.996i/o-2D9A: Shutdown connection GRACEFUL
17:27:29.996Connection pool shut down
17:27:29.997Shutdown GRACEFUL

1st. request after rebooting. Here keep-alive = 0 and total_allocated = 1
-
17:27:53.585ex-0105BA49: preparing request execution
17:27:53.585Target auth state: UNCHALLENGED
17:27:53.585Proxy auth state: UNCHALLENGED
17:27:53.585ex-0105BA49: acquiring connection with route 
{}->http://andalucia.viajesolympia.com:80
17:27:53.585Connection request: [route: 
{}->http://andalucia.viajesolympia.com:80][total kept alive: 0; route 
allocated: 0 of 1000; total allocated: 0 of 1000]
17:27:53.585Connection leased: [route: 
{}->http://andalucia.viajesolympia.com:80][total kept alive: 0; route 
allocated: 1 of 1000; total allocated: 1 of 1000]
17:27:53.585ep-01052750: acquired null
17:27:53.585ex-0105BA49: connection acquired
17:27:53.609ep-01052750: connected i/o-43B0
17:27:53.609Connected to target
17:27:53.609Route fully established


Thanks,
Joan.



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

RE: Response timeout issue

[Joan grupoventus]

Hi Oleg,

One more information I forgot to provide, not sure if it can help.

>From the 08.13:00 to 08:13:59 the pool kept exhausted:
08:13:00.211Connection request: [route: {}->http://10.15.15.41:8081][total 
kept alive: 0; route allocated: 6 of 1500; total allocated: 1500 of 1500]
( . . . .)
08:13:59.893Connection request: [route: {}->http://10.15.15.5:8083][total 
kept alive: 0; route allocated: 108 of 1500; total allocated: 1500 of 1500]

But at any second within 08:13:xx we performed a "netstat -anp | grep 
ESTABLISHED" and the result was 300. Should not it be 1500 at least?

Thanks,
Joan.


-Original Message-
From: Oleg Kalnichevski  
Sent: Thursday, June 6, 2019 3:15 PM
To: HttpClient User Discussion 
Subject: Re: Response timeout issue

On Thu, 2019-06-06 at 14:34 +0200, Joan grupoventus wrote:
> No .. that's the point ... we are trying any kind of tests ... no 
> success. Did you see the 'ServerHttpResponse.java' code? Do you think 
> the code is correct?
> 

I cannot say 10% without seeing the complete code base.

Oleg


> We are thinking to replace the HttpClient5 by the AsyncClient1.3 and 
> leave the rest of our code untouched and check again. So at least we 
> will know in what side the issue is.
> 
> We'll try to do this today ... I'll keep you informed.
> 
> Thanks,
> 
> Joan.
> 
> -Original Message-
> From: Oleg Kalnichevski 
> Sent: Thursday, June 6, 2019 2:27 PM
> To: HttpClient User Discussion 
> Subject: Re: Response timeout issue
> 
> On Wed, 2019-06-05 at 16:19 +0200, Joan grupoventus wrote:
> > Hi Oleg,
> > 
> > Still dealing with this stuck connections. I could get traces from
> > httpClient5 and we see all connections busy:
> > 08:12:56.031ex-00E1DFB8: acquiring connection with route
> > {}->
> > http://10.15.15.14:8082
> > 08:12:56.087Connection request: [route: {}->
> > http://10.15.15.14:8083][total kept alive: 0; route allocated: 108 
> > of 1500; total allocated: 1500 of 1500]
> > 
> > This happened previously because we were not expanding the capacity 
> > of the buffer in the 'updateCapacity' method. After your 
> > clarification this was fixed:
> > @Override
> >  public void updateCapacity(CapacityChannel cc) {
> >  try { cc.update(this.capacityToPerform); } 
> >  catch (Exception e) {
> > GlobalData.getInstance().getLoggerService().flushCluster("log.inter
> > na
> > l.error.server.http", new Object[] { this.objCall.getNombre(), 
> > this.capacityToPerform, Utils.stackToString(e) }, true); }  }
> > 
> > But now, after several days working, the pool becomes full again.
> > And
> > the only way to solve the issue is restarting it (stopping the http 
> > instance and starting it again from our app). This happens at
> > 08.14.03.225 in the http log we have on this repository: 
> > https://github.com/joanbalaguero/HttpClient.git
> > 
> > 08:14:03.054Connection request: [route: {}->
> > http://10.15.15.53:8083][total kept alive: 0; route allocated: 107 
> > of 1500; total allocated: 1500 of 1500]
> > 08:14:03.080Connection request: [route: {}->
> > http://10.15.15.53:8080][total kept alive: 0; route allocated: 108 
> > of 1500; total allocated: 1500 of 1500]
> > 08:14:03.107Connection request: [route: {}->
> > http://10.15.15.53:8082][total kept alive: 0; route allocated: 107 
> > of 1500; total allocated: 1500 of 1500]
> > 08:14:03.192ex-00E1E1D1: preparing request execution
> > 08:14:03.192Target auth state: UNCHALLENGED
> > 08:14:03.192Proxy auth state: UNCHALLENGED
> > 08:14:03.192ex-00E1E1D1: acquiring connection with route
> > {}->
> > http://10.15.15.24:8080
> > 08:14:03.197Shutdown connection pool GRACEFUL
> > 08:14:03.224Connection request: [route: {}->
> > http://10.15.15.24:8080][total kept alive: 0; route allocated: 10 of 
> > 1500; total allocated: 1500 of 1500]
> > 08:14:03.225i/o-0041DB56: Shutdown connection GRACEFUL
> > 08:14:03.226i/o-0041DB37: Shutdown connection GRACEFUL
> > 08:14:03.226i/o-0041DB19: Shutdown connection GRACEFUL
> > 08:14:03.242Connection pool shut down
> > 08:14:03.242Shutdown GRACEFUL
> > 08:14:03.276ex-00E1E1D2: preparing request execution
> > 08:14:03.276Target auth state: UNCHALLENGED
> > 08:14:03.276Proxy auth state: UNCHALLENGED
> > 08:14:03.276ex-00E1E1D2: acquiring connection with route
> > {}->
> > http://10.15.15.53:8081
> >

RE: Response timeout issue

[Joan grupoventus]

No .. that's the point ... we are trying any kind of tests ... no success. Did 
you see the 'ServerHttpResponse.java' code? Do you think the code is correct?

We are thinking to replace the HttpClient5 by the AsyncClient1.3 and leave the 
rest of our code untouched and check again. So at least we will know in what 
side the issue is.

We'll try to do this today ... I'll keep you informed.

Thanks,

Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Thursday, June 6, 2019 2:27 PM
To: HttpClient User Discussion 
Subject: Re: Response timeout issue

On Wed, 2019-06-05 at 16:19 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> Still dealing with this stuck connections. I could get traces from
> httpClient5 and we see all connections busy:
> 08:12:56.031  ex-00E1DFB8: acquiring connection with route {}->
> http://10.15.15.14:8082
> 08:12:56.087  Connection request: [route: {}->
> http://10.15.15.14:8083][total kept alive: 0; route allocated: 108 of 
> 1500; total allocated: 1500 of 1500]
> 
> This happened previously because we were not expanding the capacity of 
> the buffer in the 'updateCapacity' method. After your clarification 
> this was fixed:
> @Override
>  public void updateCapacity(CapacityChannel cc) {
>try { cc.update(this.capacityToPerform); } 
>catch (Exception e) {
> GlobalData.getInstance().getLoggerService().flushCluster("log.interna
> l.error.server.http", new Object[] { this.objCall.getNombre(), 
> this.capacityToPerform, Utils.stackToString(e) }, true); }  }
> 
> But now, after several days working, the pool becomes full again. And 
> the only way to solve the issue is restarting it (stopping the http 
> instance and starting it again from our app). This happens at
> 08.14.03.225 in the http log we have on this repository: 
> https://github.com/joanbalaguero/HttpClient.git
> 
> 08:14:03.054  Connection request: [route: {}->
> http://10.15.15.53:8083][total kept alive: 0; route allocated: 107 of 
> 1500; total allocated: 1500 of 1500]
> 08:14:03.080  Connection request: [route: {}->
> http://10.15.15.53:8080][total kept alive: 0; route allocated: 108 of 
> 1500; total allocated: 1500 of 1500]
> 08:14:03.107  Connection request: [route: {}->
> http://10.15.15.53:8082][total kept alive: 0; route allocated: 107 of 
> 1500; total allocated: 1500 of 1500]
> 08:14:03.192  ex-00E1E1D1: preparing request execution
> 08:14:03.192  Target auth state: UNCHALLENGED
> 08:14:03.192  Proxy auth state: UNCHALLENGED
> 08:14:03.192  ex-00E1E1D1: acquiring connection with route {}->
> http://10.15.15.24:8080
> 08:14:03.197  Shutdown connection pool GRACEFUL
> 08:14:03.224  Connection request: [route: {}->
> http://10.15.15.24:8080][total kept alive: 0; route allocated: 10 of 
> 1500; total allocated: 1500 of 1500]
> 08:14:03.225  i/o-0041DB56: Shutdown connection GRACEFUL
> 08:14:03.226  i/o-0041DB37: Shutdown connection GRACEFUL
> 08:14:03.226  i/o-0041DB19: Shutdown connection GRACEFUL
> 08:14:03.242  Connection pool shut down
> 08:14:03.242  Shutdown GRACEFUL
> 08:14:03.276  ex-00E1E1D2: preparing request execution
> 08:14:03.276  Target auth state: UNCHALLENGED
> 08:14:03.276  Proxy auth state: UNCHALLENGED
> 08:14:03.276  ex-00E1E1D2: acquiring connection with route {}->
> http://10.15.15.53:8081
> 08:14:03.277  Connection request: [route: {}->
> http://10.15.15.53:8081][total kept alive: 0; route allocated: 0 of 
> 1500; total allocated: 0 of 1500]
> 08:14:03.277  Connection leased: [route: {}->
> http://10.15.15.53:8081][total kept alive: 0; route allocated: 1 of 
> 1500; total allocated: 1 of 1500]
> 08:14:03.277  ep-00DFEDB0: acquired null
> 08:14:03.277  ex-00E1E1D2: connection acquired
> 08:14:03.279  ep-00DFEDB0: connected i/o-00423C70
> 08:14:03.279  Connected to target
> 08:14:03.279  Route fully established
> 
> The point is the variable 'this.capacityToPerform' we use to enlarge 
> the buffer is set in the 'consumeResponse' method when we have a non- 
> null EntityDetails (you can see it in the ServerHttpResponse.java):
> @Override
>  public void consumeResponse(HttpResponse response, EntityDetails 
> entityDetails, HttpContext context, FutureCallback fcback) 
> throws IOException, HttpException  {
>   ( . . . .)
>   if (entityDetails != null) 
>   {
>this.capacityToPerform = entityDetails.getContentLength() > 0 ?
> (int)entityDetails.getContentLength() :
> GlobalData.getInstance().getHttpService().getBufferInInterface();  //
> <-- GlobalData.getInstance().getHttpService().getBufferInInterface()
> is 32768 
>this.vbaos = new
> VentusByteArrayOutputStream(this.capacityToPerform);
>   }
>   else 
>   {
&

RE: Response timeout issue

[Joan grupoventus]

d.

Thanks,

Joan.


-Original Message-
From: Oleg Kalnichevski  
Sent: Thursday, May 30, 2019 11:40 AM
To: HttpClient User Discussion 
Subject: Re: Response timeout issue

On Wed, 2019-05-29 at 18:56 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> I'm still trying to manage this with our client ... we are not able to 
> reproduce it in our environment.
> 
> In the meantime we have come across with another issue. I explain it 
> just to know if you are aware that someone else has experienced 
> something similar with HttpClient5. After 7 days working correctly, 
> suddenly the http pool becomes exhausted and all the asynchronous 
> tasks hang until the container asynchronous timeout is reached. What 
> we see is the request is sent to the backend but no response is 
> obtained, and finally the asynchronous task finishes due to the 
> container timeout after 150s ... no response timeout is thrown (it's 
> set at 90s).
> 

Hi Joan

No, I am not aware of anyone else experiencing similar issues.

Oleg



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

RE: Response timeout issue

[Joan grupoventus]

Hi Oleg,

I'm still trying to manage this with our client ... we are not able to 
reproduce it in our environment.

In the meantime we have come across with another issue. I explain it just to 
know if you are aware that someone else has experienced something similar with 
HttpClient5. After 7 days working correctly, suddenly the http pool becomes 
exhausted and all the asynchronous tasks hang until the container asynchronous 
timeout is reached. What we see is the request is sent to the backend but no 
response is obtained, and finally the asynchronous task finishes due to the 
container timeout after 150s ... no response timeout is thrown (it's set at 
90s).

Our client restarted Tomcat, we could only get a thread stack ... not sure if 
this can be of any utility but I could attach it ...

Thanks,

Joan.


-Original Message-
From: Oleg Kalnichevski  
Sent: Monday, May 27, 2019 11:10 PM
To: HttpClient User Discussion 
Subject: Re: Response timeout issue

Joan

Please raise a JIRA for this issue and attach a wire log with time stamps of a 
_complete_ message exchange demonstrating the incorrect behavior. 

I will review connection management code tomorrow. 

Oleg 


On Mon, 2019-05-27 at 19:33 +0200, Joan ventusproxy wrote:
> Hello,
> 
>   
> 
> We are having an issue with HttpClient 5 beta4 / HttpCore 5 Beta7 and 
> socket timeout after switching from asyncClient 1.3.
> 
>   
> 
> Our requests have a response timeout of 4 seconds. When a response 
> timeout occurs we see this in our log:
> 
> 2019-05-27 13:05:35 [62.73.191.161] GetAccomodationAvail   
>   Response timeout   java.net.SocketTimeoutException:
> 4,000 MILLISECONDS
> 
>at
> org.apache.hc.core5.io.SocketTimeoutExceptionFactory.create(SocketTim
> eoutExceptionFactory.java:50)
> 
>at
> org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onTimeo
> ut(AbstractHttp1StreamDuplexer.java:378)
> 
>at
> org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEventHandler.timeout
> (AbstractHttp1IOEventHandler.java:81)
> 
>at
> org.apache.hc.core5.http.impl.nio.ClientHttp1IOEventHandler.timeout(C
> lientHttp1IOEventHandler.java:39)
> 
>at
> org.apache.hc.core5.reactor.InternalDataChannel.onTimeout(InternalDat
> aChannel.java:188)
> 
>at
> org.apache.hc.core5.reactor.InternalChannel.checkTimeout(InternalChan
> nel.java:67)
> 
>at
> org.apache.hc.core5.reactor.SingleCoreIOReactor.checkTimeout(SingleCo
> reIOReactor.java:232)
> 
>at
> org.apache.hc.core5.reactor.SingleCoreIOReactor.validateActiveChannel
> s(SingleCoreIOReactor.java:165)
> 
>at
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreI
> OReactor.java:127)
> 
>at
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(Abstr
> actSingleCoreIOReactor.java:81)
> 
>at
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:
> 44)
> 
>at java.lang.Thread.run(Thread.java:748)
> 
>   
> 
> That’s ok, but when we check our statistics the average time in case 
> of a response timeout is around 1s. For example the above request has 
> been logged with response timeout:
> 
> 13:05:35.423,748,http.responseTimeout,13:05:36.171
> 
>   
> 
> But the total time consumed by this request, since it enters to our 
> app (at 13:05:35.423) until the response is returned (at 
> 13:05:36.171), is just 748ms, not more than 4s.
> 
>   
> 
> After making a lot of tests, the solution came disabling keep alive.
> Our pool had keep alive enabled (with a value of 20s), disabling keep 
> alive then everything works fine. Response timeouts almost disappear 
> and when one occurs, the logged time is around 4s. If we enable 
> keepalive, the issue occurs again.
> 
>   
> 
> Our KeepAliveStrategy is the same used in asyncClient (changing to the 
> http5 cclasses). It’s set here:
> 
> HttpAsyncClientBuilder hcBuilder =
> HttpAsyncClients.custom().setKeepAliveStrategy(this.setKeepAliveStrat
> egy(pool.getKeepAliveDuration())) …
> 
>   
> 
> And the class is: 
> 
>   
> 
> ( … )
> 
> public TimeValue getKeepAliveDuration(HttpResponse response, 
> HttpContext context)
> 
>   
> 
> {
> 
>// If we have set a keepalive in our pool, it’s used.
> 
>if (this.keepAliveDuration > 0) return 
> (TimeValue.ofMilliseconds(this.keepAliveDuration));
> 
>   
> 
> // Otherwise search for it in the client response.
> 
>BasicHeaderElementIterator it = new 
> BasicHeaderElementIterator(response.headerIterator(HTTP.CONN_KEEP_ALI
> VE));
> 
>   
> 
>while (it.hasNext())
> 
> {
> 
>  HeaderElement he = it.next();
> 
>  String value= he.getValue();
> 
>   
> 
>   if ( (value != null) &&
> (he.getName().equalsIgnoreCase("timeout")) )
> 
>   {
> 
>try { return (TimeValue.ofSeconds(Long.parseLong(value))); }
> 
> catch (NumberFormatEx

RE: AsyncResponseConsumer thread stucked

[Joan grupoventus]

Hi,

We crossed our emails. I will take a look at the ' 
AbstractAsyncResponseConsumer'.

Thanks,

Joan.

-Original Message-
From: Oleg Kalnichevski  
Sent: Thursday, May 9, 2019 12:42 PM
To: HttpClient User Discussion 
Subject: Re: AsyncResponseConsumer thread stucked

On Wed, 2019-05-08 at 19:24 +0200, Joan grupoventus wrote:
> Hello,
> 
>   
> 
> We are having the following issue. Before going deeper (traces, etc) 
> we would like to explain what we are seeing:
> 
>   
> 
> HttpClient5 beta4 and HttpCore beta7 using an AsyncResponseConsumer.
> 
> Requesting, via GET method, an image to an api: 
> http://192.168.6.131:80/simbolos/nevera.gif
> 
> AsyncResponseConsumer consumeResponse method called correctly, and 
> getting a null EntityDetails
> 
> At this point the thread gets stucked, streamEnd and failed methods 
> are never called, and the thread is released when the container 
> asynchronous timeout is reached.
> 
>   
> 
> With the asynClient 4.1.3 this works, the 
> HttpAsyncResponseConsumer.responseReceived and responseCompleted 
> methods are called and the application reports a response with 
> content-length = 0.
> 
>   
> 
> Must anything special be done when an
> AsyncResponseConsumer.consumeResponse method receives a null 
> EntityDetails?
> 

No, there must not. However in case of null entity methods #updateCapacity, 
#consume and #streamEnd will never fire as there is no data stream associated 
with the response message.

Take a look at AbstractAsyncResponseConsumer as an example of response message 
processing, including those without an enclosed entity. 

Oleg



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




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

RE: AsyncResponseConsumer thread stucked

[Joan grupoventus]

Hello,

I can reproduce the issue, a HEAD method is being used, not GET. So sending a 
HEAD method to our application using an AsyncResponseConsumer hangs forever 
after calling the 'consumeResponse' method (but sending the same request using 
GET works).
In our code the only difference between head and get method is this:
AsyncRequestBuilder rb = this.request.isGetMethod() ? 
AsyncRequestBuilder.get(uri) : AsyncRequestBuilder.head(uri);

Rest of code is identical for both methods. Do I need to add some additional 
code to our AsyncResponseConsumer to manage HEAD methods? Since they don't have 
entity, 'consume' and 'streamEnd' are not called. What should I do to finish 
reading the head response and terminate the thread?

Thanks,
Joan.


-----Original Message-
From: Joan grupoventus  
Sent: Wednesday, May 8, 2019 7:24 PM
To: 'HttpClient User Discussion' 
Subject: AsyncResponseConsumer thread stucked

Hello,

  

We are having the following issue. Before going deeper (traces, etc) we would 
like to explain what we are seeing:

  

HttpClient5 beta4 and HttpCore beta7 using an AsyncResponseConsumer.

Requesting, via GET method, an image to an api: 
http://192.168.6.131:80/simbolos/nevera.gif

AsyncResponseConsumer consumeResponse method called correctly, and getting a 
null EntityDetails

At this point the thread gets stucked, streamEnd and failed methods are never 
called, and the thread is released when the container asynchronous timeout is 
reached.

  

With the asynClient 4.1.3 this works, the 
HttpAsyncResponseConsumer.responseReceived and responseCompleted methods are 
called and the application reports a response with content-length = 0.

  

Must anything special be done when an AsyncResponseConsumer.consumeResponse 
method receives a null EntityDetails?

  

Thanks,

  

Joan.

  

  

  

  

  



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

AsyncResponseConsumer thread stucked

[Joan grupoventus]

Hello,

  

We are having the following issue. Before going deeper (traces, etc) we would 
like to explain what we are seeing:

  

HttpClient5 beta4 and HttpCore beta7 using an AsyncResponseConsumer.

Requesting, via GET method, an image to an api: 
http://192.168.6.131:80/simbolos/nevera.gif

AsyncResponseConsumer consumeResponse method called correctly, and getting a 
null EntityDetails

At this point the thread gets stucked, streamEnd and failed methods are never 
called, and the thread is released when the container asynchronous timeout is 
reached.

  

With the asynClient 4.1.3 this works, the 
HttpAsyncResponseConsumer.responseReceived and responseCompleted methods are 
called and the application reports a response with content-length = 0.

  

Must anything special be done when an AsyncResponseConsumer.consumeResponse 
method receives a null EntityDetails?

  

Thanks,

  

Joan.

  

  

  

  

  

RE: Socket timeout exception with HttpClient5

[Joan grupoventus]

Hi Oleg,

Ok, let me prepare this test because the behavior of httpclient5-5.0-beta4 / 
httpcore5-5.0-beta7 is the same than httpclient5-5.0-beta3 / 
httpcore5-5.0-beta6: the 'AbstractCharResponseConsumer' works and the 
'AsyncResponseConsumer' does not.

Thanks,
Joan.

-Original Message-
From: Oleg Kalnichevski [mailto:ol...@apache.org] 
Sent: Friday, April 5, 2019 2:59 PM
To: HttpClient User Discussion 
Subject: Re: Socket timeout exception with HttpClient5

On Fri, 2019-04-05 at 14:51 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> I think I can bring a bit of light to this matter.
> 
> 1. httpclient5-5.0-beta3 / httpcore5-5.0-beta6 : I have changed my 
> code to use a 'AbstractCharResponseConsumer' instead of the original ' 
> AsyncResponseConsumer' (rest of code remains identical) and  works 
> perfectly.
> 
> 2. I remembered some changes in the ' AsyncResponseConsumer', the 
> 'consume' method now does not return a 'int'. So I tried to use the 
> 'AsyncResponseConsumer' with httpclient5-5.0-beta2 / httpcore5-5.0-
> beta5 and also works perfectly.
> 
> 
> So it seems the 'AsyncResponseConsumer' works with the combination
> "httpclient5-5.0-beta2 / httpcore5-5.0-beta5", but not with the 
> combination "httpclient5-5.0-beta3 / httpcore5-5.0-beta6".
> 
> Does this help?
> 
> Thanks,
> Joan.
> 

Please upgrade to BETA4 and re-test. I will need a complete wire/context log of 
the session and preferably a self-contained test app that demonstrates the 
usage of HC APIs. GitHub may be a reasonable
choice to host both the app and the log.   

Oleg 

> 
> -Original Message-
> From: Oleg Kalnichevski [mailto:ol...@apache.org]
> Sent: Friday, April 5, 2019 9:31 AM
> To: HttpClient User Discussion 
> Subject: Re: Socket timeout exception with HttpClient5
> 
> On Thu, 2019-04-04 at 22:35 +0200, Joan grupoventus wrote:
> > Hi Oleg,
> > 
> > Links to 2 log files, one against a https endpoint and another one 
> > against a http endpoint:
> > 
> > https endpoint:
> > http://www.grupoventus.com/download/httpClient5_https.log
> > 
> > http endpoint:
> > http://www.grupoventus.com/download/httpClient5_http.log
> > 
> > 
> > Thanks,
> > Joan.
> > 
> 
> Joan,
> 
> I see nothing in the logs other than the server not sending more data.
> There are no timestamps, so I cannot say how long it took between 
> events in the log.
> 
> Please upgrade to HttpClient 5.0-beta4 (you will have to build it from 
> source or wait a few days before it becomes available in Maven
> Central) and re-run the application with the logging on. I will also 
> need to see your code. A test app reproducing the issue would probably 
> be the best.
> 
> 
> 
https://github.com/apache/httpcomponents-client/releases/tag/5.0-beta4-RC1
> 
> Oleg
> 
> > -Original Message-
> > From: Joan grupoventus [mailto:joan.balagu...@grupoventus.com]
> > Sent: Thursday, April 4, 2019 8:49 PM
> > To: 'HttpClient User Discussion' 
> > Subject: RE: Socket timeout exception with HttpClient5
> > 
> > Hi Oleg,
> > 
> > Attached the http client log (finally) for one request that ends up 
> > with Socket timeout.
> > 
> > Thanks,
> > 
> > Joan.
> > 
> > -Original Message-
> > From: Oleg Kalnichevski [mailto:ol...@apache.org]
> > Sent: Thursday, April 4, 2019 8:31 PM
> > To: HttpClient User Discussion 
> > Subject: Re: Socket timeout exception with HttpClient5
> > 
> > On Thu, 2019-04-04 at 20:08 +0200, Joan grupoventus wrote:
> > > Hi Oleg,
> > > 
> > > I will not be able to do much without a context / wire log or a 
> > > test application reproducing the issue.
> > > 
> > > --> Yes, I am aware of this ... I'm getting crazy trying to log
> > > the
> > > http traffic, no success. That's why I was asking you if you saw 
> > > something incorrect in our appender/logger config.
> > > 
> > > Is the logger name "org.apache.hc" right?
> > 
> > Yes, this looks correct as well as the rest of log4j2 config but I 
> > am no log4j2 specialist.
> > 
> > Oleg
> > 
> > >  With HttpClient 4 I was using "org.apache.http.impl.conn" , 
> > > "org.apache.http.impl.client" and "org.apache.http.client".
> > > 
> > > Thanks,
> > > 
> > > Joan.
> > > 
> > > -Original Message-
> > > From: Oleg Kalnichev

RE: Socket timeout exception with HttpClient5

[Joan grupoventus]

Hi Oleg,

I think I can bring a bit of light to this matter.

1. httpclient5-5.0-beta3 / httpcore5-5.0-beta6 : I have changed my code to use 
a 'AbstractCharResponseConsumer' instead of the original ' 
AsyncResponseConsumer' (rest of code remains identical) and  works perfectly.

2. I remembered some changes in the ' AsyncResponseConsumer', the 'consume' 
method now does not return a 'int'. So I tried to use the 
'AsyncResponseConsumer' with httpclient5-5.0-beta2 / httpcore5-5.0-beta5 and 
also works perfectly.


So it seems the 'AsyncResponseConsumer' works with the combination 
"httpclient5-5.0-beta2 / httpcore5-5.0-beta5", but not with the combination 
"httpclient5-5.0-beta3 / httpcore5-5.0-beta6".

Does this help?

Thanks,
Joan.


-Original Message-
From: Oleg Kalnichevski [mailto:ol...@apache.org] 
Sent: Friday, April 5, 2019 9:31 AM
To: HttpClient User Discussion 
Subject: Re: Socket timeout exception with HttpClient5

On Thu, 2019-04-04 at 22:35 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> Links to 2 log files, one against a https endpoint and another one 
> against a http endpoint:
> 
> https endpoint:
> http://www.grupoventus.com/download/httpClient5_https.log
> 
> http endpoint:
> http://www.grupoventus.com/download/httpClient5_http.log
> 
> 
> Thanks,
> Joan.
> 

Joan,

I see nothing in the logs other than the server not sending more data.
There are no timestamps, so I cannot say how long it took between events in the 
log.

Please upgrade to HttpClient 5.0-beta4 (you will have to build it from source 
or wait a few days before it becomes available in Maven Central) and re-run the 
application with the logging on. I will also need to see your code. A test app 
reproducing the issue would probably be the best.


https://github.com/apache/httpcomponents-client/releases/tag/5.0-beta4-RC1

Oleg

> -Original Message-
> From: Joan grupoventus [mailto:joan.balagu...@grupoventus.com]
> Sent: Thursday, April 4, 2019 8:49 PM
> To: 'HttpClient User Discussion' 
> Subject: RE: Socket timeout exception with HttpClient5
> 
> Hi Oleg,
> 
> Attached the http client log (finally) for one request that ends up 
> with Socket timeout.
> 
> Thanks,
> 
> Joan.
> 
> -Original Message-
> From: Oleg Kalnichevski [mailto:ol...@apache.org]
> Sent: Thursday, April 4, 2019 8:31 PM
> To: HttpClient User Discussion 
> Subject: Re: Socket timeout exception with HttpClient5
> 
> On Thu, 2019-04-04 at 20:08 +0200, Joan grupoventus wrote:
> > Hi Oleg,
> > 
> > I will not be able to do much without a context / wire log or a test 
> > application reproducing the issue.
> > 
> > --> Yes, I am aware of this ... I'm getting crazy trying to log the
> > http traffic, no success. That's why I was asking you if you saw 
> > something incorrect in our appender/logger config.
> > 
> > Is the logger name "org.apache.hc" right?
> 
> Yes, this looks correct as well as the rest of log4j2 config but I am 
> no log4j2 specialist.
> 
> Oleg
> 
> >  With HttpClient 4 I was using "org.apache.http.impl.conn" , 
> > "org.apache.http.impl.client" and "org.apache.http.client".
> > 
> > Thanks,
> > 
> > Joan.
> > 
> > -Original Message-
> > From: Oleg Kalnichevski [mailto:ol...@apache.org]
> > Sent: Thursday, April 4, 2019 7:56 PM
> > To: HttpClient User Discussion 
> > Subject: Re: Socket timeout exception with HttpClient5
> > 
> > On Thu, 2019-04-04 at 16:20 +0200, joan.balagu...@grupoventus.com
> > wrote:
> > > Hello Oleg,
> > > 
> > > I've come across with the following issue. Our application is 
> > > contacting with a webservice that returns information about the 
> > > requested hotels.
> > > More hotels in the request, bigger the response size. This issue 
> > > happens using both https or http.
> > > 
> > > Below the results of the test using curl, httpAsync 4.1.3 and
> > > httpclient5-5.0-beta3 with httpcore5-5.0-beta6 (all tests executed 
> > > on the same server):
> > > 
> > > 1) Using curl:
> > > 
> > > 1 hotel -> 200 OK : 37K : 1.2s
> > > 2 hotels --> 200 OK : 74K : 1.4s
> > > 3 hotels --> 200 OK : 102K : 1.5s
> > > 
> > > 
> > > 2) Using HttpAsync 4.1.3:
> > > 
> > > 1 hotel -> 200 OK : 37K : 1.2s
> > > 2 hotels --> 200 OK : 74K : 1.4s
> > > 3 hotels --> 200 OK : 102K : 1.5s
> > > 
> > > 
> > > 3) Using HttpClient5:

RE: Socket timeout exception with HttpClient5

[Joan grupoventus]

Hi Oleg,

Links to 2 log files, one against a https endpoint and another one against a 
http endpoint:

https endpoint:
http://www.grupoventus.com/download/httpClient5_https.log

http endpoint:
http://www.grupoventus.com/download/httpClient5_http.log


Thanks,
Joan.

-Original Message-
From: Joan grupoventus [mailto:joan.balagu...@grupoventus.com] 
Sent: Thursday, April 4, 2019 8:49 PM
To: 'HttpClient User Discussion' 
Subject: RE: Socket timeout exception with HttpClient5

Hi Oleg,

Attached the http client log (finally) for one request that ends up with Socket 
timeout.

Thanks,

Joan.

-Original Message-
From: Oleg Kalnichevski [mailto:ol...@apache.org]
Sent: Thursday, April 4, 2019 8:31 PM
To: HttpClient User Discussion 
Subject: Re: Socket timeout exception with HttpClient5

On Thu, 2019-04-04 at 20:08 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> I will not be able to do much without a context / wire log or a test 
> application reproducing the issue.
> 
> --> Yes, I am aware of this ... I'm getting crazy trying to log the
> http traffic, no success. That's why I was asking you if you saw 
> something incorrect in our appender/logger config.
> 
> Is the logger name "org.apache.hc" right?

Yes, this looks correct as well as the rest of log4j2 config but I am no log4j2 
specialist.

Oleg

>  With HttpClient 4 I was using "org.apache.http.impl.conn" , 
> "org.apache.http.impl.client" and "org.apache.http.client".
> 
> Thanks,
> 
> Joan.
> 
> -Original Message-
> From: Oleg Kalnichevski [mailto:ol...@apache.org]
> Sent: Thursday, April 4, 2019 7:56 PM
> To: HttpClient User Discussion 
> Subject: Re: Socket timeout exception with HttpClient5
> 
> On Thu, 2019-04-04 at 16:20 +0200, joan.balagu...@grupoventus.com
> wrote:
> > Hello Oleg,
> > 
> > I've come across with the following issue. Our application is 
> > contacting with a webservice that returns information about the 
> > requested hotels.
> > More hotels in the request, bigger the response size. This issue 
> > happens using both https or http.
> > 
> > Below the results of the test using curl, httpAsync 4.1.3 and
> > httpclient5-5.0-beta3 with httpcore5-5.0-beta6 (all tests executed 
> > on the same server):
> > 
> > 1) Using curl:
> > 
> > 1 hotel -> 200 OK : 37K : 1.2s
> > 2 hotels --> 200 OK : 74K : 1.4s
> > 3 hotels --> 200 OK : 102K : 1.5s
> > 
> > 
> > 2) Using HttpAsync 4.1.3:
> > 
> > 1 hotel -> 200 OK : 37K : 1.2s
> > 2 hotels --> 200 OK : 74K : 1.4s
> > 3 hotels --> 200 OK : 102K : 1.5s
> > 
> > 
> > 3) Using HttpClient5:
> > 
> > 1 hotel -> 200 OK : 37K : 1.3s
> > 2 hotels --> Socket Timeout
> > 3 hotels --> Socket Timeout
> > 
> > 
> > The socket timeout error trace is:
> > 
> > java.net.SocketTimeoutException: 15,000 MILLISECONDS
> >  at
> > 
> 
> ...
> 
> > I'm trying to debug, but I'm not able to log anything into the http 
> > client log. The log file is created but nothing is logged. I'm using
> > log4j2 in this way:
> > 
> >   > fileName="${sys:log.dir}httpClient5.log"
> > append="true" immediateFlush="true">  
> > %m%n  
> > 
> > 
> >  > additivity="false">
> > 
> > 
> > 
> > 
> > 
> > I'm logging correctly into another log files using identical 
> > configuration ... What's wrong in this log4j2 configuration?
> > 
> > I have executed this test several times (request with 3 hotels) ...
> > it
> > seems to always stop after reading more than (or around) 64K of 
> > data.
> > 
> > If I could debug I would be able to give more information.
> > 
> 
> Hi Joan
> 
> I will not be able to do much without a context / wire log or a test 
> application reproducing the issue.
> 
> Oleg
> 
> 
> 
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 


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





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

RE: Socket timeout exception with HttpClient5

[Joan grupoventus]

Hi Oleg,

Attached the http client log (finally) for one request that ends up with Socket 
timeout.

Thanks,

Joan.

-Original Message-
From: Oleg Kalnichevski [mailto:ol...@apache.org] 
Sent: Thursday, April 4, 2019 8:31 PM
To: HttpClient User Discussion 
Subject: Re: Socket timeout exception with HttpClient5

On Thu, 2019-04-04 at 20:08 +0200, Joan grupoventus wrote:
> Hi Oleg,
> 
> I will not be able to do much without a context / wire log or a test 
> application reproducing the issue.
> 
> --> Yes, I am aware of this ... I'm getting crazy trying to log the
> http traffic, no success. That's why I was asking you if you saw 
> something incorrect in our appender/logger config.
> 
> Is the logger name "org.apache.hc" right?

Yes, this looks correct as well as the rest of log4j2 config but I am no log4j2 
specialist.

Oleg

>  With HttpClient 4 I was using "org.apache.http.impl.conn" , 
> "org.apache.http.impl.client" and "org.apache.http.client".
> 
> Thanks,
> 
> Joan.
> 
> -Original Message-
> From: Oleg Kalnichevski [mailto:ol...@apache.org]
> Sent: Thursday, April 4, 2019 7:56 PM
> To: HttpClient User Discussion 
> Subject: Re: Socket timeout exception with HttpClient5
> 
> On Thu, 2019-04-04 at 16:20 +0200, joan.balagu...@grupoventus.com
> wrote:
> > Hello Oleg,
> > 
> > I've come across with the following issue. Our application is 
> > contacting with a webservice that returns information about the 
> > requested hotels.
> > More hotels in the request, bigger the response size. This issue 
> > happens using both https or http.
> > 
> > Below the results of the test using curl, httpAsync 4.1.3 and
> > httpclient5-5.0-beta3 with httpcore5-5.0-beta6 (all tests executed 
> > on the same server):
> > 
> > 1) Using curl:
> > 
> > 1 hotel -> 200 OK : 37K : 1.2s
> > 2 hotels --> 200 OK : 74K : 1.4s
> > 3 hotels --> 200 OK : 102K : 1.5s
> > 
> > 
> > 2) Using HttpAsync 4.1.3:
> > 
> > 1 hotel -> 200 OK : 37K : 1.2s
> > 2 hotels --> 200 OK : 74K : 1.4s
> > 3 hotels --> 200 OK : 102K : 1.5s
> > 
> > 
> > 3) Using HttpClient5:
> > 
> > 1 hotel -> 200 OK : 37K : 1.3s
> > 2 hotels --> Socket Timeout
> > 3 hotels --> Socket Timeout
> > 
> > 
> > The socket timeout error trace is:
> > 
> > java.net.SocketTimeoutException: 15,000 MILLISECONDS
> >  at
> > 
> 
> ...
> 
> > I'm trying to debug, but I'm not able to log anything into the http 
> > client log. The log file is created but nothing is logged. I'm using
> > log4j2 in this way:
> > 
> >   > fileName="${sys:log.dir}httpClient5.log"
> > append="true" immediateFlush="true">  
> > %m%n  
> > 
> > 
> >  > additivity="false">
> > 
> > 
> > 
> > 
> > 
> > I'm logging correctly into another log files using identical 
> > configuration ... What's wrong in this log4j2 configuration?
> > 
> > I have executed this test several times (request with 3 hotels) ...
> > it
> > seems to always stop after reading more than (or around) 64K of 
> > data.
> > 
> > If I could debug I would be able to give more information.
> > 
> 
> Hi Joan
> 
> I will not be able to do much without a context / wire log or a test 
> application reproducing the issue.
> 
> Oleg
> 
> 
> 
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 


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




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

RE: Socket timeout exception with HttpClient5

[Joan grupoventus]

Hi Oleg,

I will not be able to do much without a context / wire log or a test 
application reproducing the issue.

--> Yes, I am aware of this ... I'm getting crazy trying to log the http 
traffic, no success. That's why I was asking you if you saw something incorrect 
in our appender/logger config.

Is the logger name "org.apache.hc" right? With HttpClient 4 I was using 
"org.apache.http.impl.conn" , "org.apache.http.impl.client" and 
"org.apache.http.client".

Thanks,

Joan.

-Original Message-
From: Oleg Kalnichevski [mailto:ol...@apache.org] 
Sent: Thursday, April 4, 2019 7:56 PM
To: HttpClient User Discussion 
Subject: Re: Socket timeout exception with HttpClient5

On Thu, 2019-04-04 at 16:20 +0200, joan.balagu...@grupoventus.com
wrote:
> Hello Oleg,
> 
> I've come across with the following issue. Our application is 
> contacting with a webservice that returns information about the 
> requested hotels.
> More hotels in the request, bigger the response size. This issue 
> happens using both https or http.
> 
> Below the results of the test using curl, httpAsync 4.1.3 and
> httpclient5-5.0-beta3 with httpcore5-5.0-beta6 (all tests executed on 
> the same server):
> 
> 1) Using curl:
> 
> 1 hotel -> 200 OK : 37K : 1.2s
> 2 hotels --> 200 OK : 74K : 1.4s
> 3 hotels --> 200 OK : 102K : 1.5s
> 
> 
> 2) Using HttpAsync 4.1.3:
> 
> 1 hotel -> 200 OK : 37K : 1.2s
> 2 hotels --> 200 OK : 74K : 1.4s
> 3 hotels --> 200 OK : 102K : 1.5s
> 
> 
> 3) Using HttpClient5:
> 
> 1 hotel -> 200 OK : 37K : 1.3s
> 2 hotels --> Socket Timeout
> 3 hotels --> Socket Timeout
> 
> 
> The socket timeout error trace is:
> 
> java.net.SocketTimeoutException: 15,000 MILLISECONDS
>  at
> 

...

> I'm trying to debug, but I'm not able to log anything into the http 
> client log. The log file is created but nothing is logged. I'm using 
> log4j2 in this way:
> 
> 
>  append="true" immediateFlush="true">
> 
> %m%n
> 
> 
> 
> 
>  additivity="false">
> 
> 
> 
> 
> 
> I'm logging correctly into another log files using identical 
> configuration ... What's wrong in this log4j2 configuration?
> 
> I have executed this test several times (request with 3 hotels) ...
> it 
> seems to always stop after reading more than (or around) 64K of data.
> 
> If I could debug I would be able to give more information.
> 

Hi Joan

I will not be able to do much without a context / wire log or a test
application reproducing the issue.

Oleg



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




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

RE: Socket timeout exception with HttpClient5

[Joan grupoventus]

Hi again,

To discard a particular issue with the destination endpoint used, I have tried 
to send a similar request from this server to another server within the same 
network. The result is similar, this time is able to read 92313 bytes of 101011 
in just 0,26ms and then a wait of 14,75s until reaching the response timeout:

consumeResponse :: entityDetails = 
org.apache.hc.core5.http.impl.IncomingEntityDetails@54dc9d56
consumeResponse :: headers = Content-Length = 101011, Content-Type = 
application/xml, Date = Thu, 04 Apr 2019 15:35:40 GMT,

consume called :: iteration 0 :: block size read: 3985 bytes, total size read = 
3985, total time spent = 46152 nanos.
consume called :: iteration 1 :: block size read: 8192 bytes, total size read = 
12177, total time spent = 65443 nanos.
consume called :: iteration 2 :: block size read: 8192 bytes, total size read = 
20369, total time spent = 80566 nanos.
consume called :: iteration 3 :: block size read: 8192 bytes, total size read = 
28561, total time spent = 95823 nanos.
consume called :: iteration 4 :: block size read: 8192 bytes, total size read = 
36753, total time spent = 110210 nanos.
consume called :: iteration 5 :: block size read: 3432 bytes, total size read = 
40185, total time spent = 122873 nanos.
consume called :: iteration 6 :: block size read: 2896 bytes, total size read = 
43081, total time spent = 138658 nanos.
consume called :: iteration 7 :: block size read: 8192 bytes, total size read = 
51273, total time spent = 157141 nanos.
consume called :: iteration 8 :: block size read: 6288 bytes, total size read = 
57561, total time spent = 171490 nanos.
consume called :: iteration 9 :: block size read: 8192 bytes, total size read = 
65753, total time spent = 188350 nanos.
consume called :: iteration 10 :: block size read: 8192 bytes, total size read 
= 73945, total time spent = 217534 nanos.
consume called :: iteration 11 :: block size read: 8192 bytes, total size read 
= 82137, total time spent = 234016 nanos.
consume called :: iteration 12 :: block size read: 8192 bytes, total size read 
= 90329, total time spent = 249907 nanos.
consume called :: iteration 13 :: block size read: 1984 bytes, total size read 
= 92313, total time spent = 263477 nanos.

Finish java.net.SocketTimeoutException: 15,000 MILLISECONDS
at 
org.apache.hc.core5.io.SocketTimeoutExceptionFactory.create(SocketTimeoutExceptionFactory.java:50)
at 
org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onTimeout(AbstractHttp1StreamDuplexer.java:404)
at 
org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEventHandler.timeout(AbstractHttp1IOEventHandler.java:81)
at 
org.apache.hc.core5.http.impl.nio.ClientHttp1IOEventHandler.timeout(ClientHttp1IOEventHandler.java:39)
at 
org.apache.hc.core5.reactor.InternalDataChannel.onTimeout(InternalDataChannel.java:188)
at 
org.apache.hc.core5.reactor.InternalChannel.checkTimeout(InternalChannel.java:67)
at 
org.apache.hc.core5.reactor.SingleCoreIOReactor.checkTimeout(SingleCoreIOReactor.java:232)
at 
org.apache.hc.core5.reactor.SingleCoreIOReactor.validateActiveChannels(SingleCoreIOReactor.java:165)
at 
org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
at 
org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:81)
at 
org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
at java.lang.Thread.run(Thread.java:748)


The same execution with a curl or using HttpAsync 4.1.3 works fine.

Thanks,
Joan.

-Original Message-
From: joan.balagu...@grupoventus.com [mailto:joan.balagu...@grupoventus.com] 
Sent: Thursday, April 4, 2019 4:21 PM
To: httpclient-users@hc.apache.org
Subject: Socket timeout exception with HttpClient5

Hello Oleg,

I've come across with the following issue. Our application is contacting with a 
webservice that returns information about the requested hotels.
More hotels in the request, bigger the response size. This issue happens using 
both https or http.

Below the results of the test using curl, httpAsync 4.1.3 and
httpclient5-5.0-beta3 with httpcore5-5.0-beta6 (all tests executed on the same 
server):

1) Using curl:

1 hotel -> 200 OK : 37K : 1.2s
2 hotels --> 200 OK : 74K : 1.4s
3 hotels --> 200 OK : 102K : 1.5s


2) Using HttpAsync 4.1.3:

1 hotel -> 200 OK : 37K : 1.2s
2 hotels --> 200 OK : 74K : 1.4s
3 hotels --> 200 OK : 102K : 1.5s


3) Using HttpClient5:

1 hotel -> 200 OK : 37K : 1.3s
2 hotels --> Socket Timeout
3 hotels --> Socket Timeout


The socket timeout error trace is:

java.net.SocketTimeoutException: 15,000 MILLISECONDS
 at
org.apache.hc.core5.io.SocketTimeoutExceptionFactory.create(SocketTimeoutExceptionFactory.java:50)
 at
org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onTimeout(AbstractHttp1StreamDuplexer.java:404)
 at
org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEven

HttpClient 5

[Joan grupoventus]

Hello,

  

Do you have a release date in mind for HttpClient5 GA?

  

Thanks,

  

Joan.