[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg]
David,
First of all, the sending MSH does care about the interval. RetryInterval
was invented on the assumption that people would set it long enough so that
a transient condition that might have caused the message to be lost might
have a chance to correct itself before the retry.
We don't say anything about the time to the first retry - that's the
problem. The timeout that the MSH uses is an implementation matter and
isn't specified. RetryInterval might be longer or shorter than that
timeout. If RetryInterval is shorter than the timeout, the timeout
controls; if RetryInterval is longer, RetryInterval controls. However in
any case, we don't say what determines the time to the first retry.
Now that we understand that TimeToLive can be processed without using
RetryInterval, the initial time to retry is a non-issue for TimeToLive.
However, I had submitted an issue about the initial time to retry with
regard to calculating the time to decide that a delivery failure has
occurred. I believe that that issue is still open.
Regards,
Marty
*************************************************************************************
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
*************************************************************************************
David Fischer <david@drummondgroup.com> on 11/06/2001 12:54:51 PM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg]
I'll do whatever you guys tell me. The create time is in the MessageData.
I
have already struggled to find some understandable words and obviously I
have
failed. OTOH, much of this goes away if we change TimeToLive to an
Interval?
Your other concern. . . isn't the time to the first Retry still
RetryInterval?
I assume that the Sending MSH doesn't really care when the last Retry was
sent.
What it really cares about is a multiple of RetryInterval since the message
was
originally sent/created. The system would keep a RetryCount parameter and
then
send the next Retry when RetryCount * RetryInterval (SINCE create time) had
passed. OTOH, if a Retry were late due to some problem (system crash. . .)
then
this could mean multiple Retries at the same time. . .hmmm. I think this
is an
implementation detail and we don't have to solve it.
Your point about comparing TimeToLive to Receive time is correct. The
Receiving
MSH would have to add TimeToLive to the MessageData+Timestamp if we change
TimeToLive to an interval. We have to keep in mind that TimeToLive is
since
message creation, not since the last send.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, November 06, 2001 11:12 AM
To: David Fischer
Subject: RE: [ebxml-msg]
Since we are talking about TimeToLive, the comparing has to be done by the
MSH receiving the message. If the time of sending is in the message
header, your words are logically OK though not necessarily the most
understandable. If the time of sending is NOT in the message header, than
the time origin that I pointed out still exists.
However there is still the problem that I pointed out in the second
paragaph. Retry interval is not fully defined and there is nothing that
defines the time from when the message was sent until the first retry. If
one assumes that the message sender keeps track of the time of sending each
retry, then the only remaining question is whether the product is
RetriesXRetryInterval or (Retries-1)XRetryInterval.
Actually, the receiving MSH only has to compare the time of receiving a
message to its TimeToLive, thus avoiding the whole question of time
origins.
Regards,
Marty
********************************************************************************
*****
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
********************************************************************************
*****
David Fischer <david@drummondgroup.com> on 11/06/2001 11:20:05 AM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: Arvola Chan <arvola@tibco.com>, ebXML Msg
<ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg]
OK, please give me some words. IMO, when it says SINCE that means Add. If
you
don't agree, please tell me what to change this to.
Regards,
David.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, November 06, 2001 10:08 AM
To: David Fischer
Cc: Arvola Chan; ebXML Msg
Subject: Re: [ebxml-msg]
You are still comparing a date and time to an interval. You need to either
convert TimeToLive to an interval since some date-time origin or add a
date-time origin to Retriesx RetryInterval.
In addition, the comparison has another problem: The time from the initial
message to the first retry is undefined. The specs (MSG and CPA) do not
define the timeout used following sending the message and they do not say
whether RetryInterval applies to the time before the first retry or only to
the time between retries.
Regards,
Marty
********************************************************************************
*****
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
********************************************************************************
*****
David Fischer <david@drummondgroup.com> on 11/06/2001 10:26:33 AM
To: Arvola Chan <arvola@tibco.com>
cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject: [ebxml-msg]
Spec section 7.4.5:
TimeToLive MUST be greater than the product of Retries and RetryInterval
since
the message was originally sent.
Your comments:
You cannot directly compare a dateTime quantity against a duration
quantity.
This does not directly compare. TimeToLive is compared to (Retries *
RetryInterval) SINCE the message was originally sent.
I believe this is correct. How would you prefer to say this?
Regards,
David Fischer
Drummond Group.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC