Re: [jgroups-users] RPC Timing Out

On 16/06/16 07:31, Questions/problems related to using JGroups wrote:
> Bela,
>
> We had tried 0 in the distant past and it did not work [for us] as
> crashes did not cleanly terminate the calls.

That should have worked, even in 3.0.x. Did you use both FD_ALL and 
FD_SOCK? The latter should immediately suspect and remove a crashed 
member, unless you have a high timeout in VERIFY_SUSPECT. If FD_SOCK was 
not used, then the time to terminate the call on a crashed member would 
be a function of the timeout in FD_ALL.

>  Hence we had added the keep alive code.  However, preliminary testing indicates that timeout
> of 0 works well in 3.6.9.

OK, excellent!

> We will continue down this road and report back any issues.  Thanks
> for putting us back on the path ;)

It's good to remove code that does something that should be done by 
JGroups properly. I'm always interested in making sure that JGroups does 
the job it's supposed to do, and fix things that don't work the way 
they're supposed to work...
Cheers,

> Regards, Neal
>
> -----Original Message----- From: Questions/problems related to using
> JGroups [mailto:[email protected]] Sent:
> Wednesday, June 15, 2016 12:08 AM To:
> [email protected] Subject: Re: [jgroups-users]
> RPC Timing Out
>
> If the RPC can never deadlock, why don't you set a timeout of 0
> (which disables timeouts)? Eventually the data will be received and
> the call will terminate. A crash of the sender or receiver will cause
> the call to terminate; the failure detection protocol(s) will do
> this.
>
> Perhaps I don't understand what you're trying to do; in that case, a
> unit tests will help... :-)
>
> On 14/06/16 23:47, Questions/problems related to using JGroups
> wrote:
>> Hello all,
>>
>> We have some RPCs that return fairly significant amounts of data.
>> As a result, those calls can be prone to time out.  In order to
>> combat that issue we have, on 3.0.2, added code that sends messages
>> up the stack to keep the RPC from timing out.  We could reimplement
>> that on 3.6.9, but before we do so we wanted to make sure there is
>> not a "more standard" way to solve the issue.
>>
>> Note that we do not want to set an "extra-long" timeout, as
>> failures do occur.  Rather we would want to be notified as soon as
>> reasonable of said failure.  Ideally we would set a fairly short
>> timeout - perhaps 5 seconds - and as long as the host continues to
>> receive FRAGments of the response we could bubble a keep alive up
>> the stack.
>>
>> Thoughts and advice are appreciated.
>>
>> Regards,
>>
>> Neal
>
> -- Bela Ban, JGroups lead (http://www.jgroups.org)
>
>
> ------------------------------------------------------------------------------
>
>
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and
> protocols are consuming the most bandwidth. Provides multi-vendor
> support for NetFlow, J-Flow, sFlow and other flows. Make informed
> decisions using capacity planning reports.
> http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
>
>
_______________________________________________
> javagroups-users mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>
> ------------------------------------------------------------------------------
>
>
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and
> protocols are consuming the most bandwidth. Provides multi-vendor
> support for NetFlow, J-Flow, sFlow and other flows. Make informed
> decisions using capacity planning reports.
> http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
>
>
_______________________________________________
> javagroups-users mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381