[jboss-jira] [JBoss JIRA] (JGRP-1659) deadlock in MFC with default configuration
Ray Tsang (JIRA)
jira-events at lists.jboss.org
Wed Jul 17 09:27:26 EDT 2013
[ https://issues.jboss.org/browse/JGRP-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790313#comment-12790313 ]
Ray Tsang commented on JGRP-1659:
---------------------------------
Bela Ban,
Regarding the size and number of entries, it doesn't matter if it's 100,000 entries or just 10,000 entries. All nodes were blocked very early anyways. It's set to 100,000 in case tester aren't fast enough to get around to all nodes to start it.
The original config has no max_block_time set, which would take the default of 5s. I think Mircea may have set it to 1 to prove a point. Regardless, the block happens with the default 5s as well.
> deadlock in MFC with default configuration
> ------------------------------------------
>
> Key: JGRP-1659
> URL: https://issues.jboss.org/browse/JGRP-1659
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.7
> Reporter: Mircea Markus
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: expiration-test.zip
>
>
> MFC.down does the following:
> {code:java}
> credits.decrement(length, block_time); //A
> if(needToSendCreditRequest()) //B
> sendCreditRequest(tuple.getVal1(), Math.min(max_credits)
> {code}
> A blocks forever even if the MFC.max_block_time is configured:
> {code:xml}
> <MFC max_credits="200k" min_threshold="0.20" max_block_time="1"/>
> {code}
> This happens at the same time on the whole cluster. B never gets invoked, so both wake up conditions( credits received or timeout) for credits.decrement are never satisfied resulting in the whole cluster to freeze.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list