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

[Andre Merzky]

Quoting [Thilo Kielmann] (Aug 13 2006):
> > 
> > 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" :-(

from the spec:

  A method was invoked with an URL argument which could
  not be handled. The error specifically indicates that an
  implementation can not handle the specified protocol, or
  that access the specified entity via the given protocol is
  impossible. The exception MUST NOT be used to indicate any
  other error condition. See also notes to 'The URL Problem'
  in the introducton.

Can you think of a wording which makes this more explicit?
Is it confusing to refer to end point access here?


> 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.

Yes, sounds sensible to me.


> > > 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...

Apart from handling remote resources, you may want to
release locks and handles before the object goes out of
scope.  That is in particular important for Java ;-), as you
have no control over _when_ the garbage collection will
destroy your object.  So, a close()/cancel() is useful in
these cases.  However, I am not sure if we do have an
explicit use case for the timeout on these calls then.

Cheers, Andre..


> Thilo
-- 
"So much time, so little to do..."  -- Garfield