[
https://issues.apache.org/jira/browse/DERBY-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204004#comment-13204004
]
Kristian Waagan commented on DERBY-5608:
----------------------------------------
Don't know if it is an option, but could readProcessOutput be discarded ([1])
and SpawnedProcess be extended to deal with this?
SpawnedProcess already does what readProcessOutput does (or should have done),
except for constructing a string from the raw output data. After having read a
bit about best practices for java.lang.Process, there seems to be several
common pitfalls associated with its use. It would be good to deal with them in
one place.
SpawnedProcess also has some issues that needs to be fixed. I was planning to
deal with that under DERBY-5601, but maybe this issue is a better fit?
[1] Or keep the method and just use SpawnedProcess in the method implementation.
> BaseTestCase.readProcessOutput should read getInputStream() and
> getErrorStream() in separate threads
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-5608
> URL: https://issues.apache.org/jira/browse/DERBY-5608
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.9.0.0
> Reporter: Kathey Marsden
> Priority: Minor
>
> BaseTestCase.readProcessOutput() reads the streams from
> Process.getInputStream() and Process.getErrorStream() sequentially
> InputStream is = pr.getInputStream();
> InputStream es = pr.getErrorStream();
> ...
> output += "<STDOUT> " + inputStreamToString(is) + "<END STDOUT>\n";
> output += "<STDERR>" + inputStreamToString(es) + "<END STDERR>\n";
> I think that to be really correct the two streams need to be read in
> separate threads because if the error output is large it could block and
> cause a hang if they are read sequentially like this.
> I noticed during the DERBY-5601 discussion as Myrna referenced in that the
> addition of draining the error stream caused a different problem (an
> InterruptException). I don't understand how it could cause that problem but
> do think a hang blocking on reading the input would be possible if the error
> output was large enough both before and after the change to add the reading
> of the error stream sequentially.
--
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
