Re: [jgroups-users] jgroups - callRemoteMethodsWithFuture blocks on coordinator crash

I have not used blocking RPCs since there are scenarios in which plenty of
messages have to be sent one after the other and using a blocking RPC will
increase the RTT. I have implemented the application with async calls but
the responsibility of tracking is with the application. The senders return
immediately and the receivers send the response in a separate RPC.
Collecting the individual responses of various calls and compiling a final
response is done by the sender. Although this is in place I find this
approach a bit complicated. Moreover I am not sure whether replacing
blocking calls by making the receivers send their responses in a separate
RPC is a better approach. callRemoteMethodsWithFuture seemed to be a better
alternative but the application does not tolerate longer delays. I agree
that using a bounded blocking call will solve this for me. I am looking for
a better alternative which combines the best of both the approaches.
The callRemoteMethodsWithFuture  does take a RequestOptions argument. I am
specifying a timeout in the request options. "*new
RequestOptions(ResponseMode.GET_ALL, 3000, false, new
MasterResponseFilter());*" I was hoping that when the coordinator crashes,
this timeout would be used. But the timeout is simply ignored by the
underlying implementation. This is why I wasn't sure of the behavior. What
are your thoughts on this?

- Kishore

On Thu, Aug 31, 2017 at 12:55 PM, Questions/problems related to using
JGroups <[email protected]> wrote:

> This is the expected behavior.
>
> Consider a similar case where you're making a blocking RPC on all cluster
> members.
>
> If one of the members crash during the RPC and is thus not able to send a
> response, the caller will block until either a timeout occurs (if the call
> is time-bounded) or failure detection kicks in and marks the response of
> the crashed member as faulty, so that the call can return.
>
> You could try bounding your blocking RPCs or make them async if the app
> allows that...
>
>
> On 31/08/17 09:08, Questions/problems related to using JGroups wrote:
>
>> The problem is with SEQUENCER in the stack, callRemoteMethodsWithFuture()
>> is blocking until the message is forwarded to the coordinator. Coordinator
>> loss during such situations make the call blocking until a view change
>> occurs. This is something I want to avoid in my application. When I tested
>> without SEQUENCER in the stack the call does not block until a view change
>> but removing SEQUENCER is not an option in my application. If this is the
>> expected behavior then how does one overcome this delay in processing?
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> javagroups-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>>
>>
> --
> Bela Ban | http://www.jgroups.org
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users