Derby
  1. Derby
  2. DERBY-4786

Shutdown command without username and password should work with mixed client and network server releases.

    Details

    • Issue & fix info:
      Release Note Needed
    • Bug behavior facts:
      Regression

      Description

      DERBY-2109 introduced optional parameters username and password to the shutdown command. But with this fix, the existing shutdown command which does not use username and password stopped working from client with DERBY-2109 changes against a network server without DERBY-2109 changes.

      This jira is to ensure that existing shutdown command without user name and password still works fine between different releases of client and network server(with or without DERBY-2109). The new shutdown command introduced by DERBY-2109 will work obviosuly only on client and server with DERBY-2109 changes. For client/server not with DERBY-2109 changes attempting to user use name and password will get an error.

      1. DERBY4786_patch1_diff.txt
        5 kB
        Mamta A. Satoor
      2. DERBY4786_patch2_diff.txt
        6 kB
        Mamta A. Satoor
      3. releaseNote.html
        4 kB
        Mamta A. Satoor
      4. DERBY4786_testScript_patch3_diff.txt
        14 kB
        Mamta A. Satoor
      5. releaseNote.html
        5 kB
        Rick Hillegas

        Issue Links

          Activity

          Mamta A. Satoor created issue -
          Mamta A. Satoor made changes -
          Field Original Value New Value
          Link This issue is related to DERBY-3644 [ DERBY-3644 ]
          Hide
          Mamta A. Satoor added a comment -

          Attaching a patch to fix the jira. What the patch does is it checks if the optional username and password have specified for the shutdown command and if yes, then it uses protocol level 2 and then sends the username and password info to the server when sending the shutdown command. If user has not specified username and password then it uses protocol level 1 and sends just the shutdown command the way it used to work prior to DERBY-2109. In other words, protocol level 1 for shutdown with no username and password and protocol level 2 for shutdown with username and password.

          Server on its side checks if it is dealing with protocol level 1 for shutdown and if yes, then it does not need to look for username and password. But if the the protocol level is 2, then the server will expect username and password for the shutdown command,

          This way, a trunk client with this patch will be able to shutdown a 10.3 server with DERBY-2109 changes with no username and password. If it sends the username and password then there be following error on the server and client side
          10.3 server side error
          DRDA_UnknownProtocol.S, <2>
          Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
          trunk client side error
          Tue Aug 31 11:48:20 PDT 2010 : Invalid reply header from network server: Invalid string. Plaintext connection attempt to an SSL enabled server?

          Please let me know if anyone has any feedback on this patch. I will plan on committing this in a day or two.

          Show
          Mamta A. Satoor added a comment - Attaching a patch to fix the jira. What the patch does is it checks if the optional username and password have specified for the shutdown command and if yes, then it uses protocol level 2 and then sends the username and password info to the server when sending the shutdown command. If user has not specified username and password then it uses protocol level 1 and sends just the shutdown command the way it used to work prior to DERBY-2109 . In other words, protocol level 1 for shutdown with no username and password and protocol level 2 for shutdown with username and password. Server on its side checks if it is dealing with protocol level 1 for shutdown and if yes, then it does not need to look for username and password. But if the the protocol level is 2, then the server will expect username and password for the shutdown command, This way, a trunk client with this patch will be able to shutdown a 10.3 server with DERBY-2109 changes with no username and password. If it sends the username and password then there be following error on the server and client side 10.3 server side error DRDA_UnknownProtocol.S, <2> Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? trunk client side error Tue Aug 31 11:48:20 PDT 2010 : Invalid reply header from network server: Invalid string. Plaintext connection attempt to an SSL enabled server? Please let me know if anyone has any feedback on this patch. I will plan on committing this in a day or two.
          Mamta A. Satoor made changes -
          Attachment DERBY4786_patch1_diff.txt [ 12453636 ]
          Hide
          Kathey Marsden added a comment -

          Hi Mamta,

          With this patch, how does a changed trunk client specifying no user/password behave with an existing 10.5 server? I am concerned it might hang.

          Thanks

          Kathey

          Show
          Kathey Marsden added a comment - Hi Mamta, With this patch, how does a changed trunk client specifying no user/password behave with an existing 10.5 server? I am concerned it might hang. Thanks Kathey
          Hide
          Mamta A. Satoor added a comment -

          You are right, Kathey. It sure hangs because the protocol level 1 from client is accepted by the server but for shutdown, existing 10.5 server expects username and password.

          We may have to revert to another approach to this problem which is to send shutdown command with protocol level 2 whether there is username and password or not. If this command fails because of protocol mismatch, then send shutdown command with protocol level 1. Also, if we do try this approach, what should we do if the user has provided user name and password for shutdown going against 10.3 server? Should we throw an exception that username and password can't be used for shutdown when going against a server that doesn't support protocol 2 or should we drop the user name and password and simply send the shutdown with protcol level 1 even though user name and password has been provided on the shutdown command?

          Show
          Mamta A. Satoor added a comment - You are right, Kathey. It sure hangs because the protocol level 1 from client is accepted by the server but for shutdown, existing 10.5 server expects username and password. We may have to revert to another approach to this problem which is to send shutdown command with protocol level 2 whether there is username and password or not. If this command fails because of protocol mismatch, then send shutdown command with protocol level 1. Also, if we do try this approach, what should we do if the user has provided user name and password for shutdown going against 10.3 server? Should we throw an exception that username and password can't be used for shutdown when going against a server that doesn't support protocol 2 or should we drop the user name and password and simply send the shutdown with protcol level 1 even though user name and password has been provided on the shutdown command?
          Hide
          Lily Wei added a comment -

          +1 for send shutdown command with protocol level 2 whether there is username and password or not. If this command fails because of protocol mismatch, then send shutdown command with protocol level 1. If users want to shutdown the server, it should not failed because protocol mismatch. Does people concern about security for this solution?

          Show
          Lily Wei added a comment - +1 for send shutdown command with protocol level 2 whether there is username and password or not. If this command fails because of protocol mismatch, then send shutdown command with protocol level 1. If users want to shutdown the server, it should not failed because protocol mismatch. Does people concern about security for this solution?
          Hide
          Mamta A. Satoor added a comment -

          It appears that the sole pupose of protocol mismatch error thrown by the server is for logging purposed on it's end. That exception never makes it to the client. What client gets is the generic exception as follows
          Invalid reply header from network server: Invalid string Plaintext connection attempt to an SSL enabled server?
          Note that there is no error code associated with the exception that I could see in my debugging.

          So with the current approach for this jira, we were thinking of sending the shutdown with protocol level 2 and if there is protcol mismatch exception, then try it again with protocol level 1. Since there is no way to know that the exception received is for protocol mismatch and no error code either, I was thinking of doing a string search of "Plaintext connection attempt to an SSL enabled server" into exception's message. I do not like this string searching but I wonder what alternative way can we use to know that the protocol level 2 failed and hence tried 1. Another possible thing could be to try shutdown with level 2 and catch the exception and don't worry about what kind of exception it is, just go ahead and try protocol level 1. If there is exception with that too, we will just let the existing code take care of it the way it does today.

          Also, another outstanding issue was what if user has provided user name and password and protocol level 2 fails, then should we still try protocol level 1 with no user password and password?

          Would appreciate any feedback.

          Show
          Mamta A. Satoor added a comment - It appears that the sole pupose of protocol mismatch error thrown by the server is for logging purposed on it's end. That exception never makes it to the client. What client gets is the generic exception as follows Invalid reply header from network server: Invalid string Plaintext connection attempt to an SSL enabled server? Note that there is no error code associated with the exception that I could see in my debugging. So with the current approach for this jira, we were thinking of sending the shutdown with protocol level 2 and if there is protcol mismatch exception, then try it again with protocol level 1. Since there is no way to know that the exception received is for protocol mismatch and no error code either, I was thinking of doing a string search of "Plaintext connection attempt to an SSL enabled server" into exception's message. I do not like this string searching but I wonder what alternative way can we use to know that the protocol level 2 failed and hence tried 1. Another possible thing could be to try shutdown with level 2 and catch the exception and don't worry about what kind of exception it is, just go ahead and try protocol level 1. If there is exception with that too, we will just let the existing code take care of it the way it does today. Also, another outstanding issue was what if user has provided user name and password and protocol level 2 fails, then should we still try protocol level 1 with no user password and password? Would appreciate any feedback.
          Hide
          Kathey Marsden added a comment -

          Hi Mamta,

          If we have to check the error string I think DRDA_InvalidReplyHeader is a better string to search for as it won't change with localization. I think we should fail if user, password are specified and level 2 doesn't work as it is better not to give users the impression they are doing a credentialed shutdown if they are not. Once you get your new patch ready it would be good to do some testing wtih SSLTest and mixed versions to make sure we didn't make any wrong assumptions there.

          Show
          Kathey Marsden added a comment - Hi Mamta, If we have to check the error string I think DRDA_InvalidReplyHeader is a better string to search for as it won't change with localization. I think we should fail if user, password are specified and level 2 doesn't work as it is better not to give users the impression they are doing a credentialed shutdown if they are not. Once you get your new patch ready it would be good to do some testing wtih SSLTest and mixed versions to make sure we didn't make any wrong assumptions there.
          Hide
          Mamta A. Satoor added a comment -

          Attaching a new patch, DERBY4786_patch2_diff.txt, which sends shutdown command with protocol level 2 whether there is username or password provided or not. If this command fails because of DRDA_InvalidReplyHead from server, then resend the shutdown command but this time with protocol level 1. The attempt with protocol level 1 will be made only if there was no username and password supplied with the shutdown command.

          One issue I noticed this with change is if a client with the changes proposed by this patch sends a shutdown command to a 10.3 server(which does not have DERBY-2109 changes) without the username and password, it will get 2 exceptions back from the server. 1st exception will be for sending the shutdown command at protocol level 2 and the 2nd will be for shutting down the server succesfully. Server will also have 2 messages, first indicating that an invalid protocol level command was received and 2nd message saying that the server is shutdown. Let me show that by example

          Client with the patch applied will show following when it is trying to shutdown a 10.3 server
          $ java org.apache.derby.drda.NetworkServerControl -noSecurityManager shutdown
          Tue Sep 07 21:57:10 PDT 2010 : Invalid reply header from network server: Invalid string ←. Plaintext connection attempt to an SSL enabled server?
          Tue Sep 07 21:57:11 PDT 2010 : Apache Derby Network Server - 10.7.0.0 alpha - (1) shutdown

          The 10.3 server would show following for a shutdown command from a trunk client(with the patch applied)
          java.lang.Throwable: DRDA_UnknownProtocol.S, <2>
          at org.apache.derby.impl.drda.NetworkServerControlImpl.processCommands(NetworkServerControlImpl.java:1509)
          at org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:602)
          at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:266)
          Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
          org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
          at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:470)
          at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:340)
          at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:673)
          at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
          Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
          org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
          at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:470)
          at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:340)
          at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:673)
          at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
          Apache Derby Network Server - 10.3.3.1 - (1) shutdown at

          {2}

          I am not sure if we should try to mask this exception for the shutdown attempt with protocol level 2. Is it an ususal case any ways that a 10.3 server is being shutdown with a higher release client? Should we just document this behavior?

          Show
          Mamta A. Satoor added a comment - Attaching a new patch, DERBY4786_patch2_diff.txt, which sends shutdown command with protocol level 2 whether there is username or password provided or not. If this command fails because of DRDA_InvalidReplyHead from server, then resend the shutdown command but this time with protocol level 1. The attempt with protocol level 1 will be made only if there was no username and password supplied with the shutdown command. One issue I noticed this with change is if a client with the changes proposed by this patch sends a shutdown command to a 10.3 server(which does not have DERBY-2109 changes) without the username and password, it will get 2 exceptions back from the server. 1st exception will be for sending the shutdown command at protocol level 2 and the 2nd will be for shutting down the server succesfully. Server will also have 2 messages, first indicating that an invalid protocol level command was received and 2nd message saying that the server is shutdown. Let me show that by example Client with the patch applied will show following when it is trying to shutdown a 10.3 server $ java org.apache.derby.drda.NetworkServerControl -noSecurityManager shutdown Tue Sep 07 21:57:10 PDT 2010 : Invalid reply header from network server: Invalid string ←. Plaintext connection attempt to an SSL enabled server? Tue Sep 07 21:57:11 PDT 2010 : Apache Derby Network Server - 10.7.0.0 alpha - (1) shutdown The 10.3 server would show following for a shutdown command from a trunk client(with the patch applied) java.lang.Throwable: DRDA_UnknownProtocol.S, <2> at org.apache.derby.impl.drda.NetworkServerControlImpl.processCommands(NetworkServerControlImpl.java:1509) at org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:602) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:266) Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:470) at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:340) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:673) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277) Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:470) at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:340) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:673) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277) Apache Derby Network Server - 10.3.3.1 - (1) shutdown at {2} I am not sure if we should try to mask this exception for the shutdown attempt with protocol level 2. Is it an ususal case any ways that a 10.3 server is being shutdown with a higher release client? Should we just document this behavior?
          Mamta A. Satoor made changes -
          Attachment DERBY4786_patch2_diff.txt [ 12454175 ]
          Hide
          Mamta A. Satoor added a comment -

          I have started looking at SSLTest. Can someone more aware of the test please describe it a little? Does it already do testing with different releases of the network server product? Specifically, is there existing framework to do junit testing with client and server at different releases? Thanks

          Show
          Mamta A. Satoor added a comment - I have started looking at SSLTest. Can someone more aware of the test please describe it a little? Does it already do testing with different releases of the network server product? Specifically, is there existing framework to do junit testing with client and server at different releases? Thanks
          Hide
          Kathey Marsden added a comment -

          Hi Mamta, I will look at the patch today but to answer your question, I think the behavior you have is fine with existing old versions but we should backport the recognition of level 2 protocol to the early branches so users running on the latest version on the branch, won't see the error. I think we should be careful to document that moving forward, instead of changing existing commands, new API's should create a new COMMAND_XXX command instead of bumping the protocol version. Maybe a big code comment around PROTOCOL_VERSION would be a good place to put this.

          It would be good to have some sort of automated test for this. The comments in DERBY-3644 seem to indicate that the compatibility tests exposed the problem. Are those still run anywhere?

          Show
          Kathey Marsden added a comment - Hi Mamta, I will look at the patch today but to answer your question, I think the behavior you have is fine with existing old versions but we should backport the recognition of level 2 protocol to the early branches so users running on the latest version on the branch, won't see the error. I think we should be careful to document that moving forward, instead of changing existing commands, new API's should create a new COMMAND_XXX command instead of bumping the protocol version. Maybe a big code comment around PROTOCOL_VERSION would be a good place to put this. It would be good to have some sort of automated test for this. The comments in DERBY-3644 seem to indicate that the compatibility tests exposed the problem. Are those still run anywhere?
          Mamta A. Satoor made changes -
          Link This issue is required by DERBY-3644 [ DERBY-3644 ]
          Mamta A. Satoor made changes -
          Link This issue is related to DERBY-3644 [ DERBY-3644 ]
          Hide
          Knut Anders Hatlen added a comment -
          Show
          Knut Anders Hatlen added a comment - The compatibility tests are run in the Ole's nightly tests: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/compatibility_history.html
          Hide
          Kathey Marsden added a comment -

          Thanks Mamta.

          The patch looks good to me.

          Show
          Kathey Marsden added a comment - Thanks Mamta. The patch looks good to me.
          Hide
          Mamta A. Satoor added a comment -

          Please review the attached release note, especially the wordings in the "Rationale for Change" section. Thanks

          Show
          Mamta A. Satoor added a comment - Please review the attached release note, especially the wordings in the "Rationale for Change" section. Thanks
          Mamta A. Satoor made changes -
          Attachment releaseNote.html [ 12455118 ]
          Mamta A. Satoor made changes -
          Issue & fix info [Release Note Needed]
          Hide
          Mamta A. Satoor added a comment -

          Attaching a patch which modifies the really outdated testScript.xml This gets used to run the compaibility tests. In addition to trunk, it only tested upto 10.2 and didn't include all releases of 10.2 and 10.1 I have modified it to test all available releases upto 10.6 This will definitely increase the runtime of the compatibility tests.

          Show
          Mamta A. Satoor added a comment - Attaching a patch which modifies the really outdated testScript.xml This gets used to run the compaibility tests. In addition to trunk, it only tested upto 10.2 and didn't include all releases of 10.2 and 10.1 I have modified it to test all available releases upto 10.6 This will definitely increase the runtime of the compatibility tests.
          Mamta A. Satoor made changes -
          Attachment DERBY4786_testScript_patch3_diff.txt [ 12455400 ]
          Mamta A. Satoor made changes -
          Fix Version/s 10.6.2.1 [ 12315343 ]
          Fix Version/s 10.7.0.0 [ 12314971 ]
          Hide
          Knut Anders Hatlen added a comment -

          I don't think the fix made it into the 10.6 branch until after the 10.6.2.1 release candidate was produced, so I've changed the fix-version to 10.6.2.2.

          Show
          Knut Anders Hatlen added a comment - I don't think the fix made it into the 10.6 branch until after the 10.6.2.1 release candidate was produced, so I've changed the fix-version to 10.6.2.2.
          Knut Anders Hatlen made changes -
          Fix Version/s 10.6.2.2 [ 12315370 ]
          Fix Version/s 10.6.2.1 [ 12315343 ]
          Hide
          Mamta A. Satoor added a comment -

          Thanks for fixing the 10.6 version, Knut. I must not have synced my client when I did sysinfo on it.

          Show
          Mamta A. Satoor added a comment - Thanks for fixing the 10.6 version, Knut. I must not have synced my client when I did sysinfo on it.
          Mamta A. Satoor made changes -
          Fix Version/s 10.5.3.1 [ 12314182 ]
          Mamta A. Satoor made changes -
          Fix Version/s 10.4.2.1 [ 12313401 ]
          Hide
          Mamta A. Satoor added a comment -

          If there are no objections, then I will go ahead and commit the changes for briging up test script upto date (which are part of DERBY4786_testScript_patch3_diff.txt) on Friday.

          Show
          Mamta A. Satoor added a comment - If there are no objections, then I will go ahead and commit the changes for briging up test script upto date (which are part of DERBY4786_testScript_patch3_diff.txt) on Friday.
          Hide
          Mamta A. Satoor added a comment -

          Committed the test script changes with revision 1005193 into trunk

          Show
          Mamta A. Satoor added a comment - Committed the test script changes with revision 1005193 into trunk
          Mamta A. Satoor made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Rick Hillegas added a comment -

          Attaching a new version of the release note, incorporating Dag's comments on the 10.7.1 release notes.

          Show
          Rick Hillegas added a comment - Attaching a new version of the release note, incorporating Dag's comments on the 10.7.1 release notes.
          Rick Hillegas made changes -
          Attachment releaseNote.html [ 12459476 ]
          Rick Hillegas made changes -
          Fix Version/s 10.7.1.1 [ 12315564 ]
          Fix Version/s 10.7.1.0 [ 12314971 ]
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12519366 ] Default workflow, editable Closed status [ 12799286 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          35d 23h 10m 1 Mamta A. Satoor 06/Oct/10 19:08
          Resolved Resolved Closed Closed
          984d 15h 10m 1 Knut Anders Hatlen 17/Jun/13 10:19

            People

            • Assignee:
              Mamta A. Satoor
              Reporter:
              Mamta A. Satoor
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development