Return-Path: 
 <derby-dev-return-93625-apmail-db-derby-dev-archive=db.apache.org@db.apache.org>
X-Original-To: apmail-db-derby-dev-archive@www.apache.org
Delivered-To: apmail-db-derby-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id BFBF09B1B
	for <apmail-db-derby-dev-archive@www.apache.org>;
 Wed, 22 Feb 2012 12:44:15 +0000 (UTC)
Received: (qmail 45631 invoked by uid 500); 22 Feb 2012 12:44:15 -0000
Delivered-To: apmail-db-derby-dev-archive@db.apache.org
Received: (qmail 45585 invoked by uid 500); 22 Feb 2012 12:44:15 -0000
Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:derby-dev-help@db.apache.org>
List-Unsubscribe: <mailto:derby-dev-unsubscribe@db.apache.org>
List-Post: <mailto:derby-dev@db.apache.org>
List-Id: <derby-dev.db.apache.org>
Reply-To: <derby-dev@db.apache.org>
Delivered-To: mailing list derby-dev@db.apache.org
Received: (qmail 45577 invoked by uid 99); 22 Feb 2012 12:44:15 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 12:44:15 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Feb 2012 12:44:09 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id 0DA083345E4
	for <derby-dev@db.apache.org>; Wed, 22 Feb 2012 12:43:49 +0000 (UTC)
Date: Wed, 22 Feb 2012 12:43:49 +0000 (UTC)
From: "Kristian Waagan (Commented) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1317993663.4054.1329914629057.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1813363086.16163.1328731019564.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5608) BaseTestCase.readProcessOutput
 should read getInputStream()  and getErrorStream() in separate threads
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


    [ https://issues.apache.org/jira/browse/DERBY-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213576#comment-13213576 ] 

Kristian Waagan commented on DERBY-5608:
----------------------------------------

Ok, I'll look into backporting it.

Do you mean DERBY-5594?
I don't think this will fix that issue, although I'm not sure. I'm also not sure if there is a bug with SpawnedProcess/StreamSaver To me it looks like the process is forcibly destroyed for some reason, and it would be good to understand why that's happening.
                
> 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
>             Fix For: 10.9.0.0
>
>         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