Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 8 Nov 2016 06:42:02 +0000 (UTC)
From: "Freeman Fang (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.13017284.1478100884000.218574.1478587322008@Atlassian.JIRA>
In-Reply-To: <JIRA.13017284.1478100884000@Atlassian.JIRA>
References: <JIRA.13017284.1478100884000@Atlassian.JIRA> <JIRA.13017284.1478100884109@arcas>
Subject: [jira] [Comment Edited] (CXF-7122) Infinite loop due to
 AsyncHTTPConduit read timeout with exhausted connection pool
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 08 Nov 2016 06:42:04 -0000


    [ https://issues.apache.org/jira/browse/CXF-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15646690#comment-15646690 ] 

Freeman Fang edited comment on CXF-7122 at 11/8/16 6:41 AM:
------------------------------------------------------------

Hi William,

In ahc 4.0.2 code base, the org.apache.http.impl.nio.conn.CPool is actually
{code}
class CPool extends AbstractNIOConnPool<HttpRoute, ManagedNHttpClientConnection, CPoolEntry> {

    private final Log log = LogFactory.getLog(CPool.class);

    private final long timeToLive;
    private final TimeUnit tunit;

    public CPool(
            final ConnectingIOReactor ioreactor,
            final NIOConnFactory<HttpRoute, ManagedNHttpClientConnection> connFactory,
            final SocketAddressResolver<HttpRoute> addressResolver,
            final int defaultMaxPerRoute, final int maxTotal,
            final long timeToLive, final TimeUnit tunit) {
        super(ioreactor, connFactory, addressResolver, defaultMaxPerRoute, maxTotal);
        this.timeToLive = timeToLive;
        this.tunit = tunit;
    }

    @Override
    protected CPoolEntry createEntry(final HttpRoute route, final ManagedNHttpClientConnection conn) {
        return new CPoolEntry(this.log, conn.getId(), route, conn, this.timeToLive, this.tunit);
    }

}
{code}
There's no onRelease method in that version, and I found HTTPASYNC-88(https://github.com/ok2c/httpasyncclient/commit/c246f59794cfaad86e718ad9bcc38cf368544d8a) actually fixed this and this is in ahc 4.1.0 afterwards.

With ahc 4.1.0 afterwards, I think we don't need fix for CXF-6910 and CXF-7112(because ReceivedTimeout we set on ahc RequestConfig won't affect the connection return to the pool), I will re-consider your patch based on this.

Freeman


was (Author: ffang):
Hi William,

In ahc 4.0.2 code base, the org.apache.http.impl.nio.conn.CPool is actually
{code}
class CPool extends AbstractNIOConnPool<HttpRoute, ManagedNHttpClientConnection, CPoolEntry> {

    private final Log log = LogFactory.getLog(CPool.class);

    private final long timeToLive;
    private final TimeUnit tunit;

    public CPool(
            final ConnectingIOReactor ioreactor,
            final NIOConnFactory<HttpRoute, ManagedNHttpClientConnection> connFactory,
            final SocketAddressResolver<HttpRoute> addressResolver,
            final int defaultMaxPerRoute, final int maxTotal,
            final long timeToLive, final TimeUnit tunit) {
        super(ioreactor, connFactory, addressResolver, defaultMaxPerRoute, maxTotal);
        this.timeToLive = timeToLive;
        this.tunit = tunit;
    }

    @Override
    protected CPoolEntry createEntry(final HttpRoute route, final ManagedNHttpClientConnection conn) {
        return new CPoolEntry(this.log, conn.getId(), route, conn, this.timeToLive, this.tunit);
    }

}
{code}
There's no onRelease method in that version, and I found HTTPASYNC-88 actually fixed this and this is in ahc 4.1.0 afterwards.

With ahc 4.1.0 afterwards, I think we don't need fix for CXF-6910 and CXF-7112(because ReceivedTimeout we set on ahc RequestConfig won't affect the connection return to the pool), I will re-consider your patch based on this.

Freeman


> Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection pool
> ---------------------------------------------------------------------------------
>
>                 Key: CXF-7122
>                 URL: https://issues.apache.org/jira/browse/CXF-7122
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>            Reporter: William Montaz
>            Assignee: Freeman Fang
>            Priority: Critical
>             Fix For: 3.2.0, 3.1.9
>
>         Attachments: AsyncHTTPConduitTest.java
>
>
> Using AsyncHTTPConduit, when the underlying connection pool gets exhausted, requests waiting for a connection will lead to an infinite loop if they reach receive timeout.
> The problem occured on all versions of CXF above 3.0.5 (we did not tested other ones). 
> Let's imagine a backend that's broken and leads to timeout for all requests.
> When handling requests, the cxf worker thread will eventually go in wait state (AsyncHTTPConduit:618), with a timeout that matches the HTTPClientPolicy.setReceiveTimeout() value, waiting for the NIO stack to complete and call notifyAll via responseCallback (AsyncHTTPConduit:455). 
> The timeout on the wait is the big problem :
> With our broken backend, the connection pool is exhausted waiting for other requests to timeout. When a new request is made by cxf against this backend, after timeout time this will happen :
>  - on the one side the reactor threads will get a connection from the pool and try to write to the output stream. Waiting in the pool is not considered as receive timeout.
>  - on the other side the cxf worker thread will wake up (because of the timedout wait), and shutdown SharedOutputBuffer and SharedInputBuffer (AsyncHTTPClient:624)
>  - reactor threads will go to infinite loop because they will try to produceContent from a shutdown buffer (SharedOutputBuffer:120)
>  
>  From there, application recovery is compromised.
>   
>  To fix that, timeout should be handled only via the client callback (AsyncHTTPConduit:463).


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)