[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i023 proposed resolution
Hi Chris, Some claification questions/comments inline below ... > -----Original Message----- > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] > Sent: Wednesday, Oct 12, 2005 10:03 AM > To: ws-rx@lists.oasis-open.org > Subject: [ws-rx] i023 proposed resolution > > > Regarding issue i023 [1], I believe that definition of > protocol mechanisms related to the proposed > resolution: > > "RM Protocol to support RMD pushing back on the RMS for > slowing down or > stopping (re)transmission of messages." > > When the WS-RM spec was initially published, there was an > accompanying white paper [2] > that made mention of a potential spec called WS-Transmission: > > "WS-TransmissionControl - A set of constructs for controlling > the exchange of > messages between services to improve reliability by > preventing message loss due to > service unavailability, overloading queues and other causes." > > Personally, I think that the issue of flow-control is > orthogonal to RM and really should be > addressed as a separate concern. What is the purpose of the RetransmissionInternval and ExponentialBackoff assertions? Are these not configurations for flow-control to be used by the RMS when the RMD does not send Acks in a timely manner? Should I interpret that the original spec authors recognized the problem of overloaded RMD situations but they preferred a static policy based solution as opposed to a dynamic flow control solution that may introduce additional protocol elements? Also, the above referenced pair of assertions seem to apply on a per message basis. These assertions do not say anything about whether an RMS should transmit new messages in a Sequence that already has many existing unacknowledged messages. What is the point in sending new messages on a Sequence when the RMS has resorted to ExponentialBackoff for one or more existing messages in the same Sequence. It seems that a Sequence (or even higher) level mechanism is needed to notify the RMS that the RMD is having issues with accepting messages. One solution may be to introduce pause/resume. Before dismissing this solution on the grounds of "this changes the protocol", we should do a cost-benefit analysis. In case the TC concludes that pause/resume is undesirable, then another option may to define a specific OverloadedFault upon receiving which the RMS should - a> stop sending new messages in that Sequence until b> ExponentialBackOff is triggered and all the pending messages are cleared. > > Proposal: > > I would propose that we close this issue with no action. I think we should wait a little bit further since the TC has not yet been presented with the other options, specifically in the light of the current RetranmsissionInterval/ExponentialBackoff based solution. I am fine with either myself or someone from SAP owning and driving this issue (not for tomorrow's call though). Thanks, Sanjay > > [1] > http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.ph > p/14682/Re#i023 > [2] > ftp://www6.software.ibm.com/software/developer/library/ws-rm-e > xec-summary.pdf > > Cheers, > > Christopher Ferris > STSM, Emerging e-business Industry Architecture > email: chrisfer@us.ibm.com > blog: http://webpages.charter.net/chrisfer/blog.html > phone: +1 508 377 9295 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]