[
https://issues.jboss.org/browse/JGRP-1193?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1193:
--------------------------------
We can continue using RspFilter if:
#1 In GroupRequest.receiveResponse(), we move the lock acquisition up to include both
calls (to isAcceptable() and needMoreResponses()). This will get rid of the race condition
Brian mentioned
and
#2 If we increment num_received when a response is received, and not dependent on the
result of RspFilter.isAcceptable()
This way, a RspFilter's isAcceptable() method *can* actually return false on a null
value, and we wouldn't wait until timeout if we only receive null values...
Simplify RspFilter interface
----------------------------
Key: JGRP-1193
URL:
https://issues.jboss.org/browse/JGRP-1193
Project: JGroups
Issue Type: Task
Affects Versions: 2.7, 2.8, 2.9
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
Fix For: 3.0
RspFilter interface although having only two methods in its contract has been a source of
some confusion regarding the semantics of response filtering. In order to simplify and
make response filtering semantics easier to understand and implement a new RspFilter has
been proposed for 3.0.
RspFilterResult responseReceived(Object response, Address sender);
RspFilterResult is an enum with four states where each state is essentially a combination
of two boolean variables: validResponse and needMoreResponses.
Original discussion reference:
http://sourceforge.net/mailarchive/forum.php?thread_name=4BC8943F.2000101...
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira