[timfox]

Ron-

From my POV, I guess the important thing right now is to get it to the state where the test can be run in infinite loop opening and closing multiplex connections without running out of memory or failing in any other way, and sustain a connection creation/close rate of the same order of magnitude as the socket transport.

Wdyt?

[ron_sigal]

Tim,

When I run your program as is, I have the problem I mentioned above with shared MultiplexClientInvokers, which causes the program to fail at some random iteration. However, what I see when I run it that way (from an ant script) is a small number (say 2 - 6) of open sockets hanging around. I don't know at which iteration it is failing because the junit task holds the output until the task ends, but when I run the program in Eclipse I've seen anywhere from around 15 to around 75 iterations.

When I apply the workaround (adding localPort to the end of the Client's InvokerLocator) to prevent shared MultiplexClientInvokers, and run netstat manually, I see what I've always seen - some sockets briefly open (I saw 26 at one point) and then none.

So, basically, I'm doing exactly what you're doing. This is baffling.

I'm going to look at the memory leak problem today - I've just got JBoss Profiler installed. Then I'll look at performance.

[timfox]

Which jdk are you using?

I am using 1.4.2.

If you're using 1.5 can you try with 1.4?

Cheers

Tim

[ron_sigal]

I'm running 1.4.2_06 on a linux machine and 1.5.0_06 on Windows XP. Just to be anal I copied the program to the linux machine again to make sure I was running the same code - got the same results.

[ron_sigal]

Tim,

I've made some progress on the out of memory problem I get when running your program. Originally, it was running out of memory after around 2200 iterations. I'm running a long test now, and it's up to around 205,000 iterations. The heap seems to have stabilized around 30-60 MB. Seems kind of high, but it's not out of control.

Now, I can't imagine how this could affect the open socket problem, but you might try rebuilding Remoting to see what happens.

[timfox]

30-60M seems a lot of overhead for zero open connections :)

Have you tried running a memory profiler on it to find out what is taking up the memory and where it is allocated from?

205000 is certainly better but we need it to be able to run indefinitely without failure.

[ron_sigal]

Your program ran 1,000,000 iterations over night.

I also collected some profiling data over night. I'll look at them today.

[clebert.suconic]

With JVMTIInterface (from jbossProfiler) you could do...


jvmtiInterface.getInstancesOfObject(Class);


than you could validate memory leaks in testcases if you want.