RE: [wsrm] Rel 33: some thoughts and proposal...

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: RE: [wsrm] Rel 33: some thoughts and proposal...

Peter and Sunil:

my $0.02...

>
> So I understood - but one of my points (perhaps obscured) was that the
> use of the phrase in defining the ordering semantics implies only an
> ordering of (delivery) events with respect to each other, but does not
> of itself imply when those deliveries occur relative to the
> communication from the sender. The ordering requirement correctly allows
> that the RMP receipt of the sequence and the delivery occur at
> completely separate times.

 Sure. My point was we are using the same phrase with the same semantics
 in Message Ordering case also. We currently say that in an Ordered sequence
 case a message is "made available to the user/application" if all the previous
 messages in that sequence are received and Acked.

<JD> "...are received and Acked", you mean the Receiver has sent Acks for
all of these previously received messages (meaning therefore it has passed them to
the "app"). To be precise, the Ack is sent *after* the message has been made available
to the app. I concur with this ack semantics as I said previously.
Delivery to app can be defined abstractly as the magic moment when
the message is out of RMP responsibility (e.g. in a queue available to business app)
Same definition as for Ordering.

 
--------------------------

 And hence I'm re-iterating that this particular issue (usage of words) is not
 specifically tied to Expiry time or REL 50. That doesn't mean that I'm not
 suggesting that it shouldn't be changed.

>
>
> I don't see how the true sentences in Tom's message link up. For any
> message, the sender
> can flush the message on receipt of the ack - the only requirement on

 Not entirely true. The way REL 52 and 57 are coined, we still need
 to keep the message metadata information (if not the whole message)
 for Acked messages as we are using individual MaxIdleTimes/MsgExpiryTimes
 (max of the individual ones) to compute the Group termination/removal
 conditions. Note that we need this both on the Sender and Receiver side.

<JD> Overall agree but would refine:
"flush the message" does not indeed (in general) flush its ID, which
maybe  needed for duplicate checks, and the storage of which is indeed linked
to ExpiryTime (simply for the sake of better memory management).
- Sender side: an acked message , I believe, can be entirely flushed along with its ID.
- Receiver side: a delivered message body can be flushed, but not its ID yet,
if dup check required. How to know when to get rid of this ID?
For groups, we use expiration and timeout criteria described in proposed Rel52.
(note we don't need to memorize message-specific values, only some max value for group)
For singletons, we propose to use also ExpiryTime, and therefore need to store
it per message, along with ID. We flush IDs when ExpiryTime expires.

--------------------------

> the receiver is that
> it doesn't send the ack until either it has delivered the message or has
> it safe such

 sure. I guess we are all speaking in one voice then. The new proposal
 is more aligned to what you are suggesting here. In the old case,
 a msg. was Acked even when it not ready to be delivered.

<JD> agree.

--------------------------

> A complication with "ack when made available" means that the sender has
> got to guess
> whether the non-arrival of an ack means that the message hasn't been
> safely received
> (and so should be resent) or it is a later message that hasn't been
> received.

 Well this is an Issue which is easily solved by keeping tracking of
 Acks for all previously sent messages in that sequence, which he
 has ought to do it anyway.

<JD> I think that becomes an implementation issue:
In order to prevent useless retries for messages that have been received
but are on hold at Receiver as unordered, A Sender can limit its resending to
teh first non-acknowledged message.
- If that one does never get acked, no point resending the next messages anyway:
the out-of-order sequence should be considered as lost, from Sender viewpoint.
- If that one gets acked, then all acks for out-of-order ones are also sent along.
If one is missing again, then resending should apply.
Note that this refinement is about "resending", not "sending" subsequent messages.
True there may be subsequent "holes" in an out-of-order sequence, that may not
have been filled as early as they could, due to resending procrastination.

--------------------------

>
>
> queue.  But when it was talking about ordering, and probably about
> expiry, "deliver to the user"
> meant taking stuff off the queue.
>
> I don't believe you can use the same phrase for the ordering requirement
> and the ack point
>

 So what would be your proposal & suggestion  then?

<JD> I do not see how these two cases of delivery are different...
"delivery to app" is an abstract operation that could mean either putting the
message in a queue, doing a callback to app, storing message in DB and
waiting for the app to pick it up, forwarding, etc.
As long as we can identify the point during message processing
where an RMP is relaxed from the RM contract, that is release to me.
The order in time in which these releases are made, is the delivery "Order".