[jboss-jira] [JBoss JIRA] (JGRP-1851) RSVP: add option to not block caller
Bela Ban (JIRA)
issues at jboss.org
Tue Sep 30 03:56:02 EDT 2014
[ https://issues.jboss.org/browse/JGRP-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bela Ban resolved JGRP-1851.
----------------------------
Resolution: Done
> 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)
More information about the jboss-jira
mailing list