[concurrency-interest] Any fix for bug 6460501: AbstractQueuedSynchronizer$Node memory leak in BlockingQueues
david at walend.net
Sat Dec 2 12:53:15 EST 2006
On Dec 1, 2006, at 1:01 PM, Dawid Kurzyniec wrote:
> David Walend wrote:
>> I need your help with a leak of
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$Node s I'm
>> seeing in a big application using SomnifugiJMS. ...
>> Any suggestions for a fix or a work-around? Is there one already
>> in the concurrency backport?
> There is jsr166.jar, updated on September 5, in which there is some
> fix labeled "Avoid memory leak on timeouts". I don't know if it
> fully solves the problem, I guess this is a question to Doug Lea.
> If yes, then I believe that by putting this JAR on your
> bootclasspath, you can override the platform's java.util.concurrent.
> I suppose you could try using the backport as well. But don't use
> the backport version for "5.0", since it is using the native AQS
> and will probably suffer from the same problem. You would have to
> use standard 1.4 backport, which does not rely on AQS at all, but
> it may have a performance impact. (Depending on the application, it
> may be unnoticeable, but it may be substantial, too).
> Also, I would consider looking at the application logic, to see if
> you can avoid short timeouts in the first place. Short timeouts
> indicate that you're waiting for something else while trying to
> enqueue. Maybe you can write a specialized queue, that wakes up
> your putter thread once that something else happens?...
Thanks for the suggestions, Dawid. You're right about the application
logic (built by a guy who has since left our group), but that will
take some effort to fix. From a design perspective, there's no need
to have a time out. No one picked it up because no one has let the
system sit idle that long. I'll post next week if the backport .jar
david at walend.net
More information about the Concurrency-interest