[jboss-jira] [JBoss JIRA] (JGRP-1498) Deadlock in SEQUENCER

[David Hotham (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714052#comment-12714052 ] 

David Hotham commented on JGRP-1498:
------------------------------------

Thanks
                
> Deadlock in SEQUENCER
> ---------------------
>
>                 Key: JGRP-1498
>                 URL: https://issues.jboss.org/browse/JGRP-1498
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.1
>            Reporter: David Hotham
>            Assignee: Bela Ban
>             Fix For: 3.2
>
>
> I've just seen a deadlock in SEQUENCER, which I think occurs as follows:
> -  Start of day.  coord=null, ack_mode=true, flushing=false.
> -  First view arrives.  We call handleView(), and start a Flusher
> -  On the Flusher thread, flush() gets as far as waiting to acquire the send_lock, but doesn't yet have it.
> -  Meanwhile on Thread 2, the application tries broadcasting a message.  This gets as far as the trace "forwarding my-address::1 to coord null", but does not yet enter forwardToCoord().
> -  Now on Thread 3, a second view arrives.  handleViewChange() finds that coord_changed is true, and calls stopFlusher().  This sets flushing=false.
> -  Now Thread 2 picks up.  flushing=false, ack_mode=true; so forwardToCoord() gets as far as acquiring the send_lock.
> -  Now Thread 2 loops around making no progress.  forward() always drops the message, because coord is null.  The send_lock is never relinquished
> -  So the Flusher thread can never acquire the send_lock, and the Flusher can't exit
> -  And so Thread 3 is stuck too, in stopFlusher().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira