[concurrency-interest] Any fix for bug 6460501: AbstractQueuedSynchronizer$Node memory leak in BlockingQueues

David Walend 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  
fixes it.

Thanks again,

Dave

David Walend
david at walend.net




More information about the Concurrency-interest mailing list