]
Bela Ban updated JGRP-656:
--------------------------
Attachment: tmp.java
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: