hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Stanton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCORE-331) deadlock in AbstractNIOConnPool
Date Fri, 18 Jan 2013 01:37:11 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556867#comment-13556867

Scott Stanton commented on HTTPCORE-331:

Digging through the stacks, this is what happened in each thread:

    inputReady catches exception
    HttpAsyncRequestExecutor.exception gets handler(1) from connection
    closehandler calls handler(1).failed
    future.failed locks (0x00000007c76d23c8)
    failed calls pool release, blocks on 0x00000007363b3050

    wants to send a request
    calls lease on pool (acquires lock 0x00000007363b3050)
    pool acquires pool lock
    calls processPendingRequests
    calls completed on future
    calls completed on callback (locks 0x00000007c76d2508)
    doExecute on  a new BasicAsyncRequestExecutionHandler(1)
      handler gets attached to connection
    connection is not open
    calls handler(1).failed
    future.failed (blocks on 0x00000007c76d23c8)

    blocked on lock pool for lease 0x00000007363b3050

I think the handler leaked from statemachine-4367 to agent-004 by way of the HTTP_HANDLER
on the connection.
I'm not sure why both threads are operating on the same connection, but the locking is not
ordered, so in one case the pool lock is grabbed before the handler and in the other case
the reverse is true, hence the deadlock.  I think the fact that the handlers can call into
the pool and vice versa is a recipe for deadlock.  I have no idea how to resolve any of this,

> deadlock in AbstractNIOConnPool
> -------------------------------
>                 Key: HTTPCORE-331
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-331
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.2.4
>         Environment: jjdk 1.7.0_u10
>            Reporter: Scott Stanton
>            Priority: Blocker
>         Attachments: stacks
> I have run into a deadlock in the AbstractNIOConnPool.  I have attached the deadlock
stacks.  I'm not entirely sure what's going on yet, but it appears that nested futures are
causing lock ordering problems.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message