You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org> on 2006/03/07 01:17:29 UTC
[jira] Created: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
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
Assigned to: Sunitha Kambhampati
Fix For: 10.2.0.0
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
Re: [jira] Commented: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.
Posted by Francois Orsini <fr...@gmail.com>.
I'm still reviewing this patch and should be done very soon. I needed
to look at it as it is something I need to look at / handle for the
changes I made for USRSSBPWD support (JIRA-528).
Thanks,
--francois
On 3/13/06, Bryan Pendleton (JIRA) <de...@db.apache.org> wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370217 ]
>
> Bryan Pendleton commented on DERBY-1080:
> ----------------------------------------
>
> I intend to submit this patch today. If any reviewers are still looking at it, please let me know.
>
>
> > 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: Derby1080.diff.txt, Derby1080.stat.txt, derby1080.2.diff.txt, derby1080.2.stat.txt
> >
> > 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
>
>
Re: [jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by Bryan Pendleton <bp...@amberpoint.com>.
I was able to reproduce the truncated output a couple more times just
by running standalone commands of the form:
java -Dframework=DerbyNet org.apache.derbyTesting.functionTests.harness.RunTest derbynet/testSecMec.java
So I don't think that the issue involves an interaction with another test,
at least in my configuration.
Reading through testSecMec.java, I see that there is some relatively
complex code to handle switching System.out and System.err back and
forth when shutting down the server.
I wonder if something is going wrong in this code, intermittently, which
is causing the test output to be lost?
thanks,
bryan
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370265 ]
Sunitha Kambhampati commented on DERBY-1080:
--------------------------------------------
Thanks Bryan.
No. I havent come across this test failing on my machines but I didnt run with jdk141 on linux. I had tested with sun 1.4.1 on windows (just this test). and on linux (ibm142).
In derby-273, the dataSourcePermissions_net failed intermittently and that change affected testSecMec.java also and changed some streams.
I'd have to put some debug statements in the test to see up to what point it is running, but from the tmp, it seems like it doesnt get past the second testrun in the main for-loop. I'll run it repeatedly on my machine and see if I can reproduce this failure.
Thanks,
Sunitha.
> 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: Derby1080.diff.txt, Derby1080.stat.txt, derby-1080-testSecMec.tmp, derby1080.2.diff.txt, derby1080.2.stat.txt
>
> 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370419 ]
Sunitha Kambhampati commented on DERBY-1080:
--------------------------------------------
Thanks Bryan for committing this patch. I have opened a new issue (DERBY-1114) for the intermittent test failure.
> 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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370380 ]
Sunitha Kambhampati commented on DERBY-1080:
--------------------------------------------
Thanks.
The premature_shutdown_derby.log was interesting in that the shutdown message doesnt even get to the derby.log.
In my successful runs, I see 4 shutdown messages in derby.log which is correct and as expected.
> 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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370395 ]
Sunitha Kambhampati commented on DERBY-1080:
--------------------------------------------
I tested both with Thread.sleep(100) and removing the call altogether and the test still passes OK in my environment. I am going to try to see if I can get access to machine with 2.4 kernel similar to what you are using.
I am not sure why the Thread.sleep(5000) line is in this test. I'll try to look at it. This line is also in the dataSourcePermissions_net.java test. Does anyone know ?
There is this code:
// how do we do this with the new api?
//networkServer.join();
Thread.sleep(5000);
---------------------------------------------------------------------
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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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
[jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Mike Matrigali updated DERBY-1080:
----------------------------------
Component: Network Server
> 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
> Components: Network Server
> 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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370382 ]
Bryan Pendleton commented on DERBY-1080:
----------------------------------------
Sunitha, can you help me understand the purpose of the Thread.sleep(5000) line in testSecMec.java? If I change that line from (5000) to (100), the problem becomes *much* more reproducible.
Is there a possibility that, on my machine, some action is sometimes taking longer than 5 seconds to perform, and so the problem is related to that sleep() call returning "too soon"?
In your environment, what happens if you change the Thread.sleep() call?
thanks,
bryan
> 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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370217 ]
Bryan Pendleton commented on DERBY-1080:
----------------------------------------
I intend to submit this patch today. If any reviewers are still looking at it, please let me know.
> 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: Derby1080.diff.txt, Derby1080.stat.txt, derby1080.2.diff.txt, derby1080.2.stat.txt
>
> 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
[jira] Resolved: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Sunitha Kambhampati resolved DERBY-1080:
----------------------------------------
Resolution: Fixed
> 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
> Components: Network Server
> 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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370376 ]
Sunitha Kambhampati commented on DERBY-1080:
--------------------------------------------
Just want to check if there is anything interesting in derby.log. Could you attach the derby.log from the testrun. 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
[jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Sunitha Kambhampati updated DERBY-1080:
---------------------------------------
Attachment: DebugTest.diff.txt
derbyTesting.jar
I am attaching a DebugTest.diff.txt which adds some println statements to testSecMec to see if the intermittent problem with the test is an issue with the closing of System.out and System.err streams. I built the insane version of derbyTesting.jar with this change in test. Bryan- if possible, can you run this test with this change or using this derbyTesting.jar and see if it reproduces. Thanks much.
Main logic for switching of System.out and System.err streams was added as part of derby273 and then got merged with changes for derby 928. I'll study that more and see if I can find something.
I ran the test separately with jdk141/win2k several times and the test passed ok. I tried to run it about 15 times on a linux machine (2.6 kernel, redhat) with sun 1.4.1 and the test passes.
java version "1.4.1_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_07-b02)
Java HotSpot(TM) Client VM (build 1.4.1_07-b02, mixed mode)
OS name: Linux
OS architecture: i386
OS version: 2.6.9-22.0.1.ELsmp
> 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
>
> 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12369447 ]
Kathey Marsden commented on DERBY-1080:
---------------------------------------
Thanks for the patch Sunitha. I applied it and ran derbynetmats and derbynetclientmats and all passed.
Your change looks like it would resolve the problem but I think it would be better to put a reset() method in Database.java rather than resetting the variables directly in DRDAConnThread.
> 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: Derby1080.diff.txt, Derby1080.stat.txt
>
> 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
Re: [jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> server assumes we have seen more SECTKN's and thus we throw error too many codepoints.
Thanks! This was the little detail I'd failed to understand on the first discussion,
and it makes perfect sense now.
Also, thank you for adding the comments; that is very helpful and the regression
test is much clearer now. I think that will be important for maintenance in the
future as the crypto capabilities of the various JDKs continue to evolve.
thanks,
bryan
[jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Sunitha Kambhampati updated DERBY-1080:
---------------------------------------
Attachment: derby1080.2.diff.txt
derby1080.2.stat.txt
I am attaching a patch for Bryan's comments in
http://www.nabble.com/Re%3A-jira-Updated%3A-%28DERBY-1080%29-Connection-reset-when-using-security-mechanism%3DEUSRIDPWD-results-in-protocol-error.-p3293695.html
Thanks Bryan and Kathey for looking at this patch.
This patch (Derby1080.2.diff.txt) makes the following change compared to previous Derby1080.diff.txt.
1) Reset of database.decryptedUserId and decryptedPassword is moved from DRDAConnThread to Database.reset(). Note: that these 2 variables were not correctly reset for connection-reuse which was causing the problem mentioned in this jira. This patch adds reset() method in Database and resets the above 2 variable and also resets the variables related to security mechanism only.
I talked to Kathey on IRC about this:
-- the above change fixes this particular problem in this issue.
-- But more investigation is required for database reset when connection pooling and transaction pooling is done.
-- File a jira so the reset cleanup can be done after investigation.
Does this sound reasonable ?
2) I have reorganized the regression test and added lots of comments. I hope they are helpful in understanding the expected results.
3) Bryan asked"Lastly, would your test have been any different if you had used
ConnectionPoolDataSource.getPooledConnection(String user, String password)
rather than ConnectionPoolDataSource.getPooledConnection()? "
The result would be the same. For eusridpwd case, the client sends the encrypted userid and password sectkns as part of SECCHK. The protocol error was happening because we only read the 2 sectkns if the database.decryptedUserId , database.decryptedPassword is null, otherwise we think we have already read this. Thus on a connection reset,if the decryptedUserId and decryptedPassword are not reset, server assumes we have seen more SECTKN's and thus we throw error too many codepoints.
Per the code: The userid/password passed in getPooledConnection will be the user and password that is used. If userid and password is not set in getPooledConnection, then the information is retrieved from the ConnectionPoolDataSource.
svn stat:
code change
M java\drda\org\apache\derby\impl\drda\Database.java
M java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
test change
M java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testSecMec.java
master file for JCC2.4 driver and for IBM131, Sun JVM131,141,142,15.
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\testSecMec.out
master file for JCC2.6 driver and for IBM131, Sun JVM(versions 131,141,142,15)
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ver2.6\testSecMec.out
master file for JCC2.6 driver and for IBM (versions 141,142,15). Note these jvms support the EUSRIDPWD security mechanism.
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\ver2.6\testSecMec.out
master file for JCC2.4 driver and for IBM(versions 141,142,15). Note these jvms support the EUSRIDPWD security mechanism.
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\testSecMec.out
master file for client driver and for IBM131, Sun JVM (versions 131,141,142,15)
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\testSecMec.out
master file for client driver and for IBM jvm (versions 141,142,15)
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\ibm14\testSecMec.out
Test ran ok with derbynetclientmats and derbynet with ibm142 on linux with known failures in surtest and stress.multi.
testSecMec.java was run with derby client, JCC2.4,JCC2.6 with ibm131,ibm141,ibm142,ibm15,sun - jdk131,141,142,15 ok.
Please review this change. 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: Derby1080.diff.txt, Derby1080.stat.txt, derby1080.2.diff.txt, derby1080.2.stat.txt
>
> 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
[jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Bryan Pendleton updated DERBY-1080:
-----------------------------------
Attachment: derby-1080-testSecMec.tmp
Sunitha, I had a strange failure in testSecMec in the DerbyNet framework.
This is on Linux, using Sun JDK 1.4, when I ran all of derbyall.
I have attached the testSecMec.tmp file. Basically, the output just ceased at line 28, with no other error messages that I can find.
I re-ran the test 5 or 6 times as a single test (-Dframework=DerbyNet derbynet/testSecMec.java) and I reran the derbynetmats suite with the DerbyNet framework.
During the various re-runs, the test failed again the same way exactly once.
So, there seems to be some sort of a very intermittent failure, but I cannot reproduce it.
Does this make sense to you? Can you look at the attached testSecMec.tmp and tell me whether you have a theory for why I might have seen this very intermittent failure? Is there something that might be causing the test program to quit without flushing its output buffer?
thanks,
bryan
> 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: Derby1080.diff.txt, Derby1080.stat.txt, derby-1080-testSecMec.tmp, derby1080.2.diff.txt, derby1080.2.stat.txt
>
> 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
Re: [jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by Mike Matrigali <mi...@sbcglobal.net>.
it seems reasonable as all reviewers think the fix is good to submit
the fix and file and work on the newly discovered issues as Sunitha
outlined.
Bryan Pendleton wrote:
> Sunitha Kambhampati wrote:
>
>> Will the below be reasonable ways to proceed ?
>> -- this fix (derby1080.2.diff.txt ) can be committed now as is.
>> -- In the testSecMec test, I dont see why shutdown should throw an
>> exception. I can change the test to not do this switching of
>> streams, so hopefully test will not exit. If this seems ok, I can
>> submit a test only patch for this.
>> -- open a jira for further investigation of networkserver.shutdown
>> and how it affects streams.
>
>
> I am comfortable with this plan of action. Does anybody else wish to
> express an opinion?
>
> thanks,
>
> bryan
>
>
>
Re: [jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Sunitha Kambhampati wrote:
> Will the below be reasonable ways to proceed ?
> -- this fix (derby1080.2.diff.txt ) can be committed now as is.
> -- In the testSecMec test, I dont see why shutdown should throw an
> exception. I can change the test to not do this switching of streams,
> so hopefully test will not exit. If this seems ok, I can submit a test
> only patch for this.
> -- open a jira for further investigation of networkserver.shutdown and
> how it affects streams.
I am comfortable with this plan of action. Does anybody else wish to
express an opinion?
thanks,
bryan
Re: [jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by Sunitha Kambhampati <ks...@gmail.com>.
Bryan Pendleton wrote:
>> I will try to see if the problem reproduces without your 1080 fix.
>
>
> Hi Sunitha,
>
> Yes, the problem reproduces without your fix. The output files are a bit
> different, but the symptom is the same: the test mysteriously exits
> without
> producing all the required output, and no other messages are produced.
>
> I think in a way this is good news, because it indicates that your
> DERBY-1080 changes are not implicated in the problem.
>
> How should we proceed?
>
Thanks Bryan for trying this out without the 1080 fix.
So,
-- DERBY-1080 does not cause the strange test exit in testSecMec.java.
-- I do think that the networkserver.shutdown and how it affects streams
needs to be investigated further.
Will the below be reasonable ways to proceed ?
-- this fix (derby1080.2.diff.txt ) can be committed now as is.
-- In the testSecMec test, I dont see why shutdown should throw an
exception. I can change the test to not do this switching of streams,
so hopefully test will not exit. If this seems ok, I can submit a test
only patch for this.
-- open a jira for further investigation of networkserver.shutdown and
how it affects streams.
Thanks,
Sunitha.
Re: [jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> I will try to see if the problem reproduces without your 1080 fix.
Hi Sunitha,
Yes, the problem reproduces without your fix. The output files are a bit
different, but the symptom is the same: the test mysteriously exits without
producing all the required output, and no other messages are produced.
I think in a way this is good news, because it indicates that your
DERBY-1080 changes are not implicated in the problem.
How should we proceed?
thanks,
bryan
[jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Bryan Pendleton updated DERBY-1080:
-----------------------------------
Attachment: premature_shutdown_derby.log
premature_shutdown_sysinfo.out
Hi Sunitha, thanks for the updates.
I agree with your analysis and the conclusions you have reached so far. Good work. I think we're getting closer.
I've attached the derby.log from the run, and I've also attached my sysinfo, to give you more details about my environment.
I will try to see if the problem reproduces without your 1080 fix.
> 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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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
[jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Bryan Pendleton updated DERBY-1080:
-----------------------------------
Attachment: testSecMec_with_prints.tmp
testSecMec.DerbyNet.shutdown.std.log_with_prints
The bug reproduces with the print statements in place, which I think is good, so we can continue to diagnose it.
I've attached the new '.tmp' file with the output of a failed test with the print statements in place, and also, this time, I am attaching the 'shutdown.std.log' file. In the past, this file has been 0 bytes after the run, but this time it has 4 of the print statements in it.
Please let me know what additional information I can provide.
thanks,
bryan
> 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
Re: [jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Sunitha Kambhampati (JIRA) wrote:
> Attachment: Derby1080.diff.txt
Hi Sunitha,
I took a very quick look at your patch, and wanted to offer the following feedback:
1) Resetting database state information when re-using a database object seems
like a reasonable behavior to me. I think it would be nice to use the same
overall naming conventions and techniques that Deepa established in DERBY-1002,
so maybe you might want to investigate whether your new code should go into
a database.reset() method rather than being open-coded in DRDAConnThread.
2) A couple more comments in the code in the "try" block in testSecMecWithConnPooling()
would be nice, to make it more clear as to why you are re-using the connection and
what the expected result is. In particular, I found myself unable to explain why
some of the master files show this test succeeding, and some of the master files
show it getting an exception, so some comments would help me understand why the
various master files have the contents that they do.
3) Lastly, would your test have been any different if you had used
ConnectionPoolDataSource.getPooledConnection(String user, String password)
rather than ConnectionPoolDataSource.getPooledConnection()? I guess I don't
really understand how the user's identification information is intended to be
passed around when using pooled connections, and the JDBC javadocs did not
provide an obvious answer.
thanks,
bryan
[jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Sunitha Kambhampati updated DERBY-1080:
---------------------------------------
Attachment: Derby1080.diff.txt
Derby1080.stat.txt
This patch Derby1080.diff.txt provides a fix to ensure that on a connection reset, we dont throw too many codepoint error when reading SECTKN on a parseSECCHK when EUSRIDPWD security mechanism is used.
Overview:
DRDA spec, mentions this in section about connection pooling:
"Allows an application requester to reuse an existing network connection for a different
application once an application disconnects from the connection either by terminating or by
releasing the connection.
An application requester or application server at AGENT manager level 7 indicates the
support of flowing the EXCSAT, ACCSEC, SECCHK, and ACCRDB commands after a
successful commit or rollback to initialize a connection on behalf of a new application."
The DDM manual (pg54) for the ACCSEC command states that
"The source server can send repeated ACCSEC commands when it wants to reuse a connection
for another application or transaction. The ACCSEC must be preceded by an EXCSAT, and
followed by a SECCHK and ACCRDB."
In the NetworkServer code: we have comments in parseEXCSAT() which mentions about connection resets
where a EXCSAT is followed by an ACCSEC (see DRDAConnThread.line 1222-1235)
Couple things to note:
1)On a parseACCSEC, on a RDBNAM , we can re-use the database object. Database stored information for
the decryptedUserId and decryptedPassword which is used only for EUSRIDPWD security mechanism case.
2)ACCSEC is followed by SECCHK. On parseSECCHK, for the SECTKN codepoint we check if
database.decryptedUserId and decryptedPassword is null and if so only then read the sectkn's that
are sent by client. (see method parseSECCHK/case CodePoint.SECTKN)
3)On a re-use of a connection, since reset of the 2 variables in database does not happen, on a
SECCHK flow, we incorrectly throw an error that too many codepoints sent. The error can only be seen when
EUSRIDPWD security mechanism is used since only this requires the flow of SECTKN for encrypted Userid and password
that is sent from the client.
Fix:
This patch fixes the case for EUSRIDPWD where this problem happens. For other security mechanisms the fields decryptedUserId and decryptedPassword is not used. Reset decryptedUserId and decryptedPasword on a parseACCSEC/RDBNAM to null.
svn stat:
M java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
M java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testSecMec.java
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\testSecMec.out
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ver2.6\testSecMec.out
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\ver2.6\testSecMec.out
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\testSecMec.out
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\testSecMec.out
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\ibm14\testSecMec.out
I have a feeling we need to investigate more into this connection pooling (connection reset) as well
as transaction pooling. Maybe someone with more knowledge can comment on how transaction pooling
happens in network server.
I ran derbyall on ibm142/linux ok with known failures(stress.multi and surtest).
I ran derbynet/testSecMec.java for both JCC and client driver on ibm131/ibm141/ibm142/ibm15 as well as sun jvms 131/142/15.
Can someone please review this change. 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: Derby1080.diff.txt, Derby1080.stat.txt
>
> 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
[jira] Closed: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]
Sunitha Kambhampati closed DERBY-1080:
--------------------------------------
> 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
> Components: Network Server
> 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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370212 ]
Sunitha Kambhampati commented on DERBY-1080:
--------------------------------------------
If there are no issues, I'd appreciate if someone can commit this patch (derby1080.2.diff.txt). Thanks.
Here is the short description for checkin comment.
--------------------------------------------------
DERBY-1080: Connection reset when using security mechanism=EUSRIDPWD results in protocol error.
For eusridpwd case, the client sends the encrypted userid and password sectkns as part of SECCHK. The protocol error was happening because we only read the 2 sectkns if the database.decryptedUserId , database.decryptedPassword is null, otherwise we think we have already read this. Thus on a connection reset,if the decryptedUserId and decryptedPassword are not reset, server assumes we have seen more SECTKN's and thus we throw error too many codepoints.
Patch adds
-- code to reset the security mechanism related variables on a connection re-use.
-- regression test to testSecMec.java
----------------------------------------------------
> 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: Derby1080.diff.txt, Derby1080.stat.txt, derby1080.2.diff.txt, derby1080.2.stat.txt
>
> 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Francois Orsini (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370273 ]
Francois Orsini commented on DERBY-1080:
----------------------------------------
The changes look good to me and thanks for adding a connection reset test.
My only minor comment would be to document a bit more in DRDAConnThread.java how we detect it is a connection re-use in parseACCSEC(). I know you have put lots of info in that JIRA but a bit more comment in that part of the code would be good.
Regards.
> 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: Derby1080.diff.txt, Derby1080.stat.txt, derby-1080-testSecMec.tmp, derby1080.2.diff.txt, derby1080.2.stat.txt
>
> 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
[jira] Commented: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370398 ]
Bryan Pendleton commented on DERBY-1080:
----------------------------------------
Patch derby1080.2.diff.txt committed as Revision 385857:
http://svn.apache.org/viewcvs?rev=385857&view=rev
We will address the intermittent test failure as a separate issue.
> 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, premature_shutdown_derby.log, premature_shutdown_sysinfo.out, 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