[
https://issues.jboss.org/browse/JGRP-1659?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1659:
--------------------------------
Ray,
can I get access to the RHEL box (is it in the lab) ?
As I said, I can run it many times on my Linux box, and it has blocked *exactly 0 times*
!
To be honest, I would also be surprised if MFC blocked as it has been in operation *in
production* for quite a while now and I have yet to get a report about MFC locking up.
I can run MPerf with a couple of nodes and each node sending 100 million multicast
messages, without MFC ever blocking.
I'm trying this on my mac now...
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