db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1694) derbynet/testProperties.java hangs
Date Fri, 15 Sep 2006 21:39:22 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1694?page=all ]

Sunitha Kambhampati updated DERBY-1694:

    Attachment: derby1694.p2.diff.txt

I was looking at the testProperties issue that caused problems because of test hang. The test
doesnt hang in my environment but I thought I would look to see why the test didnt timeout.

I found couple of issues here:
0. The testProperties.java and several networkserver tests exec new processes to start server,
test properties,shutdown server etc. In some cases, we wait to capture the output from the
subprocess that is started. ProcessStreamResult is used for this purpose.  ProcessStreamResult
is part of the harness (see org.apache.derbyTesting.functionTests.harness.ProcessStreamResult)
and it starts a thread to read data from the process's stream and writes it out. Once EOS
(-1) is reached, the thread exits after doing a notifyAll. 

1. ProcessStreamResult.Wait() does not work with the timeout case. I think the original intention
of the method that takes the timeout was to force the thread to stop, once the timeout period
has elapsed. The method Wait() does not handle this case.
2. On timeout, the myThread needs to stop its work. The run() method does not handle this
3. testProperties test does not make use of the ProcessStreamResult timeout mechanism.  
4. Process's are exec'd in the tests and they are not destroyed within a timeout period. The
network server tests start server using Process, and then cleanup by shutting them down. 
It will all work ok, if no deadlock or blocking of process's occur. It seems to me though,
that we should have a way to destroy the processes that are 
started as part of each test given a timeout period.  Each test must learn to do the cleanup
when it leaves and the test has knowledge of all the sub-processes that it has exec'd.  The
current test harness has a class TimedProcess which could work. 

In the spirit of incremental development, I am attaching a patch(derby1694.p2.diff.txt and
corresponding stat file - derby1694.p2.stat.txt)  that fixes problems 1,2 and 3.  I think
#4 can be handled as a separate issue/patch.

This patch 
-- fixes the timeout handling in ProcessStreamResult.  Instance variable 'interrupted' is
a flag to indicate if a timeout has occurred or if the thread's work has been interrupted
in between.  The flag 'finished' indicates whether  the work has been finished by the thread.
Changes are in Wait() method to make use of wait(timeoutms) if a timeout is specified in ProcessStreamResult.
If timeout time has elapsed, then the interrupted flag is set to true.
-- Adds condition in the run() method to check if interrupted is true. If so, the thread will
stop its work and leave.
-- correctly return if the thread's work was interrupted either because of a timeout or if
it was interrupted.
-- Make use of the ProcessStreamResult with a timeout setting of 2 minutes in testProperties
test. Note, the timeout handling only comes into effect when ProcessStreamResult.Wait() method
is called.

other notes:
-- when you run a test, the suite property for timeout does not get picked up. I think this
is intentional behavior. 
-- Issues mentioned above are not specific to just testProperties but exist for other networkserver
tests. There are a total of 7 files in derbynet that make use of this.  

I'd like feedback on this patch. If this approach seems ok, then we can make these changes
to the 6 other networkserver tests also.

I ran derbyall on ibm142/linux and no new failures. Two tests failed, blobclob4BLOB(derby-1844)
and the known DerbyNetAutoStart.   These 2 failures are not related to these changes. 


> derbynet/testProperties.java hangs
> ----------------------------------
>                 Key: DERBY-1694
>                 URL: http://issues.apache.org/jira/browse/DERBY-1694
>             Project: Derby
>          Issue Type: Bug
>          Components: Regression Test Failure
>    Affects Versions:
>         Environment: Windows XP  IBM 142 JRE
>            Reporter: Daniel John Debrunner
>             Fix For:
>         Attachments: derby1694.p2.diff.txt, derby1694.p2.stat.txt, 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


View raw message