+1
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
Dan Weinreb <dlw@exceloncorp.com> on 12/12/2001 09:02:44 AM
Please respond to Dan Weinreb <dlw@exceloncorp.com>
To: david.burdett@commerceone.com
cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
Date: Tue, 11 Dec 2001 15:17:24 -0800
From: "Burdett, David" <david.burdett@commerceone.com>
The original intent behind TimeToLive is that it should indicate the
time by
which the message should be delivered to the application.
That is not my understanding of TimeToLive. That's much more like what
I thought PersistDuration is for.
As I understand it, TimeToLive is part of the duplicate elimination
mechanism. When a message is first created, at the From MSH assigns
the message its unique message ID, the From MSH also assigns the
message a TimeToLive, which might more appropriately be called the
message's InstantOfDoom.
The message is then injected into the "network". The network can
delay a message for any amount of time, and it can create duplicates
that are delivered each after its own delay time.
The meaning of the TimeToLive field of a message is that if a message
is still "in the network" after TimeToLive, the message MUST be
ignored and treated as if it were not there. Once a message is out of
the network, TimeToLive is no longer relevant.
When the To MSH receives a message from the network, it examines the
TimeToLive field, and if the value of the field is in the past, the To
MSH ignores the message.
If the To MSH doesn't ignore the message, it will presumably store
the message in persistent storage, but that has nothing to do with the
question of what TimeToLive means! The queue of messages destined for
the application is not relevant. The time at which the application
reads a message from that queue is not relevant.
The reason for all this is so that when duplicate elimination is being
used, the To MSH can know when it can stop remembering (persistently)
the message ID of a message that it has received. The answer is that
any time after that message's TimeToLive instant has passed, the To
MSH is free to forget the messageId of the message. Any further
duplicates of the message that arrive will be eliminated by virtue of
the TimeToLive, without any help from the persistent set of
messageId's.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>