felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Banner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3055) Event Admin deadlocks when sendEvent is called from within a handleEvent method
Date Thu, 28 Jul 2011 15:06:09 GMT

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

Matt Banner commented on FELIX-3055:

Everything looks good to me.  I tried my original test code as well as a new test that recursively
calls sendEvent() a greater number of times than there are threads in the pool (to check for
the starvation issue), and I also tried it out in our actual application as a sanity check.

> 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
>             Fix For: eventadmin-1.2.14
>         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


View raw message