You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by Zsolt Kúti <la...@gmail.com> on 2010/08/29 21:21:56 UTC

retry on error, idempotency

Hi,

I vaguely remember of Jini 1.x specification contained a chapter about
evaluating possible types of exceptions (network errors). It
categorized them so that it can be used to base a retry policy on. I am
not able to find them it now, though. 2.x does not contain it any more.
Can tell me somebody what was the reason to have left it out? 

Searching for information for the subject found a post of Gregg
Wonderly stating:

> retried. In the JERI stack available in Jini 2.0, there are some
> pretty good exception layering things that happen that help you
> understand whether the error 
> came from the server side or the transport layer.

Is there a document available to read about this topic more? Is there
some best practice or collective wisdom one can follow? I would like to
learn about how others tackle these problems.

Thanks!
Zsolt

Re: retry on error, idempotency

Posted by Zsolt Kúti <la...@gmail.com>.
On Tue, 31 Aug 2010 10:50:18 -0400
"Christopher Dolan" <ch...@avid.com> wrote:

> Zsolt,
> 
> Take a look at
> com.sun.jini.constants.ThrowableConstants.retryable(Throwable).  It
> does a decent job of categorization.  But I've been meaning to file a
> defect that it does not explicitly handle java.rmi.ConnectException...

 
Hi Chris,

A quick look at the visible com.sun.jini* packages didn't reveal this
class, but I will find it.

Thanks for the info, just as to Tim for the explanation!

Zsolt

RE: retry on error, idempotency

Posted by Christopher Dolan <ch...@avid.com>.
Zsolt,

Take a look at com.sun.jini.constants.ThrowableConstants.retryable(Throwable).  It does a decent job of categorization.  But I've been meaning to file a defect that it does not explicitly handle java.rmi.ConnectException...

Chris


-----Original Message-----
From: Zsolt Kúti [mailto:la.tinca@gmail.com] 
Sent: Sunday, August 29, 2010 2:22 PM
To: river-user@incubator.apache.org
Subject: retry on error, idempotency

Hi,

I vaguely remember of Jini 1.x specification contained a chapter about
evaluating possible types of exceptions (network errors). It
categorized them so that it can be used to base a retry policy on. I am
not able to find them it now, though. 2.x does not contain it any more.
Can tell me somebody what was the reason to have left it out? 

Searching for information for the subject found a post of Gregg
Wonderly stating:

> retried. In the JERI stack available in Jini 2.0, there are some
> pretty good exception layering things that happen that help you
> understand whether the error 
> came from the server side or the transport layer.

Is there a document available to read about this topic more? Is there
some best practice or collective wisdom one can follow? I would like to
learn about how others tackle these problems.

Thanks!
Zsolt

Re: retry on error, idempotency

Posted by Tim Blackman <ti...@gmail.com>.
My recollection is that we decided that this behavior was an implementation detail and should not be part of the spec.  The information was moved to the implementation as others have pointed out.

- Tim

On Aug 29, 2010, at 3:21 PM, Zsolt Kúti <la...@gmail.com> wrote:

> Hi,
> 
> I vaguely remember of Jini 1.x specification contained a chapter about
> evaluating possible types of exceptions (network errors). It
> categorized them so that it can be used to base a retry policy on. I am
> not able to find them it now, though. 2.x does not contain it any more.
> Can tell me somebody what was the reason to have left it out? 
> 
> Searching for information for the subject found a post of Gregg
> Wonderly stating:
> 
>> retried. In the JERI stack available in Jini 2.0, there are some
>> pretty good exception layering things that happen that help you
>> understand whether the error 
>> came from the server side or the transport layer.
> 
> Is there a document available to read about this topic more? Is there
> some best practice or collective wisdom one can follow? I would like to
> learn about how others tackle these problems.
> 
> Thanks!
> Zsolt