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