You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (Resolved) (JIRA)" <ji...@apache.org> on 2012/02/25 19:39:48 UTC
[jira] [Resolved] (HTTPCORE-294) Deadlock between
Cancellable#cancel() and HttpAsyncExchange#submitResponse()
[ 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