You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Jamie Goodyear (JIRA)" <ji...@apache.org> on 2008/09/05 15:21:59 UTC
[jira] Created: (SMX4KNL-73) Require work around for blocking
in.read() call in ProxyIO for automated testing.
Require work around for blocking in.read() call in ProxyIO for automated testing.
---------------------------------------------------------------------------------
Key: SMX4KNL-73
URL: https://issues.apache.org/activemq/browse/SMX4KNL-73
Project: ServiceMix Kernel
Issue Type: Improvement
Environment: Unix
Reporter: Jamie Goodyear
Require work around for blocking in.read() call in ProxyIO for automated testing.
When automating the SMX4 Kernel with a testing harness the in.read() call in ProxyIO class may block awaiting input (as per design). This functionality becomes a problem since process control can not be turned back to the automating harness that calls servicemix.
To clarify the issue this creates for automated testing:
Harness executes the base GShell start script "gsh":
The GShell command line is started up and the prompt displayed. The underlying JLine Console will read via the readVirtualKey call a '-1' indicating End of Stream. Control is returned to the harness.
Harness executes the SMX4 Kernel start script "servicemix":
The Kernel gshell command line is started up and the prompt displayed. The ProxyIO class performs the read call however and does not read any characters or recieved the End of Stream ("-1"). The read call blocks, not returning control to the harness.
Could we possible add some sort of testing mode configuration to SMX4 Kernel to place read calls into a timeout mode? If configured the ProxyIO read call would wait say 10 seconds for a read then return "-1", simulating GShell's functionality.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SMX4KNL-73) Require work around for blocking
in.read() call in ProxyIO for automated testing.
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SMX4KNL-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45472#action_45472 ]
Guillaume Nodet commented on SMX4KNL-73:
----------------------------------------
Browsing through the code, I think what happens is that the gshell console thread detects the EOS and stops. However, it does not stop the osgi framework.
To do that, I think we would need the following patch:
{code}
Index: src/main/java/org/apache/geronimo/gshell/spring/GShell.java
===================================================================
--- src/main/java/org/apache/geronimo/gshell/spring/GShell.java (revision 692181)
+++ src/main/java/org/apache/geronimo/gshell/spring/GShell.java (working copy)
@@ -131,6 +131,16 @@
} else {
// Otherwise go into a command shell.
shell.run();
+ log.info("Exiting shell due to end of stream on the console");
+ new Thread() {
+ public void run() {
+ try {
+ getBundleContext().getBundle(0).stop();
+ } catch (BundleException e2) {
+ log.info("Caught exception while shutting down framework: " + e2, e2);
+ }
+ }
+ }.start();
}
} catch (Throwable e) {
{code}
> Require work around for blocking in.read() call in ProxyIO for automated testing.
> ---------------------------------------------------------------------------------
>
> Key: SMX4KNL-73
> URL: https://issues.apache.org/activemq/browse/SMX4KNL-73
> Project: ServiceMix Kernel
> Issue Type: Improvement
> Environment: Unix
> Reporter: Jamie Goodyear
>
> Require work around for blocking in.read() call in ProxyIO for automated testing.
> When automating the SMX4 Kernel with a testing harness the in.read() call in ProxyIO class may block awaiting input (as per design). This functionality becomes a problem since process control can not be turned back to the automating harness that calls servicemix.
> To clarify the issue this creates for automated testing:
> Harness executes the base GShell start script "gsh":
> The GShell command line is started up and the prompt displayed. The underlying JLine Console will read via the readVirtualKey call a '-1' indicating End of Stream. Control is returned to the harness.
> Harness executes the SMX4 Kernel start script "servicemix":
> The Kernel gshell command line is started up and the prompt displayed. The ProxyIO class performs the read call however and does not read any characters or recieved the End of Stream ("-1"). The read call blocks, not returning control to the harness.
>
> Could we possible add some sort of testing mode configuration to SMX4 Kernel to place read calls into a timeout mode? If configured the ProxyIO read call would wait say 10 seconds for a read then return "-1", simulating GShell's functionality.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SMX4KNL-73) Require work around for blocking
in.read() call in ProxyIO for automated testing.
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SMX4KNL-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet resolved SMX4KNL-73.
------------------------------------
Assignee: Guillaume Nodet
Fix Version/s: 1.0.0
Resolution: Fixed
Sending gshell/gshell-core/src/main/java/org/apache/geronimo/gshell/spring/GShell.java
Transmitting file data .
Committed revision 692524.
Fixed as part of SMX4KNL-75
> Require work around for blocking in.read() call in ProxyIO for automated testing.
> ---------------------------------------------------------------------------------
>
> Key: SMX4KNL-73
> URL: https://issues.apache.org/activemq/browse/SMX4KNL-73
> Project: ServiceMix Kernel
> Issue Type: Improvement
> Environment: Unix
> Reporter: Jamie Goodyear
> Assignee: Guillaume Nodet
> Fix For: 1.0.0
>
>
> Require work around for blocking in.read() call in ProxyIO for automated testing.
> When automating the SMX4 Kernel with a testing harness the in.read() call in ProxyIO class may block awaiting input (as per design). This functionality becomes a problem since process control can not be turned back to the automating harness that calls servicemix.
> To clarify the issue this creates for automated testing:
> Harness executes the base GShell start script "gsh":
> The GShell command line is started up and the prompt displayed. The underlying JLine Console will read via the readVirtualKey call a '-1' indicating End of Stream. Control is returned to the harness.
> Harness executes the SMX4 Kernel start script "servicemix":
> The Kernel gshell command line is started up and the prompt displayed. The ProxyIO class performs the read call however and does not read any characters or recieved the End of Stream ("-1"). The read call blocks, not returning control to the harness.
>
> Could we possible add some sort of testing mode configuration to SMX4 Kernel to place read calls into a timeout mode? If configured the ProxyIO read call would wait say 10 seconds for a read then return "-1", simulating GShell's functionality.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.