You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2007/09/11 17:30:32 UTC

[jira] Commented: (FELIX-363) Forceable termination of Felix instance leaves global EventDispatcher in non-restartable state

    [ https://issues.apache.org/jira/browse/FELIX-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526486 ] 

Richard S. Hall commented on FELIX-363:
---------------------------------------

The patch makes it so that the calling thread of EventDispatcher.shutdown() no longer waits for the dispatcher thread to shutdown. This changes the behavior a little bit, but I am not sure if anyone cares about this.

I could imagine, given the situation of the dispatcher thread being killed, that you could get into some condition where the calling thread is waiting for the dispatcher thread forever since there is likely a race condition between the caller waiting and the dispatcher getting killed.

> Forceable termination of Felix instance leaves global EventDispatcher in non-restartable state
> ----------------------------------------------------------------------------------------------
>
>                 Key: FELIX-363
>                 URL: https://issues.apache.org/jira/browse/FELIX-363
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>            Reporter: Rob Walker
>            Assignee: Rob Walker
>
> FELIX-314 fixed an issue where internal shutdown of the global EventDispatcher thread left Felx in a state where new instances could not be started within the same VM at a later time.
> It seems in an Applet VM environment using JRE 1.6 and IE7 there is a variation on this case where the Applet VM is forcibly killing VM threads not cleanly terminated by the application itself e.g. a sloppily written Applet  (like ours!) which launched a Felix instance in the start() but didn't shut it down in the stop().
> Such a forceable termination is not tracked or detected, and hence leads to a similar inability to start additional Felix instances as was being seen in FELIX-314

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.