1. Derby
  2. DERBY-3106

securityMechansim=8 causes slowdown on some JVMs?


    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s:
    • Fix Version/s: None
    • Component/s: Network Client
    • Environment:
      IBM JVM 1.42, SLES 10 or SLES 10 SP1
    • Urgency:
    • Issue & fix info:
      Repro attached
    • Bug behavior facts:


      1. We have a Web App that uses Derby 10.2, doing client/server. It is a Java 1.4 app
      2. We run it extensively on Windows (JDK 1.4,1.5/Tomcat 4.1/5.5), SLES 9, SLES 10, OES, and NetWare
      3. Recently I added securityMechanism=8 to the JDBC URL to at least encrypt the password (it's all local right now, but it was a nicety). Extensive testing on Windows proved flawless.
      4. Immediately after releasing to Beta testers, we heard the "UI" was slow. I traced this specifically to pages that accessed Derby Connections (or built them into a pool - there are depressing reasons why we don't do this all the time currently).
      5. The issue only occurs on SLES 10/10 SP1. It occurred for about 80% of users, and was oddly intermittent. The slowdown did NOT occur on initial login, but after they added some entries (adding some fields to some tables effectively). From then on, the slowdown was rampant and survived restarts. Even the login (which queries some DBs) was very very slow
      6. A test JSP page was created, which basically will be attached, but did nothing more than create a Connection, do a simple query, iterate the result set. Then do the same thing without the security Mechanism. Then spit out benchmark numbers.

      On my box (Windows), the numbers were typically a total of less than 10 ms for the queries. On machines exhibiting the issue, they were 80 SECONDS!

      As soon as the securityMechanism=8 was removed, the issue disappeared.

      Now, I'm not really sure I should blame Derby. My offhand gut guess is there is something wrong with the IBM JVM 1.42, doing the encrypted password and Derby took a long time to timeout and then backed down to cleartext..

      But I don't have a lot of time to test this one out. So I'm mostly posting FYI.

      (Additional: Connection logging was performed and not that interesting. Telnet to derby server was quick - it appears it is all in the client negotiating the connection that the slow down occurs).

      1. goo.jsp
        2 kB
        mike bell
        2 kB
        Kathey Marsden

        Issue Links


          mike bell created issue -
          mike bell made changes -
          Field Original Value New Value
          Attachment goo.jsp [ 12367128 ]
          Kathey Marsden made changes -
          Attachment [ 12412629 ]
          Kathey Marsden made changes -
          Bug behavior facts [Performance]
          Urgency Normal
          Issue & fix info [Repro attached]
          Kathey Marsden made changes -
          Labels derby_triage10_5_2
          Kathey Marsden made changes -
          Labels derby_triage10_5_2 derby_triage10_9
          Gavin made changes -
          Workflow jira [ 12414362 ] Default workflow, editable Closed status [ 12798259 ]
          Knut Anders Hatlen made changes -
          Link This issue is related to DERBY-6702 [ DERBY-6702 ]


            • Assignee:
              mike bell
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: