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

Okay, I tried to achieve this by using async calls. Even when the mode is
'GET_NONE', a broadcast using callRemoteMethods will block if
1. The coordinator crashes/loses network connectivity before the broadcast
has been made &
2. SEQUENCER is in the stack.

None of the request options seem to be applied to the unicast message sent
to the coordinator internally.

- Kishore

On Thu, Aug 31, 2017 at 1:56 PM, kishore kumar <[email protected]>
wrote:

> 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