[
https://issues.jboss.org/browse/JGRP-1330?page=com.atlassian.jira.plugin....
]
Benoit Leblanc commented on JGRP-1330:
--------------------------------------
Within Request implementations (GroupRequest, MultiRequest and UnicastRequest), we count
received, not received and suspected responses, but never filtered ones.
There are two ways to fix it:
- Consider a filtered response as suspected one
- Create proper counter for not received response
Please let me know which solution did your prefer. If you want, I can submit to you a pull
request with the chosen implementation.
Dispatcher: incorrect RspFilter impl should not prevent termination
of call
---------------------------------------------------------------------------
Key: JGRP-1330
URL:
https://issues.jboss.org/browse/JGRP-1330
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.1
When a RspFilter returns false for isAcceptable() for all responses and
needMoreResponses() returns true all the time, then a call would block forever (if
timeout=0), or until the timeout kicks in.
This should be prevented; the new behavior would be:
GET_ALL:
- Terminate when the filter indicates it has sufficient responses (needMoreResponses() ==
false) OR when responses from all members have been received.
- The current behavior requires the RspFilter to keep track of responses and terminate
when no suitable responses have been received from all members
GET_FIRST:
- Terminate the call when 1 suitable response has been received, or when uisuitable
responses from all members have been received
Of course, both GET_FIRST and GET_ALL are also bounded by the timeout, as it currently
the case.
Similar behavior would exist for GET_MAJORITY
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira