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.
