[
https://issues.apache.org/jira/browse/FELIX-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Banner updated FELIX-3055:
-------------------------------
Environment: Win2K8 R2, Java 1.6.0_17
Sorry, I didn't think about this being platform dependent. I am seeing the
issue on Win2k8 R2 with Java 1.6.0_17 and on Windows XP with Java 1.6.0_16, but
NOT on RHEL 4 with Java 1.6.0_17.
> 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
> Environment: Win2K8 R2, Java 1.6.0_17
> Reporter: Matt Banner
> Assignee: Carsten Ziegeler
> Attachments: TestClass.java, threaddump.txt
>
>
> 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
