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] NEW ISSUE: Robust recovery from low-resource conditions


I agree.  I view ExponentialBackoff as something that is useful for
preventing excessive network traffic when an RMD is not reachable.  If
an RMD is reachable, but is currently becoming congested then there
should be a more explicit mechanism for temporarily throttling the RMS.
Actually, there are at least two ways of dealing with this - 

1) Have the RMD explicitly send a message to the RMS to suspend the
sending of messages until the RMD is ready to handle it again.  This
would work in conjunction with another message that tells the RMD to
start sending again.  

2) Have a policy setting on the RMD that states the RMD may discard
messages if it becomes overloaded.

I prefer option #1, but some of our customers over the years have also
requested option #2.
Dave

-----Original Message-----
From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
Sent: Wednesday, July 27, 2005 1:33 AM
To: wsrx
Subject: [ws-rx] NEW ISSUE: Robust recovery from low-resource conditions

Title:
  Robust recovery from low-resources conditions. 

Description: 
  In situations where the RMD is running low on resources, it may want
to provide hints to the RMS of its situation with the expectation that
the RMS pauses or slows down the (re)transmittal of messages and avoid
further straining of RMD resources until recovery. The current solution
of statically associating an ExponentialBackoff policy assertion may not
be timely and sufficient in all the cases and a more dynamic solution
for throttling the message flow may be needed.

Justification:
  In a low-resource situation, it is likely that the RMD would discard
any incoming messages and stop sending any Acks. Since the current
protocol design does not provide for the RMS to become cognizant of the
situation on the RMD side, RMS may simply keep on (re)transmitting
messages resulting into further resource utilization (network bandwidth,
processing power on both ends, etc.) and possibly making the situation
worse. It seems that a better option may be for the RMD to push back on
the RMS in the event of low-resource like situations and request the RMS
for pausing or slowing down any (re)transmissions.

Target:
  core

Proposal: 
  RM Protocol to support RMD pushing back on the RMS for slowing down or
stopping (re)transmission of messages.



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