romradz@man.poznan.pl wrote:
On Tue, 11 May 2010, Jason Zurawski wrote:
Hi Piotr;
On 5/11/10 10:26 AM, Piotr Pikusa wrote:
Hi Jason!
Jason Zurawski wrote:
RRDMA:
- Are these only for the perfSONAR layer, or do these cover other exceptions that may come up from tomcat/axis/exist?
Those result codes, which were sent present only perfSONAR layer. If some exception comes from eXist it is covered by perfSONAR code. However presented list doesn't cover tomcat and axis errors if they appear besides the perfSONAR code and cannot be catch by it.
- I only see one that uses the 'error.' format: "error.common.storage.xmldb.open". Are these all 'error's or are some of them 'success' too?
Success is only responded by echo request and has a url format. When other requests are completed successfully just a proper message with requested data is sent without any success code and I suppose it is compatible with nmc-wg standard for MA services.
- There is a lot of reuse of 'query_exception'. In the new model would that still be the case or would there be more specific new error codes used?
Does not it come out from new results code - the clienterror and servererror part in the tree?
I am not sure what you mean by 'clienterror' or 'servererror' in this case because we still don't have a complete mapping of how you think all of the old result codes will translate into new. I would expect that this is the next step (we can talk about this on the thursday call).
Maybe I wasn't clear enough on my question. From the examples that I am reading for 'query_exception' it covers several cases:
- Structure of the message may be wrong, e.g. "no data trigger", "no subject element in metadata id=[...]" - Content in XML is unexpected, e.g. "eventType [...] in metadata id= [...] is not supported" - Content is 'wrong' (not sure how to interpret this, maybe its unexpected or maybe it is just incorrect vs. what is stored in the backend?), e.g. "wrong ipAddress", "wrong hostName"
I would call these things different error messages since they cover slightly different cases.
My original question was do you or Roman envision these translating directly to a single result code in the new model, or would these be encoded as different codes for different situations.
Moving to the new model will be difficult because meanings of errors may overlap. Let's take 3 examples mentioned above. We can assign them to
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/not_acceptable
but this one:
clienterror/bed_request, clienterror/event_type_not_allowed, clienterror/bed_request
also provides true info about error situations.
I'm thinking that maybe we should say that the first part of result code URL is standard but the second part is not controled by NMC.
Standard parts of result codes: http://perfsonar.net/status/informational/ http://perfsonar.net/status/successful/ http://perfsonar.net/status/redirection/ http://perfsonar.net/status/clienterror/ http://perfsonar.net/status/servererror/
Example of complete result code:
http://perfsonar.net/status/informational/something_which_is_proposed_by_ser...
Cheers, Roman
But then I suppose we must assume that developer will write a code which is understandable by all others, especially client maintainers or client users. I think that this is strong assumption and can provide to the situation that from two different services the same two errors will have very different result code and a client may then think that those two errors are not the same. Cannot we just follow a standard part of results codes presented by you Roman and then bring together non-standard and include them into NMC? It requires developers` agreement on result codes related to the same errors.