JDK-6959550 : Possible memory leak in RMI-IIOP EJB clients in JRE 6u19
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:orb
  • Affected Version: 6u19-rev
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2010-06-08
  • Updated: 2011-01-20
  • Resolved: 2010-10-04
Related Reports
Duplicate :  
JDK-6964164 - +MonitorInUseLists can cause leakage of contended objects
Description
Customer has a chat application that runs fine with JRE 6u16. They moved to JRE 6u19-rev-b07 only to see memory grow to over 7G after 5 days. Investigation of histograms and heap dumps point to a potential issue with RMI-IIOP EJB clients.

The READMEs identified CRs 6763340 and 6828768 are the only changes to RMI. Could this issue be a regression bug from one these CRs?
Comments
EVALUATION Here is input from the WebLogic engineer who did a code review with the customer. This issue is not related to the bugs mentioned. I did complete the Oracle web session to the Verizon application code. Here is the summary from my reading to the code. There is a weblogic cluster with two managed servers. Managed server1 is called as "user server" and the managed server2 is called as "session server". The RMI calls are happening between the user-server and the session-server. There are no weblogic thin clients. It is all server-to-server RMI calls. The user clients are web clients, html (chat session). The session-server acts as the RMI client and the user-server acts as the RMI Server. Session-server is doing RMI call to the user-server. A timer task (every 10 seconds) does invoke this RMI call in the session-server. In this RMI call latest encore queue's details are being received as HashTable (nested one) by the session-server (RMI client) and that hashtable (received over the wire) is being used read and update the local variables, hashtables. This is very strait forward RMI call. Nothing is unusual and nothing susceptible neither in application code nor in the weblogic RMI implementation layer. It might be not a weblogic RMI issue. As per the Tao's update as of now OOME seen only on the session-server (RMI client), the heap dumps were collected so far on the session-server (managed server2 of the cluster), the issue not seen with old JDK version when reverted from the latest JDK, 6u19. It appears to me hashtable objects received over the wire by the session-server (RMI client) **seems** becoming part of the unreachable objects and either not being collected or happening delayed collection by the CMS GC in the jdk6 u19 is the issue. Unreachable objects are not unusual in the heapdump but its growth is unusual here. I agree with Rick that JDK-Dev-RMI and JDK-Dev-GC expertise is needed to isolate the reason for why the unreachable objects��� claiming is differed in the 6u19 from the previous jdk 6u16. This could be a new bug or regression from other. The interim workaround could be tuning at GC/DGC related parameters with the help of JDK dev.
09-06-2010
EVALUATION Data is at /cores_data/pool-1/data12/72545182/ Customer used this command to collect heap dumps. jmap -d64 -heap:format=b I am working with Ramki. He asked to add -dump:live. Both CRs said issue is with thin client WebLogic. I am confirming with the customer that they are using the thin client.
08-06-2010