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] Commented: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.
Date Tue, 14 Mar 2006 17:31:00 GMT
    [ 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


Mime
View raw message