[ http://issues.apache.org/jira/browse/DERBY-1694?page=comments#action_12428160 ] John H. Embretsen commented on DERBY-1694: ------------------------------------------
Yes, that is true. I see now that the JavaDoc must have been wrong before applying the patch as well, since there was no parameter to execCmdDumpResults called wait, although there is a JavaDoc @param tag saying so. By the way, can someone help me understand why derbynet/testProperties_derby.properties sets some of the properties multiple times? It seems that the patch for DERBY-706 only set them once, but that something went wrong when applying/committing the patch... (?) > 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
