Re: [jersey-dev] PoolingHttpClientConnectionManager not releasing connec

[Martynas Jusevičius <martynas@xxxxxxxxxxxxx>]

Jan, I found your blog post describing very similar problems with
HttpClient: http://blog.supol.cz/?p=164

I've now set maxTotal=30 and maxPerRoute=20, yet the test doing
"loopback requests" hangs after only 7 requests:
https://github.com/namedgraph/jersey-test/blob/master/src/test/java/jersey/test/release_conn/ReleaseConnTest.java

The code is doing response.readEntity(String.class) and
request().get(String.class), so everything should be closed correctly
here?

With config.property(ClientProperties.READ_TIMEOUT, 1_000) it goes to
9 requests and then fails, my guess is because the first-issued
connections start to time out.

I've traced the issue to this.condition.await() @
org.apache.http.pool.AbstractConnPool:379

Could it be the same issue as you have described? I am using 2.30.1
though, where it should be fixed, according to the blog post?

I would appreciate the help, this is starting to drive me crazy...

On Tue, Apr 28, 2020 at 9:41 PM Martynas Jusevičius
<martynas@xxxxxxxxxxxxx> wrote:
>
> Note that only testLoopback() fails, i.e. only the client doing a
> loopback request (to its own server on localhost) is hanging. Not sure
> if this is significant; our code uses this pattern quite a lot.
>
> On Tue, Apr 28, 2020 at 8:38 PM Martynas Jusevičius
> <martynas@xxxxxxxxxxxxx> wrote:
> >
> > Oops, the link to the test:
> > https://github.com/namedgraph/jersey-test/blob/master/src/test/java/jersey/test/release_conn/ReleaseConnTest.java
> >
> > On Tue, Apr 28, 2020 at 8:37 PM Martynas Jusevičius
> > <martynas@xxxxxxxxxxxxx> wrote:
> > >
> > > Hi,
> > >
> > > hitting one more snag in the upgrade...
> > >
> > > I was hoping that PoolingHttpClientConnectionManager is a drop-in
> > > replacement for the deprecated ThreadSafeClientConnManager.
> > >
> > > But with the seemingly identical configuration and the same
> > > setDefaultMaxPerRoute(5) setting, our client connections started
> > > hanging after reaching the per route limit:
> > >
> > >     PoolingHttpClientConnectionManager:266 - Connection request:
> > > [route: {s}->https://localhost:4443][total kept alive: 0; route
> > > allocated: 5 of 5; total allocated: 10 of 20]
> > >
> > > Looking in the logs of the 1.19 version, it seems that the limit was
> > > ignored - no connections available, but a new one is created anyway:
> > >
> > >     ThreadSafeClientConnManager:221 - Get connection:
> > > HttpRoute[{s}->https://localhost:4443], timeout = 0
> > >     ConnPoolByRoute:350 - [HttpRoute[{s}->https://localhost:4443]]
> > > total kept alive: 1, total issued: 0, total allocated: 1 out of 20
> > >     ConnPoolByRoute:523 - No free connections
> > > [HttpRoute[{s}->https://localhost:4443]][null]
> > >     ConnPoolByRoute:369 - Available capacity: 5 out of 5
> > > [HttpRoute[{s}->https://localhost:4443]][null]
> > >     ConnPoolByRoute:549 - Creating new connection
> > > [HttpRoute[{s}->https://localhost:4443]]
> > >
> > > So my questions are:
> > > - is this the expected behavior of PoolingHttpClientConnectionManager?
> > > Is it different from PoolingHttpClientConnectionManager?
> > > - what do we do to avoid the client hanging?
> > > - I suppose we need to introduce a (short) connection timeout - how do
> > > we do that?
> > >
> > > I've created a JerseyTest with our config that illustrates the problem:
> > >
> > > Thanks
> > >
> > > Martynas