Daniel John Debrunner wrote: > Kathey Marsden wrote: > > >>Kathey Marsden wrote: >> >> >>>Just FYI, I think there is something not quite right with network >>>server's interaction with firewall software or maybe , where one can >>>get a hang even though the software is set to allow connections. >> >> >>Should have said: >> >>Just FYI, I think there is something not quite right with network >>server's interaction with firewall software or maybe the tests , where >>one can get a hang even though the software is set to allow connections. >>Also DERBY-1278 looks like another similar hang with testSecMec on Z/OS. > > > FYI - I'm seeing a hang running derbyNet/testProperties test. I tried > without the firewall software and still see it.
So this hang is a test problem, not one with the network server. 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." Making the hack change to always process the streams to System.out made the hang disappear, though of course introduced more output, I'm not sure how stable it is though. Dan.
