6472 2009-01-26 13:58:32 +0000 Eventing-EventSourceUnableToProcess: Distinguish temporary v permanent failure 2009-05-26 13:48:54 +0000 1 1 1 Unclassified WS-Resource Access Eventing FPWD PC Windows XP CLOSED REMIND P2 normal --- 1 katy_warr katy_warr bob dug public-ws-resource-access-notifications oldest_to_newest 23244 0 katy_warr 2009-01-26 13:58:32 +0000 Eventing spec section 5.6 EventSourceEnableToProcess Consider allowing subscribing clients to be able to distinguish between a temporary fault (such as event source has too many subscribers) and a permanent fault (such as endpoint is no longer an event source). This would allow clients to retry only in cases of temporary failure. We could do this via differing subcodes or different detail. 23576 1 bob 2009-02-09 00:53:01 +0000 Proposals from http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0062.html Suggestion 1: Introduction of "retryAfter" ------------------------------------------ Introduce an optional retryAfter element (in homage to ws-addressing soap ;o) ) in the detail of EventSourceUnableToProcess and UnableToRenew. Absence of the retryAfter element would mean: don't bother to retry. This suggestion has the advantage that it reuses an existing pattern from another spec. It also is more useful to the client as it gives some indication as to when it might be worth retrying. This may be useful (for example) if an event source had too many subscribers and was therefore being taken off-line for a while. Here's an example fault using this suggestion: <S:Fault> <S:Code> <S:Value> S:Sender </S:Value> <S:Subcode> <S:Value>wse:EventSourceUnableToProcess</S:Value> </S:Subcode> </S:Code> <S:Reason> <S:Text xml:lang="en">The event source has too many subscribers</S:Text> </S:Reason> <S:Detail> <wse:RetryAfter>1000</wse:RetryAfter> </S:Detail> </S:Fault> Required Changes to the specification: 1) Add to Section 5:Faults Fault detail elements: The following element is used to convey additional information in the faults. Retry After The following describes the <wse:RetryAfter> element: /wse:RetryAfter This element (whose content is of type xs:unsignedLong) is a suggested minimum duration in milliseconds to wait before retransmitting the message. Omission of this element indicates that a retry is never likely to succeed. /wse:RetryAfter/@{any} Optional extensibility attributes that do not affect processing. 2) Add "<wsa:RetryAfter> Optional" to the [Detail] section of 5.6 EventSourceUnableToProcess and 5.7 UnableToRenew Suggestion 2: PermanentFailure Subsubcode ----------------------------------------- A simpler, but less powerful solution, would be to enable an event source to set a subsubcode in the fault to indicate that the error was permanent. Absence of this subsubcode would indicate to clients that it may be worth retrying the request. Here's an example fault using this suggestion: <S:Fault> <S:Code> <S:Value> S:Sender </S:Value> <S:Subcode> <S:Value>wse:EventSourceUnableToProcess</S:Value> <S:Subcode>wse:PermanentFailure</S:Subcode> </S:Subcode> </S:Code> <S:Reason> <S:Text xml:lang="en">The endpoint is no longer acting as an event source</S:Text> </S:Reason> </S:Fault> Required Changes to the specification: 1) Section 5 Faults. In the table following "The definitions of faults use the following properties:" change the text in the subcode row from "The fault subcode" to "The fault subcode (with optional nested subcode)". 2)Change [subcode] row of section of 5.6 EventSourceUnableToProcess and 5.7 UnableToRenew to: wse:EventSourceUnableToProcess The EventSourceUnableToProcess subcode can be further narrowed in scope by use of an optional nested subcode <wse:PermanentFailure>. Inclusion of this nested subcode indicates that a retry is never likely to succeed. 23871 2 bob 2009-02-23 15:15:44 +0000 Resolved 2009-02-17 with suggestion 1 in comment#1