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

[Andre Merzky]

Hi, 

Quoting [Thilo Kielmann] (Aug 13 2006):
> 
> >   - The RPC spec is silent about 'when' the connection to
> >     the remote server is made, on creation of the handle, or
> >     on call().  We decided in other parts of the spec that,
> >     for example, the constructor opens a file, or remote
> >     connection.  I propose to prescribe the same for RPC.
> >     Does that make sense?  Do we need to loosen the
> >     semantics elsewhere in the spec? (IMHO not).
> 
> 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.


> > >     - constructor
> > >       Purpose: inits a remote function handle
> > >       Format:  CONSTRUCTOR  (in  session session, 
> > >                              in  string  funcname)
> > >       Inputs:  session:      saga session to use
> > >                funcname:     name of remote method to
> > >                              initialize
> > >       Outputs: -
> 
> I suggest the following mappings of GridRPC errors to SAGA exceptions:
> 
> GRPC_SERVER_NOT_FOUND    IncorrectURL
> GRPC_FUNCTION_NOT_FOUND  IncorrectURL
> 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.

IncorrectURL is reserved fo non-parsable URLs, and URLs
which cannot be handled because the scheme is unsupported.
An invalid URL in the sense that the server does not exist,
or points to a non-existing function handle etc. should
cause a BadParameter exception, or a DoesNotExist exception
(latter if it fails because the described endpoint does,
well, not exist).


> >   - should we add a 'cancel(in float timeout)'?  Explicit
> >     resource dealloction was an issue in our discussion at
> >     GGF, and we agreed on cancel - is that not needed
> >     anymore?
> 
> I gave it a thorough (I hope ;-) read and came to the following conclusion:
> 
> 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?

Agree with the other points you made.

Cheers, Andre.


> Summary: no explicit cancel method for SAGA's RPC package
> 
> 
> Thilo
-- 
"So much time, so little to do..."  -- Garfield