[jboss-jira] [JBoss JIRA] Created: (JGRP-656) Flag to determine when a message is considered delivered
Bela Ban (JIRA)
jira-events at lists.jboss.org
Sat Jan 5 11:58:43 EST 2008
Flag to determine when a message is considered delivered
--------------------------------------------------------
Key: JGRP-656
URL: http://jira.jboss.com/jira/browse/JGRP-656
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.7
Attachments: tmp.java
Okay, I know what the problem is.
When a multicast message is received from sender A, then a lock is acquired for A (or we block until A's done processing the message and releases the lock).
When the receive() method would send more messages down the stack, that lock might get held for potentially a long time. So I made the following change: I assume that calling down() from within receive() means that the message has been *delivered*, so I release the lock held for A and someone else can now acquire that lock. If you comment the lines of ProtocolStack.down() and recompile JGroups, then you will always see a count of 1:
public Object down(Event evt) {
ReentrantLock lock=locks.remove(Thread.currentThread());
//if(lock != null && lock.isHeldByCurrentThread()) {
// lock.unlock();
//if(log.isTraceEnabled())
// log.trace("released lock held by " + Thread.currentThread());
//}
if(top_prot != null)
return top_prot.down(evt);
return null;
}
The issue here is that I don't want to block incoming calls just because the receive() method sends other messages. This is described in http://jira.jboss.com/jira/browse/JGRP-535.
I might introduce a flag in ProtocolStack to configure this behavior...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list