ok, I will try to do the following tests, this night, in Italy it's
night already.
I will do a 'sending' session of 3000 messages for 4 different clients
at the same time, then I will check the amount of instances,
I will leave the application without load, for some time, and then check
again if the system released the objects.
If it is not so, I think there is a problem, correct? In that case I
will try to print the references to the classes which held the objects.
I will share with you the results. And I will try the JDK 6.
Thanks again,
Luca
Holger Hoffstaette ha scritto:
On Wed, 25 Oct 2006 20:52:32 +0100, Robert Greig wrote:
On 25/10/06, Luca Zago <[EMAIL PROTECTED]>
wrote:
I don't know how to interpret this behavior, but these objects after one
night of running tests are the majority in the application.
Is it definitely a leak? If you look at the code in the ExecutorFilter you
can see that it add events for that session - e.g. data read from the
network - and those events are processed in order for the session by a
thread from the pool.
That was my question as well - in Mule's case Luca reported a leak in a
similar event handler, yet after looking at the source in question I could
not see how that leak could actually ever happen because items are always
removed via take(), regardless of errors etc. Considering that the
backport's LinkedBlockingQueue is a straight 1:1 port and tested with the
JSR 166 tck suite I'd be more than surprised if there really was a bug
somewhere. It's just a fancy single-linked list after all.
IMHO it's much more likely that there's something fishy with JProfiler or
the way Luca uses it. (I've never used JProfiler)
Luca, if you can please try the same tests with JDK 6 and use jhat (part
of the Mustang tools). It will show you exactly how many live objects are
held by which owner.
Holger
