Re: [jersey-dev] PoolingHttpClientConnectionManager not releasing connec

[Jan Supol <jan.supol@xxxxxxxxxx>]

Interesting. Adding the following fixes the test:

@Override protected TestContainerFactory getTestContainerFactory()throws TestContainerException {
    return new NettyTestContainerFactory();
}

On 29.04.2020 23:17, Martynas Jusevičius wrote:
> 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
> _______________________________________________
> jersey-dev mailing list
> jersey-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev