RE: Is (sender-side) persistent storage needed for Reliable Messaging ??

  <Ricky>
  Does it mean the value of "persistent storage" is so that RM can promise
the App-A earlier after it persist the message, and release App-A to do
something else ?

  In other words, does it mean if App-A is willing to wait until the message
is actually delivered (RM-A get an ACK from RM-B), then there is no need for
persistent storage.
  </Ricky>

  Yes and yes.

  If you use a low latency protocol such as UDP then you could wait to know
if the message got delivered. If you use a high latency protocol, or want a
queue to take care of delivery at its own pace, then you would expect the
message to be stored and go about your business.

   <Ricky>
  But it is possible RM-A fail to deliver the message after retry and decide
to give up.  Does the application still not care ??
  </Ricky>

  There is no benefit for the app to tell if the message was recieved or the
RM gave up. I highlighted the reasons before, but just to recap.
  If the app sends a message than it agrees that the receiver can start
processing it whether or not it knows about that fact. So, if you do not
hear back from the receiver that does not mean that the message was not
received.

  If the app depends on the message being received and processed it must
anticipate the possibility that the message will be received, acked, but not
processed. So it needs logic to deal with that possibility.

  The logic for dealing with that possibility is the same regardless of
whether or not you received the ack, so it's just easier to develop an
application that does not ask the RM for failure notification but has one
logic for dealing with both kinds of scenarios.

  arkin