[
http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370374 ]
Sunitha Kambhampati commented on DERBY-1080:
--------------------------------------------
Thanks very much Bryan for the tmp and the log files.
The testSecMec test starts /stops the server and does so 4 times. I will call
one cycle of {start server, runtest, stop server }as one testrun.
from the printlns here is what I can see:
-- testrun0 - start server, runtest, switches System.out and System.err to the
testSecMec.DerbyNet.shutdown.std.log and the
testSecMec.DerbyNet.shutdown.err.log
and shutsdown server and switches System.out and System.err streams back.
-- testrun1 - start server, runtest and switches out and err streams and then
after the call to shudown the server, the test seems to exit.
Something in networkserver.shutdown() is causing the System.out stream to close
and the test exits.
I think the harness waits for the process streams to close and
System.out.close() thus triggers the test to exit. To confirm this, I put a
System.out.close() in the test program and the test exits.
===============
The 4 printlns in the shutdown.std.log makes sense. It is printing the
statements to this log after the switching of streams happens. In the second
testrun, the stream is switched and then prints the statement "calling network
server shutdown" , but after that it exits. It doesnt print the next println
which is Flush consoleLogStream.
Calling network server shutdown. testrun[0]
Flush consoleLogStream. testrun[0]
Switch back consoleLogStream. testrun[0]
Calling network server shutdown. testrun[1]====> after this println the next
call is networkserver.shutdown()
===============
Not sure what is causing the streams to close in shutdown of the server. The
reason this stream switching logic was added seems to be that intentional
exceptions on shutdown of server was written to the standard output streams
causing diffs. Hence as part of DERBY-273, before calling shutdown, the
system.out and System.err are switched to testSecMec.DerbyNet.shutdown.std.log
and testSecMec.DerbyNet.shutdown.err.log files and after shutdown they are
switched back so the test output can continue to go to System.out.
I tried to look briefly if there were any java bugs related to streams but
didnt find any that seemed related.
==============
If this intermittent test failure is due to switching of streams, I'd expect
that maybe it will happen without the 1080 fix too, no?
Can you mention what environment you are seeing this failure.
I ran this test couple more times in the night yday but couldnt reproduce it
either with sane/insane jars on my linux test machine.
I will post if I learn more. Thanks.
> Connection reset when using security mechanism=EUSRIDPWD results in protocol
> error.
> -----------------------------------------------------------------------------------
>
> Key: DERBY-1080
> URL: http://issues.apache.org/jira/browse/DERBY-1080
> Project: Derby
> Type: Bug
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0,
> 10.1.2.1, 10.1.2.2
> Reporter: Sunitha Kambhampati
> Assignee: Sunitha Kambhampati
> Fix For: 10.2.0.0
> Attachments: DebugTest.diff.txt, Derby1080.diff.txt, Derby1080.stat.txt,
> derby-1080-testSecMec.tmp, derby1080.2.diff.txt, derby1080.2.stat.txt,
> derbyTesting.jar, testSecMec.DerbyNet.shutdown.std.log_with_prints,
> testSecMec_with_prints.tmp
>
> if connection is reset, the security mechanism related information for
> EUSRIDPWD is not reset correctly and this leads to a protocol error.
--
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
