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
