• Sun
    January 4, 2008

A NSS/JSS Bug is Fixed

Guest Author
Someone reported that their J2EE agent 2.2 periodically hangs. The thread dump shows that over hundreds threads waiting for a lock that was held by a thread writing a log message to the remote Access Manager (AM) server.
        at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)

This stack trace is not new to me. I have seen this kind of thread stack trace many times, especially on AM servers. The difference is that on AM server, there could be many threads doing socketRead when all sending session/policy notifications, as this operation is asynchronous. The common thing is that this problem only happens when AM server or client running in secure mode. Basically SSL is enabled.
This is not an AM/agent problem, but root in NSS/JSS/NSPR packages. This morning, I checked the latest NSS/JSS/NSPR patch 119211-14(Solaris 9). I am very happy to this
bug 6524809 - JSS SSLSocket.close() may be blocked and not interrupting the SSLSocket.read() thread. Actually it is fixed in rev #13. I strongly believe that this bug might be responsible to all AM/agents hang issues with SSL enabled
Solaris 8 SPARC:    119209-13
Solaris 9 SPARC: 119211-13
Solaris 9 X86: 119212-13
Solaris 10 SPARC: 119213-13
Solaris 10 X86: 119214-13
Linux: 121656-13
HP-UX pa-risc: 124379-04
JES5 Windows: 125923-02
JES5 Solaris SPARC: 125358-02
JES5 Solaris x86: 125359-02

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.