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