OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] I023 proposed solution(s)



Steve,
need to think more about this, but some initial comments:
- Pause/Resume, sent to the RMS or AcksTo EPR?  If RMS, how does the RMD know the RMS's EPR?  If AcksTo then what about the anonymous URI case?  Or would this be piggy-backed on a message already going to the RMS?  By using the term "notify" it seemed to imply the RMD would initiate the sending of this message instead of piggy-backing.
- Even with the 2nd proposal I think you might still need the first one since there may not be a way for the RMD to send the RMS a pause/resume and the RMD would still need a way to reject new incoming messages.

thanks,
-Doug



"Winkler, Steve" <steve.winkler@sap.com>

11/02/2005 05:21 PM

To
<ws-rx@lists.oasis-open.org>
cc
Subject
[ws-rx] I023 proposed solution(s)






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]