[jboss-jira] [JBoss JIRA] Commented: (JGRP-1330) Dispatcher: incorrect RspFilter impl should not prevent termination of call

[Benoit Leblanc (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629392#comment-12629392 ] 

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