JDK-6217140 : iiop memory leak with connector client create+start+stop
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 1.0.1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2005-01-13
  • Updated: 2010-07-29
  • Resolved: 2006-02-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6Resolved
Related Reports
Duplicate :  
JDK-6354718 - client connections to ORB are neither freed nor garbage collected (java 1.5)
Description
Looks like there is a memory leak by looping over Connector Client create + start + stop with the iiop protocol. A single Connector Server started once for all is used for that test.
We do test run of 1 hour long each; the PASS criteria is to have a 30 minutes period where the heap no more increase.
See Comments for measures done on:
- Solaris 9 on Sparc
- Windows XP Pro SP2 on Pentium 4
Note that for 3 hours long run, they fail equally.
Note that with rmi over jrmp, there is NO leak at all.
###@###.### 2005-1-13 14:16:35 GMT

Starting Mustang b37, the symmetric test with rmi/jrmp fails equally.
The run is 1 hour long and we check the memory does not increase after 30 minutes of run; but after 35 to 41 minutes, we see an increase on Sparc Solaris 10 (no measure for other platforms).
###@###.### 2005-05-30 07:12:50 GMT
Comments
EVALUATION Forgot to say in my previous update that the new test duration 8h/1h allows to get the test green with rmi. But iiop is still red.
13-12-2005
EVALUATION Changing the test configuration to 8 hours total time and 1 hour period without memory allocation does not solve. I feel we are possibly affected by the leak described into 6354718.
08-12-2005
EVALUATION Suggest QA to run the test with a more reasonable time configure. So set status to "Incomplete".
07-12-2005
EVALUATION With the simple test code: while (!myCB.ended) { client = JMXConnectorFactory.newJMXConnector(url, null); client.connect(); client.close(); } cannot reproduce the bug for both rmi and iiop, on JDK 1.5 and 1.6, the test machine is "SunOS sr-egnb07-03 5.9 Generic_117171-17 sun4u sparc SUNW,Sun-Fire-V440" Suggest the QA to re-configure the test with a logger time for the "Total time" to run, like 2 hours instead of 1 hour. ###@###.### 2005-06-02 09:49:56 GMT It looks to be more subbtle than changing tests; if a test is made less strict we take risk to miss regressions. Anyway, the point is that it looks related to the underlying OS. I made further test run with Mustang b38 on various Sparc hardware (Ultra 10, E450) and two update level of Solaris 10 : the FCS release tagged 74L2a and an Update 1 release tagged U1_07. With Solaris U1, the memory increases the first 10 to 15 minutes then test is green. With Solaris 74L2a, the memory continuously increases then test is red. I even used the same hardware and reinstalled Solaris 10 U1 between two tries and saw the same test changing from red to green. It means that the combination Solaris 10 FCS + Mustang b38 is leaky and installing Solaris U1 solves the problem from a customer point of view. However, there is perhaps an issue on the jvm side (timing ?) that could allow under some circumtances only the leakage. Please refer to the new attachement leakTestRun.html for details on tests done. ###@###.### 2005-06-06 09:29:03 GMT To set a longer time for "total running time" does not make the test less strict. In fact it is more reasonable because it is possible that an application increases its used memory during long time, for example one hour before stopping increasing, in this case it is not correct to set the "total running time" to one hour. It is much sure to get a correct test by setting a long "total running time". Especially, a long "total running time" does not mean we have to take that long time to finish the test, the class "MemoryMonitor" uses another parameter "maxTimeWithoutIncreasing" to stop the test earlier, that means the test will be stopped as passed if the class MemoryMonitor finds that no increasing memory after the time "maxTimeWithoutIncreasing". ###@###.### 2005-06-06 09:55:22 GMT I have run the QA test repeatly in same way and on same environment, but with a longer running time: one day. After one week running, the result is NO MEMORY LEAK. To use the class MemoryMonitor to determine memory leak is sophistic, it is heavily dependent to timing configuration and tests. If the total running time is set to a short one: one or 2 hours like today's QA configuration, the failed result can be used as a warning, and it needs us to re-run the tests with a more important timing configuration. Suggest to close this bug as not-a-bug, and to re-run all other failed memory tests with a longer running time, for example one or two days. ###@###.### 2005-06-21 07:27:57 GMT
02-06-2005