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