Re: [wsrm] What about this tradeoff solution for the persistence issue?

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

Paolo Romano wrote:

> I don't understand why we should specify
> the crash tolerance level in a message.
>
> My understanding is that WS-RM relys on message parsistance to achieve
> the three functionalities (i.e., guaranteed delivery, duplicate elimination, and
message
> ordering).  If it is true, the specification "mustpersist=false" does not make
sense
> since, without message persistance, WS-RM does not provide any reliability.

As Sunil pointed out we exstensively discussed about this point in F2F, but I do
not think we reached an agreement. In fact, also when the protocol state (i.e.

 We did had consensus on "message persistence" (aka "persist a
 message"). I cut-and-pasted Tom's meeting minutes. See the
 ones in Red color. We didn't close it bacause we didn't have quorum.
 

 We did not agree on "Persistence Storage" which we took it out.

-----------------------------------------------------------------------------------------
In particular, in the existing spec we need to change:

      The receiver is also REQUIRED to keep the received message in persistent storage to pass the message
      to the application layer reliably in the event a system failure or server down time occurs. Both sender and
      receiver MUST behave as if there was no system failure or system down after recovery. For this reason, both
      sender and receiver MUST use a persistent storage mechanism, e.g, HDD or equivalent nonvolatile storage
      .

To:

      The receiver MUST persist out of order messages to support ordered delivery.

 

      The receiver MUST persist the messageID to support duplicate elimination.

 

Also change the title of 2.2.3 to “Message Persistence”.

 

There was unanimous agreement to accepting the above resolution as a pending resolution for Rel 17.  We can
move from pending to accepted at a future meeting when we are quorate.
-------------------------------------------------------------------------------
 

 
the information concerning the exchanged messages) is stored in a non persistent
way, some additional reliability guarantees are still provided by ws-rm, when
compared to classic TCP based protocols: that is, applications relying on ws-rm
are guaranteed that their messages will be delivered in face of communication
channel failures. This use case is common in wireless environments, and was
originally presented by Nokia members.

Even when you choose to persist, in fact, ws-rm still can fail to provide
reliable messaging, simply because, whatever redundancy you can imagine, you
still cannot exclude a priori the event of persistent storage failures.
In other words, since ws-rm is not a stateless protocol, it can not be crash
tolerant in case of persistance storage failures.

If I look at WS-RM from this point of view (i.e. if I consider WS-RM as a
protocol which, also when persisting, can provide a "limited" level of fault
tolerance) and since some members agree that WS-RM could be used in environments
with high probability of communication failures, but very simple hardware (i.e.
no persistance), I do not see any harm in formalizing within the specification
an optional behavior for rm-processors which allows them, on demand, not to
persist messages, as long as the ws-rm users are aware of it, and of its
implications.

Reliability IS NOT crash tolerance. Reliability is the ability of a process to
carry on succesfully its task, despite the event of failures. It is up to us
deciding what the process task is, and what failures will be tolerated.
I believe we can not find an agreement because we do not even agree on this.

> (Of cource, the level of persistance reliability may differ from main memory to
> hard disks.)
>
> If "mustpersist" is meant to specify the level of persistance reliability,
> the boolean is too simple -- the level of persistance reliability is not
> all-or-nothing.
>
> Moreover, even if we can specify crash torelance in a message,
> we still need some agreement before establishing reliable messaging
> (such as retry interval, maximum time-to-live, ...).
>

> My opinion is that we should use a (yet-to-come) standard for (service level /
policy)
> (description / agreement / negotioation), which is orthogonal to WS-RM.
> Since we can't expect such a standard within our timeframe, all we can do
> is to list up what sender/receiver should agree on (how to agree should
> be out-of-scope), such as message persistance reliability, retry interval,...

I agree with this point, we do need such a protocol. While we are waiting for
it, we should point out what are the parameters/capabilities to be negotiated.
Anyway, while we are waiting for a standardized solution to our problem, we may
still allow some simple configuration options (e.g. <mustpersist>) to be decided
at run-time, on sender's demand. Also when the negotiation will be performed in
a standard way, we will still need a mechanism to report errors when one of the
end-points does not respect some agreed parameters.

>
> ---
> Junichi Tatemura
>
> ----- Original Message -----
> From: "Paolo Romano" <Paolo.Romano@dis.uniroma1.it>
> To: <wsrm@lists.oasis-open.org>
> Sent: Monday, June 09, 2003 5:15 PM
> Subject: [wsrm] What about this tradeoff solution for the persistence issue?
>
>
> >
> > Persistent storage usage is the default mode.
> > An apposite <mustpersist="false"/> tag is used when applications do not require
> > a crash tolerance reliability level, but only tolerance to transport layer
> > failures.
> > In case a device which is not able to persist a message receives a message
> > without the <mustpersist="false"> element, a fault message MUST be sent in
> > response, indicating the inability of the receiver to assure required
> > reliability guarantees.
> > In that case it is up to the application layer to decide whether to send again
> > the same message requiring a lower quality of service.
> >
> > It seems to me to be very simple, needs only to define two reliability levels:
> >              (non-destructive) crash tolerance
> >              transport layer (communication channel) failure tollerance
> >
> > By default <mustpersist="true"> even if not specified since it is the most
> > common use case.
> > No need for negotiation, reliability level is estabilished by the sender, and
> > possibly refused by the receiver.
> > ..
> > And cell phones users (and surely mobile developers too!) will be happy not
> > being bothered anymore by disconnections when driving into tunnels!
> >
> > Comments?
> >
> >
> > --
> > Paolo Romano
> >
> >
> >
> > You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
> >
> >

--
Paolo Romano

You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php