[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] I023 proposed solution(s)
"Yalcinalp, Umit"
<umit.yalcinalp@sap.com>
11/02/2005 09:07 PM |
|
"Yalcinalp, Umit"
<umit.yalcinalp@sap.com>
11/02/2005 08:56 PM |
|
"Winkler, Steve"
<steve.winkler@sap.com>
11/02/2005 05:21 PM |
|
Issue i023 [1] deals with the roboust recovery from low resource conditions, specifically on the RMD side. While I agree with the sentiment of the original proposal that the best way to solve such a problem is to allow for the RMD to notify the RMS of the situation and to have the RMS do The Right Thing, I also believe that the original proposal wasn't concrete enough for the TC to resolve and close the issue.
What follows are 2 concrete proposals that solve this problem using 2 different mechanisms. Both proposals were made based on the wsrm-1.1-spec-wd-05.pdf [2]. SAP favors the second proposal.
Proposal 1: ResourcesExhaustedFault
Summary: The basic idea behind this proposal is to notify the RMS via the faulting mechanism that the RMD currently can't process any messages due to resource constraints. This will indicate to the RMS that they should not immediately retry the message that breaks the camels back and, more importantly, that they should hold off for a while on sending new messages. How long the RMS should wait would be specified by an optional element in the fault detail indicating the RMD's best estimate as to when it would be safe for the RMS to try again. This would be similar to the optional Retry-After header in an HTTP 503 error message [3].
Concrete proposal: Add the following text after line 851.
4.9 Resources Exhausted
This fault is sent by the RM Destination to indicate that the received
message could not be processed due to resource constraints.
Properties:
[Code] Receiver
[Subcode] wsrm:ResourcesExhausted
[Reason] Sufficient resources to process the message were exhausted.
[Detail]
<wsrm:RetryAfter>…</wsrm:RetryAfter>
Proposal 2: Pause and Resume
Summary: This proposal is a more elegant solution than the one above. The advantage is that the RMD can prempt RMS attempts when it has exhausted its resources before they occur. The RMD, upon detecting a lack of resources, can choose to notify an/some/all (implementation specific) RMS(s) for which it currently has sequences that it cannot accept requests. Once resources have become available the RMD can then choose to notify the RMS that it can resume sending again.
Concrete proposal: Add the following text after line 591
3.5 Pausing A Sequence
There may be times when a RM Destination will find it beneficial to indicate
to the RM Source that it won't be able to process messages but doesn't
wish to terminate the sequence yet. For example, when the RM Destination
has exhausted its resources and is unable to process messages, but will
likely be able to process messages again in the future once resources have
been reclaimed.
The following exemplar defines the PauseSequence
syntax:
<wsrm:PauseSequence
wsrm:Identifier="xs:anyURI"/>
/wsrm:PauseSequence
This element is sent by an RM Destination to an RM Source to indicate that
the RM Source SHOULD NOT send any more messages, as they will most likely
be discarded.
/wsrm:PauseSequence@Identifier
This REQUIRED attribute contains an absolute URI conformant with RFC2396
that uniquely identifies the sequence.
/wsrm:PauseSequence/{any}
This is an extensibility mechanism to allow different (extensible) types
of information, based on a schema, to be passed.
/wsrm:PauseSequence@any
This is an extensibility mechanism to allow additional attributes, based
on schemas, to be added to the element.
3.6 Resuming a Sequence
After pausing a sequence it is necessary for the RM Destination to be able
to indicate to the RM Source that it can process messages again.
The following exemplar defines the ResumeSequence
syntax:
<wsrm:ResumeSequence
wsrm:Identifier="xs:anyURI"/>
/wsrm:ResumeSequence
This element is sent by an RM Destination to an RM Source to indicate that
the RM Source can resume sending messages.
/wsrm:ResumeSequence@Identifier
This REQUIRED attribute contains an absolute URI conformant with RFC2396
that uniquely identifies the sequence.
/wsrm:ResumeSequence/{any}
This is an extensibility mechanism to allow different (extensible) types
of information, based on a schema, to be passed.
/wsrm:ResumeSequence@any
This is an extensibility mechanism to allow additional attributes, based
on schemas, to be added to the element.
[1] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i023
[2] http://www.oasis-open.org/committees/download.php/15001/wsrm-1.1-spec-wd-05.pdf
[3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]