[gridrpc-wg] Final call: GridRPC API for inclusion in SAGA 1.0

[Thilo Kielmann]

On Sun, Aug 13, 2006 at 01:30:06PM +0200, Andre Merzky wrote:

> > To my personal taste, I would prefer having the accessability check
> > in the constructor, enforced. However, this would contradict GFD.52
> > (see above). So we should have "all useful" exceptions (see below)
> > both for the constructor and the "call" method.
> 
> We should explicitely describe that this is different to
> other constructors then.

Yes, no problem.

> 
> IncorrectURL is reserved fo non-parsable URLs, and URLs
> which cannot be handled because the scheme is unsupported.

Hmm, it that would be clear from the SAGA spec, I wold not have chosen
"IncorrectURL" :-(


So, what about the following mapping:

GRPC_SERVER_NOT_FOUND    DoesNotExist
GRPC_FUNCTION_NOT_FOUND  DoesNotExist
GRPC_RPC_REFUSED         AuthorizationFailed     looks like the closest match
GRPC_OTHER_ERROR_CODE    NoSuccess               default

GRPC_NO_ERROR and GRPC_NOT_INITIALIZED are not applicable.

> > We have to rely on GFD.52, this means here on grpc_cancel().
> > grpc_cancel is meant to cancel an asynchronous rpc call.
> > The description in GFD.52 does NOT mention any remote resource de-allocation.
> > This means, prescribing in SAGA some form of remote resource de-allocation
> > would deviate from GridRPC and would likely not be implementable.
> > 
> > This means, all we can do is cancel the SAGA task (possibly with timeout -1).
> > And, if I understand SAGA's task cancel method correctly, it is supposed
> > (or at least allowed) to "clean up resources", which I would translate to
> > calling grpc_cancel underneath.
> 
> Hmm, I am somewhat confused now, as I thought (as said
> earlier) that the timeout on cancel was an GridRPC
> requirement.  Well, nevermind then.  Should we consider
> removing cancel/close timeouts from the spec altogether?

Unless I have overlooked something in GFD.52 (GridRPC), then the 'enforced'
clean up can not be implemented there.

Are there any other use cases for cancel/close timeouts??
I personally don't see much good in them: either the cancel manages to clean
up, or it doesn't even after the timeout. This would onle be interesting if
the same app would request more of the same remote resources. But still,
either the remote resource manages to clean up, or sooner-or-later it will
overflow...


Thilo
-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/