[
https://issues.jboss.org/browse/JGRP-1851?page=com.atlassian.jira.plugin....
]
Bela Ban edited comment on JGRP-1851 at 9/26/14 4:50 AM:
---------------------------------------------------------
We could also add a check for UNICAST3 and ignore RSVP handling for unicasts if UNICAST3
is present, as UNICAST3 does resend messages itself. This essentially makes RSVP only
needed by NAKACK2 (and UNICAST2, but this is deprecated anyway).
was (Author: belaban):
We could also add a check for UNICAST3 and ignore RSVP handling for unicasts if UNICAST3
is present, as UNICAST3 does resend messages itself.
RSVP: add option to not block caller
------------------------------------
Key: JGRP-1851
URL:
https://issues.jboss.org/browse/JGRP-1851
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.6
In RSVP we have a {{resend_interval}} at which empty messages are sent to trigger
retransmission and a {{timeout}} which is the max time a caller will block until all acks
have been received.
In the {{down()}} method, the caller blocks until all acks have been received or a
timeout occured. Then the resend task is stopped and the entry removed from the {{ids}}
map.
In some cases, we may want to not block the caller, so that the calling thread returns
immediately, but nevertheless perform resending until all acks have been received or the
timeout occurred. This is a new property {{block}}.
An example of where this is useful is {{RpcDispatcher.callRemoteMethodsWithFuture()}}:
here, we want the call to return immediately with a future, and then - later - potentially
block on it. However, if we have the RSVP flag set, then sending the message will block in
RSVP until all acks have been received. This breaks the semantics of
{{callRemoteMethodsWithFuture()}}.
Another example is async RPCs (mode={{GET_NONE}}); here we'd block if RSVP is set
even though we shouldn't.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)