Re: [javagroups-users] Jgroups 2.2.9 Sender thread leak ?

[Bela B. <be...@ya...>]

Okay, I fixed this, the new code is now
|            void stop() {
                if(senderThread != null) {
                    if(send_queue != null)
                        send_queue.close(false);
                    Thread tmp=senderThread;
                    senderThread=null;
                    tmp.interrupt();
                    running=false;
                }
            }|

Let me know whether this works, I'll check it into CVS in ca 10 minutes 
(once the unit tests pass successfully)

David Forget wrote:
>
> Hi,
>
>             We found some issue using JGroups 2.2.9 in TCP mode. With 
> a cluster of 10 nodes with one node that only connect and disconnect 
> to the group every minutes. We observer in this scenario using Thread 
> Dumps that some members have a Sender thread leak (10 receivers 
> threads, 325 Senders threads).  
>
>  
>
> Note: JGroups 2.2.8 does not have the same problem.
>
>  
>
>  
>
> Here is a piece of code from the Connection.Sender inner class in the 
> ConnectionTable.java file.
>
>  
>
> void stop() {
>
> if(senderThread != null) {
>
> senderThread.interrupt();
>
> senderThread=null;
>
> running=false;
>
> }
>
> }
>
>  
>
> public void run() {
>
> byte[] data;
>
> while(senderThread != null && 
> senderThread.equals(Thread.currentThread())) {
>
> try {
>
> data=(byte[])send_queue.remove();
>
> if(data == null)
>
> continue;
>
> _send(data, 0, data.length);
>
> }
>
> catch(QueueClosedException e) {
>
> break;
>
> }
>
> }
>
>  
>
> The problem with this code is that when the stop() method is called, 
> it is possible that the thread exits from the send_queue.remove() with 
> null. If this thread executes, loops and blocks on the remove method 
> again before the senderThread is put to null, the thread will be 
> blocked forever (Note that the interrupt flag of the thread is reseted 
> after throwing an InterruptedException so that the next wait() will 
> not exit). Because of the Reaper thread, this can cause a severe 
> memory leak and crash the application.
>
>  
>
> The fix we suggest is to modify the stop() method of the Sender class 
> and add a call to send_queue.close().  This way, even if the Sender 
> thread loops and re-executes the send_queue.remove() method, the 
> remove() method will throw a QueueClosedException and the thread will 
> terminate properly. We have tested this fix and it successfully 
> prevents the Sender thread leak.
>
>  
>
> void stop() {
>
> if(senderThread != null) {
>
> *send_queue.close(false);*
>
> senderThread.interrupt();
>
> senderThread=null;
>
> running=false;
>
> }
>
> }
>
>  
>
> Regards,
>
>  
>
> David Forget
>

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
callto://belaban