[io] Refactor of ThreadIO #48
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The ThreadIO service replaces the System streams so that the output and input on a thread associated with a command can be captured. Unfortunately, this occupies the singletons of System.in/out/err. There are many others that want to use the same mechanism. This change introduces a SystemIO service that dispatches the System streams to any number of listeners. The ThreadIO is modified to use this service. By default, the Gogo runtime will register its own SystemIO service. However, it is possible to disable this with the "org.apache.felix.gogo.systemio.timeout" (SystemIO.TIMEOUT) framework property. If this is set to a numeric value, it will indicate that Gogo should look for an external service. The numeric value indicates the amount of time Gogo should wait for this service. 30000 is a common value. Additionally, there is an onClose method added to the session so that it is possible to get a callback when the session closes. Gogo commands can use this to cancel any activity related to a session. The lambda is weakly referenced so it is necessary that the command keeps a strong reference to the callback. Signed-off-by: Peter Kriens <[email protected]>
pkriens
force-pushed
the
pkriens/systemio
branch
from
33f089b
to
f55963e
Compare
|
I just tested the branch and it works like a charm 👍. I strongly believe that this is a great enhancement to Gogo runtime. |
|
To help me understand, maybe to improve the documentation, could you
explain a use case?
- Ray
…On Wed, Mar 31, 2021 at 9:43 AM Amit Kumar Mondal ***@***.***> wrote:
I just tested the branch and it works like a charm 👍. I strongly believe
that this is a great enhancement to Gogo runtime.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABD2TGIFRF7JG7TVQX6BF3TGMRJZANCNFSM4RG7RW3A>
.
--
*Raymond Augé* ***@***.***)
Senior Software Architect *Liferay, Inc.* (@liferay)
OSGi Fellow
|
|
@rotty3000 What I noticed earlier that if I start a local Felix runtime in Eclipse with Gogo and simultaneously connect the runtime using Telnet, all commands executed in the Telnet console get captured by |
|
👍
…On Wed, Mar 31, 2021 at 10:53 AM Amit Kumar Mondal ***@***.***> wrote:
@rotty3000 <https://github.com/rotty3000> What I noticed earlier that if
I start a local Felix runtime in Eclipse with Gogo and simultaneously
connect the runtime using Telnet, all commands executed in the Telnet
console get captured by ThreadIO, and the execution result gets
dispatched to all available streams. The result gets displayed not only on
the Telnet console but also on the Eclipse IDE console. In my opinion, the
result should not have been displayed in IDE if the command is executed on
Telnet and vice versa. This is why, after discussing with @pkriens
<https://github.com/pkriens>, it has been decided that it would have
great to disable the use of ThreadIO on demand which @pkriens
<https://github.com/pkriens> accomplished in this PR by introducing the
SystemIO service. In my scenario, I just needed to export a custom
implementation of SystemIO with the framework property
org.apache.felix.gogo.systemio.timeout set to a proper timeout value
(i.e. 20000 milliseconds).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABD2TGBSXU3RAT4JSJL3H3TGMZNNANCNFSM4RG7RW3A>
.
--
*Raymond Augé* ***@***.***)
Senior Software Architect *Liferay, Inc.* (@liferay)
OSGi Fellow
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The ThreadIO service replaces the System streams so that the output and input on a thread associated with a command can be captured.
Unfortunately, this occupies the singletons of System.in/out/err. There are many others that want to use the same mechanism.
This change introduces a SystemIO service that dispatches the System streams to any number of listeners. The ThreadIO is modified to use this service.
By default, the Gogo runtime will register its own SystemIO service. However, it is possible to disable this with the "org.apache.felix.gogo.systemio.timeout" (SystemIO.TIMEOUT) framework property. If this is set to a numeric value, it will indicate that Gogo should look for an external service. The numeric value indicates the amount of time Gogo should wait for this service. 30000 is a common value.
Additionally, there is an onClose method added to the session so that it is possible to get a callback when the session closes. Gogo commands can use this to cancel any activity related to a session. The lambda is weakly referenced so it is necessary that the command keeps a strong reference to the callback.
Signed-off-by: Peter Kriens [email protected]