Re: HttpClient is not proving to be thread-safe and reusable -- probably user error

[Shawn Heisey]

On 6/21/2016 8:56 AM, Pete Keyes wrote:
> You failed to consume the response. Apache-HC will never return the
> connection to the pool. Once you've hit the 500th thread all
> connections are leased. In the run() method simply add a finally to
> your try/catch and move the response object into scope.

Thank you.  Added that, and now it all works.  I haven't needed to
actually obtain the data in the response, so I never looked that part up
in the documentation.  In hindsight, it makes sense that the response
needs handling.

Thanks,
Shawn


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

Re: Telling HC to make new connections all the time

[Oleg Kalnichevski]

On Tue, 2016-06-21 at 08:28 -0400, Benson Margulies wrote:
> Oleg, If I set a TTL, do I also need an IdleConnectionMonitorThread (
> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html#d5e652
> )? thanks, benson.
> 

TTL setting only ensures connections cannot get re-used beyond their TTL
but they can still be kept alive in the pool until the pool manager
discards them either while trying to find a valid connection or while
evicting expired ones. One might still need IdleConnectionMonitorThread
to ensure eviction of expired connections when the connection manager
becomes idle after a period of heavy activity. 

Oleg

> 
> On Tue, Jun 21, 2016 at 4:41 AM, Oleg Kalnichevski  wrote:
> > On Mon, 2016-06-20 at 13:57 -0400, Benson Margulies wrote:
> >> We use the async http components library to connect various components
> >> in a system that is deployed, in some cases, on AWS. When it's
> >> deployed on AWS, there are ELBs involved.
> >>
> >> Like some other people, we've having various trauma dealing with the
> >> very dynamic environment of AWS ELBs, which includes constant DNS
> >> changes and some other issues. So far, we've been making our HC
> >> configuration more and more complex. I'm wondering if we should back
> >> off and make it simpler -- make a new connection for each request.
> >> Obviously, this will be somewhat slower and more expensive, but at the
> >> moment we might prefer a slower and more expensive approach that works
> >> to one that occasionally gets lost.
> >>
> >> I appreciate that even making new connections all the time won't
> >> compensate for all possible DNS problems -- if Java itself caches a
> >> stale name->address translation, making a new connection will fail
> >> just as effectively as anything else.
> >>
> >> Does anyone out there have advice to share (other than running away from 
> >> ELB)?
> >>
> >
> > Hi Benson
> >
> > I personally would consider disabling connection persistence extreme and
> > unnecessary. Consider setting the TTL (total time to live) of persistent
> > connections to some low value (say, 10 seconds or even less) instead.
> > This should improve distribution of connections across the cluster of
> > servers behind a load balancer.
> >
> > Hope it helps
> >
> > 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

HttpClient is not proving to be thread-safe and reusable -- probably user error

[Shawn Heisey]

At the paste URL below is the code I'm using in a test.  The test is
checking for race conditions in some server code I've written:

http://apaste.info/Vs6

This code will stop working correctly during the second loop.  On the
first loop, it creates 400 threads and requests the URL once in each
thread.  On the second loop, it tries to do it again, but hangs after
the 100th thread is created.  When I create the client, i set
maxConnPerRoute to 500, so it is related to that.  It seems that each
connection isn't being removed from the internal tracking after it
completes.

If I move the httpclient creation inside the for loop and uncomment the
"client.close();" at the end of the loop, then everything works ... but
it seems like Ishould be able to use one client for this entire test.

What have I done wrong in my code?

threads is a Set.
firstFailedLoop and loopNum are AtomicInteger.
numThreadsPerRun is set to 400.

If anything in the code is unclear, please let me know what needs
clarification.

Thanks,
Shawn


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

Re: Telling HC to make new connections all the time

[Benson Margulies]

Oleg, If I set a TTL, do I also need an IdleConnectionMonitorThread (
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html#d5e652
)? thanks, benson.


On Tue, Jun 21, 2016 at 4:41 AM, Oleg Kalnichevski  wrote:
> On Mon, 2016-06-20 at 13:57 -0400, Benson Margulies wrote:
>> We use the async http components library to connect various components
>> in a system that is deployed, in some cases, on AWS. When it's
>> deployed on AWS, there are ELBs involved.
>>
>> Like some other people, we've having various trauma dealing with the
>> very dynamic environment of AWS ELBs, which includes constant DNS
>> changes and some other issues. So far, we've been making our HC
>> configuration more and more complex. I'm wondering if we should back
>> off and make it simpler -- make a new connection for each request.
>> Obviously, this will be somewhat slower and more expensive, but at the
>> moment we might prefer a slower and more expensive approach that works
>> to one that occasionally gets lost.
>>
>> I appreciate that even making new connections all the time won't
>> compensate for all possible DNS problems -- if Java itself caches a
>> stale name->address translation, making a new connection will fail
>> just as effectively as anything else.
>>
>> Does anyone out there have advice to share (other than running away from 
>> ELB)?
>>
>
> Hi Benson
>
> I personally would consider disabling connection persistence extreme and
> unnecessary. Consider setting the TTL (total time to live) of persistent
> connections to some low value (say, 10 seconds or even less) instead.
> This should improve distribution of connections across the cluster of
> servers behind a load balancer.
>
> Hope it helps
>
> 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: Telling HC to make new connections all the time

[Oleg Kalnichevski]

On Mon, 2016-06-20 at 13:57 -0400, Benson Margulies wrote:
> We use the async http components library to connect various components
> in a system that is deployed, in some cases, on AWS. When it's
> deployed on AWS, there are ELBs involved.
> 
> Like some other people, we've having various trauma dealing with the
> very dynamic environment of AWS ELBs, which includes constant DNS
> changes and some other issues. So far, we've been making our HC
> configuration more and more complex. I'm wondering if we should back
> off and make it simpler -- make a new connection for each request.
> Obviously, this will be somewhat slower and more expensive, but at the
> moment we might prefer a slower and more expensive approach that works
> to one that occasionally gets lost.
> 
> I appreciate that even making new connections all the time won't
> compensate for all possible DNS problems -- if Java itself caches a
> stale name->address translation, making a new connection will fail
> just as effectively as anything else.
> 
> Does anyone out there have advice to share (other than running away from ELB)?
> 

Hi Benson

I personally would consider disabling connection persistence extreme and
unnecessary. Consider setting the TTL (total time to live) of persistent
connections to some low value (say, 10 seconds or even less) instead.
This should improve distribution of connections across the cluster of
servers behind a load balancer.  

Hope it helps

Oleg


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