hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HTTPCORE-294) Deadlock between Cancellable#cancel() and HttpAsyncExchange#submitResponse()
Date Sat, 25 Feb 2012 18:39:48 GMT

     [ https://issues.apache.org/jira/browse/HTTPCORE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oleg Kalnichevski resolved HTTPCORE-294.
----------------------------------------

       Resolution: Fixed
    Fix Version/s: 4.2-beta2

I certainly think that your Cancellable implementation contains logic that probably does not
belong there. Cancellable should hardly do anything other than flipping a flag. Anyway, I
removed synchronization on the connection state a few days ago and the test case attached
to this issue works for me with the latest SVN snapshot.

Please re-test with the latest SVN snapshot.

Oleg
                
> Deadlock between Cancellable#cancel() and HttpAsyncExchange#submitResponse()
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCORE-294
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-294
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.2-beta1
>            Reporter: Geir Harald Hansen
>             Fix For: 4.2-beta2
>
>         Attachments: Test.java, threaddump.txt
>
>
> I leave postponed responses for a separate thread to handle. When Cancellable#cancel()
is invoked I signal this background thread and wait for it to signal back before returning
true or false from cancel() depending on whether the response was cancelled or already sent.
I'm assuming it is not OK to always return true immediately and attempt in the background
to signal another thread to tell it to not submit a response, which it may still do if it
doesn't get the signal in time.
> My program deadlocks if the background thread tries to submit a response after Cancellable#cancel()
has been invoked. The IOReactor worker thread (inside cancel()) waits on the background thread,
and the background thread is trying to submit a response, apparently needing a lock held by
the IOReactor worker thread.
> Not sure if this is a bug or if I am "doing it wrong". But I think this is a trap many
will fall in, so it would be best if this problem could be avoided.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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


Mime
View raw message