You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "John H. Embretsen (JIRA)" <de...@db.apache.org> on 2006/08/15 17:00:14 UTC

[jira] Commented: (DERBY-1694) derbynet/testProperties.java hangs

    [ http://issues.apache.org/jira/browse/DERBY-1694?page=comments#action_12428146 ] 
            
John H. Embretsen commented on DERBY-1694:
------------------------------------------

Thank you for uploading the patch (derby1694diff.txt)! I spent a few minutes studying it, along with the existing code for testProperties.java, and it looks to me that this a clear improvement. I have not run any tests apart from testProperties.java in the DerbyNetClient framework on Solaris 10 x86, Sun JVM 1.5. 

The only thing I would like to mention is that if this patch gets committed as is, the JavaDoc for the execCmdDumpResults(...) method will (if I have understood the code correctly) no longer match its behavior:

        /**
	 * Execute the given command and dump the results to standard out
	 *
	 * @param args	command and arguments
	 * @param wait  true =wait for completion
	 * @exception Exception
	 */

With the patch, if wait == false, results will *not* be dumped to standard out.


> derbynet/testProperties.java hangs
> ----------------------------------
>
>                 Key: DERBY-1694
>                 URL: http://issues.apache.org/jira/browse/DERBY-1694
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.3.0.0
>         Environment: Windows XP  IBM 142 JRE
>            Reporter: Daniel John Debrunner
>         Attachments: derby1694diff.txt
>
>
> The testProperties.execCmd() is used to fork a JVM and not handle its
> streams. This will cause problems, as indicated by the javadoc for Process.
> "The parent process uses these streams to feed input to and get output
> from the subprocess. Because some native platforms only provide limited
> buffer size for standard input and output streams, failure to promptly
> write the input stream or read the output stream of the subprocess may
> cause the subprocess to block, and even deadlock"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira