Re: [jgroups-users] Odd RPC behavior

[Jim T. <jim...@no...>]

I think that is a good idea.  In my use case I need ensure that the calls
will go through with high probability in a reasonably short period of time
but I can't afford to wait around to retry or branch on a failure.
 However, one thing I have noticed is that I wish I could configure
multiple settings for RSVP.  I have one place where the exceptions and
blocking does make sense, so I have turned on the exception -- I just have
to handle it in the places where I didn't need it.   I suppose I could use
fork stacks to have different RSVP behaviors.

>From a strictly RPC point of view it may make sense to put an RSVP-like
feature (verify?) into the call options that is coupled with the timeout of
the RPC call.  Then on GET_NONE rather than the timeout being ignored it
could be the verify timeout.  I think you would just need to have another
constructor for call options that would allow setting the resend interval
and timeout behavior.  That would eliminate the confusion of an RSVP
timeout and a call timeout and allow more granularity on how RPC works on a
per-call basis.

JT

On Thu, Jun 12, 2014 at 8:20 AM, Bela Ban <be...@ya...> wrote:

> RSVP is not supposed to know about RPCs (GET_NONE or GET_ALL); it only
> deals with messages. So this change would be bad as it breaks
> encapsulation.
>
> However, you have a point: some callers may not want to block, even
> callers with GET_FIRST or GET_ALL. I created [1] to take care of this.
> Low prio, but I hope to get it into 3.5.
>
> [1] https://issues.jboss.org/browse/JGRP-1851
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> javagroups-users mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>