[
https://issues.apache.org/jira/browse/DERBY-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-5608:
-----------------------------------
Attachment: derby-5608-2a-clear_interrupt_flag_on_waitFor.diff
I think patch 1a is an improvement, so I committed it to trunk with revision
1242681.
Myrna's results suggest that the old readProcessOutput isn't the cause for the
problems - it's another victim. This assumes of curse that the stream draining
code in SpawnedProcess isn't buggy.
I'm attaching another patch 2a, which resets the interrupt flag when waitFor is
interrupted in SpawnedProcess.complete. If my theory is correct that should
still leave you with some failed tests due to the interrupt, but the cascading
errors caused by Derby shutdowns should go away.
This fix is part of addressing the issues I mentioned for SpawnedProcess under
DERBY-5601.
The real issue here is finding out where the interrupt is coming from, but I
don't know how to do that.
> 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
> Assignee: Kristian Waagan
> Priority: Minor
> Attachments: derby-5608-1a-use_spawnedprocess.diff,
> derby-5608-2a-clear_interrupt_flag_on_waitFor.diff
>
>
> 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
