You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Thomas Watson (JIRA)" <ji...@apache.org> on 2012/07/24 17:53:34 UTC

[jira] [Created] (FELIX-3608) ThreadIOImpl.checkIO can be called after ThreadIOImpl.stop

Thomas Watson created FELIX-3608:
------------------------------------

             Summary: ThreadIOImpl.checkIO can be called after ThreadIOImpl.stop
                 Key: FELIX-3608
                 URL: https://issues.apache.org/jira/browse/FELIX-3608
             Project: Felix
          Issue Type: Bug
          Components: Gogo Runtime
    Affects Versions: gogo.runtime-0.10.0
         Environment: All
            Reporter: Thomas Watson


ThreadIOImpl.checkIO() can be called after ThreadIOImpl.stop() is called.  It appears the ThreadIOImpl.close() method always calls checkIO() which always resets the System streams even after ThreadIOImpl.stop() has been called.  In my environment the gogo shell thread is sitting waiting for input after the gogo.runtime bundle has been stopped.  If it receives input then it tries to interact with some cached ThreadIO service (the one that is stopped) and ends up calling close on it.

This will leave the System streams set even though the ThreadIOImpl object has been stopped and the runtime bundle is no longer active.  This causes a number of issues since now we have an invalid set of streams set in the System.  I also think it is probably a bug that the gogo shell is acting upon a ThreadIO service that is unregistered.

--
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