1 Reply Latest reply: Jan 12, 2012 10:00 PM by Arshad Noor RSS

    LDAP/SSL performance degradation with 1.6.29/1.6.30

    910667
      Hi,

      we are running an application within a Tomcat 6.0.35 server on RHEL 5.7/i386 that queries our company's Active Directory using LDAP over SSL. One of the queries involves expanding a large distribution list. Since the upgrade from JDK 1.6.27 to 1.6.29 (or 1.6.30) the performance of this LDAP query has degraded dramatically, from about 8 seconds to more than 300 seconds. This only happens when encrypting the LDAP connection.

      We are not sure how to debug this further. Which information would we need to provide to get to the root of this? I was thinking that perhaps the Tomcat output with the javax.net.debug=ssl,handshake property set for 1.6.27 and 1.6.29/30 would be sufficient?

      With Java 1.6.29/30, the basic response/reply between the Tomcat and the AD server looks like:

      TP-Processor11, WRITE: TLSv1 Application Data, length = 32
      TP-Processor11, WRITE: TLSv1 Application Data, length = 160
      Thread-270, READ: TLSv1 Application Data, length = 16368
      Thread-270, READ: TLSv1 Application Data, length = 16368
      Thread-270, READ: TLSv1 Application Data, length = 11920
      TP-Processor11, WRITE: TLSv1 Application Data, length = 32
      TP-Processor11, WRITE: TLSv1 Application Data, length = 160
      Thread-270, READ: TLSv1 Application Data, length = 16368
      Thread-270, READ: TLSv1 Application Data, length = 16368
      Thread-270, READ: TLSv1 Application Data, length = 11920

      When using Java 1.6.27, we see:

      TP-Processor12, WRITE: TLSv1 Application Data, length = 208
      Thread-42, READ: TLSv1 Application Data, length = 16368
      Thread-42, READ: TLSv1 Application Data, length = 16368
      Thread-42, READ: TLSv1 Application Data, length = 5696
      TP-Processor12, WRITE: TLSv1 Application Data, length = 208
      Thread-42, READ: TLSv1 Application Data, length = 16368
      Thread-42, READ: TLSv1 Application Data, length = 16368
      Thread-42, READ: TLSv1 Application Data, length = 5696

      Looking at the 32 bytes long requests (with javax.net.debug=all set), we see:

      Padded plaintext before ENCRYPTION: len = 32
      0000: 30 0C C2 32 83 6E 9F D8 8F 5E E8 47 7A 0B 9A F1 0..2.n...^.Gz...
      0010: 7D 44 78 0B 9E 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A .Dx.............
      TP-Processor1, WRITE: TLSv1 Application Data, length = 32

      Which doesn't make a whole lot of sense to us...

      Any help debugging this further would be most welcome.

      Cheers
      Stefan

      Edited by: user9158206 on Jan 12, 2012 6:06 AM