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
