Event Admin deadlocks when sendEvent is called from within a handleEvent method
-------------------------------------------------------------------------------
Key: FELIX-3055
URL: https://issues.apache.org/jira/browse/FELIX-3055
Project: Felix
Issue Type: Bug
Components: Event Admin
Affects Versions: eventadmin-1.2.12
Reporter: Matt Banner
The Felix Event Admin service doesn't correctly handle the case where
EventAdmin.sendEvent(Event) is called from within an
EventHandler.handleEvent(Event) implementation. This happens whether the
original event (the one being handled by the EventHandler, not the one it is
dispatching) was dispatched using EventAdmin.sendEvent(Event) or
EventAdmin.postEvent(Event).
I have attached some sample code which should make this easy to reproduce.
Every time you invoke the "dispatch foo" command from the GoGo shell, it will
post a "foo" event. The handler for this event then attempts to send a new
"bar" event. Every time this happens, a thread in the event admin pool will
become deadlocked. If you run the dispatch command more times than the minimum
number of threads in the pool (I think 20, by default), they will all be
deadlocked and the event admin service will stop invoking event handlers (it
seemed strange to me that this happens when you hit the minimum number of
thread in the pool rather than the maximum, but I haven't had time to
investigate that).
Also attached is a thread dump from when all 20 threads have become deadlocked.
Note that they are all stuck on line 240 of SyncDeliverTasks.java waiting on a
rendezvous with the timer barrier (line numbers refer to the current revision
on trunk, r1074155). I suspect that this is because the attempt to rendezvous
on line 266 is met by the attempt on line 208 in the case where the event
handler recursively calls sendEvent, leaving line 240 with no corresponding
call to meet.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
