Friday Jan 04, 2008

A NSS/JSS Bug is Fixed

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

About

gc

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today