Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <928457591.1142375516938.JavaMail.jira@ajax>
Date: Tue, 14 Mar 2006 22:31:56 +0000 (GMT)
From: "Bryan Pendleton (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1114) derbynet/testSecMec.java fails
 intermittently and test exits mysteriously when server is shutdown as part
 of the testrun.
In-Reply-To: <29629678.1142368001988.JavaMail.jira@ajax>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-1114?page=comments#action_12370431 ] 

Bryan Pendleton commented on DERBY-1114:
----------------------------------------

I can still reproduce the problem even with your changes to remove the switchable streams. So that's one piece of evidence that appears to rule out the switchable streams as the cause.

Also, I tried another experiment. I modified the definition of SwitchablePrintStream in dataSourcePermissions_net.java so that it overrode the close() method, and I gave the overridden method an empty body (that is, I didn't call super.close()) on the theory that this would show whether somebody was calling the close method on the streams unexpectedly. But I was still able to reproduce the problem even with SwitchablePrintStream.close() doing nothing.

So, the good news is that I can still reproduce the failure, and I seem to be ruling things out.

The bad news is that I'm a little short of theories as to what's going wrong.

I like Sunitha's theory that we're somehow closing the standard output stream prematurely; I'm just not sure how to write code that tests that theory.


> derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun.
> -------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1114
>          URL: http://issues.apache.org/jira/browse/DERBY-1114
>      Project: Derby
>         Type: Bug
>   Components: Network Server, Test
>     Versions: 10.2.0.0
>  Environment: Java Version:    1.4.2_06
> Java Vendor:     Sun Microsystems Inc.
> Java home:       /usr/local/lib/j2sdk1.4.2_06/jre
> OS name:         Linux
> OS architecture: i386
> OS version:      2.4.21-27.0.2.ELsmp
>     Reporter: Sunitha Kambhampati
>     Priority: Minor
>  Attachments: Derby1114.diff.txt
>
> The test derbynet/testSecMec.java fails intermittently in a strange way that the test actually exits before finishing the full test. 
> This issue was noticed by Bryan when he ran derbyall with the derby-1080 fix. Some discussion and analysis that has been done is in Derby-1080. Please read comments in DERBY-1080. Some main links in
> http://issues.apache.org/jira/browse/DERBY-1080#action_12370260
> http://issues.apache.org/jira/browse/DERBY-1080#action_12370374
> In short: the test does some switching of System.out and System.err streams before calling networkserver.shutdown. This code was added to this test as part of fix for derby-273.   for some reason, the networkserver.shutdown call makes the test to exit.  One theory is that the network server.shutdown is causing the standard out streams to close and thus the test exits.
> -- Need to investigate what is the cause for this intermittent failure and how/why  networkserver.shutdown is closing the stream or making the test to exit prematurely.

-- 
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