[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
Actually, what I said below is not quite true. The exception is, of course, message ordering where depositing an out-of-order message is not delivery to the application. So, delivery to the application is depositing the message in the persistent store and making the application aware that the message is there. That's it. Once the MSH has signalled that a message is available to the applicaiton, timeToLive is no longer a factor and in any case, the MSH cannot tell when the application finally takes notice of the message. 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 ************************************************************************************* ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 12/11/2001 07:00 PM --------------------------- Martin W Sachs/Watson/IBM@IBMUS on 12/11/2001 06:31:16 PM To: "Burdett, David" <david.burdett@commerceone.com> cc: ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement It seems to me that we have all at least implicitly agreed that depositing a message in the persistent store constitutes delivery to the application (not unlike the postal service delivering a letter to a post office box). That's the event that should be governed by time to live. See my previous posting. 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 ************************************************************************************* "Burdett, David" <david.burdett@commerceone.com> on 12/11/2001 06:17:24 PM To: ebxml-msg@lists.oasis-open.org cc: Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement I agree with Doug The original intent behind TimeToLive is that it should indicate the time by which the message should be delivered to the application. Consider the use case where the To Party MSH stores messages which, at the end of the day, they forward in batch to an application. If we make the semantics mean that the message will be processed, then, as Doug says, you can't send back the acknowledgement until the message has been passed to the app. I think it is completely valid to: 1. Send a delivery receipt to indicate that the message has been received by the To Party MSH 2. Later send an error message to indicate the the To Party MSH could not deliver the message to the App before TimeToLive expired. A delivery receipt is just that a receipt for **delivery** it is not an indication that the message has been processed. That can only be provided by the application. David -----Original Message----- From: Doug Bunting [mailto:dougb62@yahoo.com] Sent: Tuesday, December 11, 2001 11:15 AM To: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement Hmmm, I remember no such decision and think it isn't a particularly useful way to define TTL. The sender couldn't care less when a receiver MSH gets a message, they care only about the application at the To Party. As you comment, the underlying issue is (again) acknowledgments and their semantics. I completely agree an acknowledgment message MUST be the last message an MSH could initiate with reference to a received message. (Yes, applications are free to respond to any message whenever they please -- I'm talking only about MSH signals.) In particular, error messages (such as "TTL expired") MUST NOT be sent after an acknowledgment message has been sent. According to my understanding of TTL, this would mean an MSH shouldn't send an acknowledgment until it has informed the application. whatever, doug ----- Original Message ----- From: "David Fischer" <david@drummondgroup.com> To: "Doug Bunting" <dougb62@yahoo.com>; <ebxml-msg@lists.oasis-open.org> Sent: Tuesday, 11 December 2001 10:43 Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement No, Arvola is right. We decided a message could be delivered from the MSH to the Application AFTER TTL. TTL is the time it must be delivered to the To Party MSH. If this is not true, then the receiver could just hold any message he didn't like until after TTL and then discard, regardless of any Acknowledgments. The sending of an Acknowledgment constitutes a commitment by the MSH to deliver to the Application (what the Application does is undefined). Regards, David. -----Original Message----- From: Doug Bunting [mailto:dougb62@yahoo.com] Sent: Tuesday, December 11, 2001 11:47 AM To: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement Arvola, I disagree; the wording is fine as it is. If the example you've described occurs, the To Party MSH is not operating correctly. The TimeToLive value is intended to be the time by which (end-to-end, application-to-application, whatever you want to call it) delivery must be complete. That may mean the To Party MSH discards a message after it has been persisted in some storage (but not delivered to its application). Going further, your previous recommendation made sense though the example was also slightly incorrect. In that example, a message found in persistent store after crash recovery might (MUST) be discarded due to an expired TimeToLive value. Of course, we can't say anything about how long it might take an application to process a message... thanx, doug ----- Original Message ----- From: "Arvola Chan" <arvola@tibco.com> To: "David Fischer" <david@drummondgroup.com>; <ebxml-msg@lists.oasis-open.org> Sent: Monday, 10 December 2001 17:44 Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement David: The first paragraph in section 3.1.6.4 in the version 1.091 draft now reads: "If the TimeToLive element is present, it MUST be used to indicate the time, expressed in UTC, by which a message should be delivered to the To Party. It must conform to an XML Schema dateTime." I think the phrase "To Party" should be replaced with "To Party MSH". The To Party MSH will check the incoming message to determine if its TimeToLive has expired. It may have to make a persistent copy of the message before attempting to deliver it to the To Party. A crash may happen after the message has been persisted but prior to its being delivered to the To Party. Therefore, it is entirely possible that the To Party only receives the message after TimeToLive has passed. Regards, -Arvola -----Original Message----- From: David Fischer <david@drummondgroup.com> To: Arvola Chan <arvola@tibco.com>; ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> Date: Sunday, December 09, 2001 8:47 AM Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement >Yes, I will remove "and processed by". > >David. > >-----Original Message----- >From: Arvola Chan [mailto:arvola@tibco.com] >Sent: Friday, December 07, 2001 5:49 PM >To: ebxml-msg@lists.oasis-open.org >Subject: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement > >This first paragraph in this section states: > >"The TimeToLive element indicates the time by which a message should be >delivered to and processed by the To Party." > >I don't think the above statement is correct. The message must be received >by the To Party MSH prior to its TimeToLive. Once it has been persisted by >the To Party MSH, it can be delivered to the To Party. If a crash occurs >after the message has been persisted but before it can be handed over to the >To Party, it is possible that it may be processed by the To Party (on crash >recovery) even after TimeToLive has expired. > >-Arvola > > > > >---------------------------------------------------------------- >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> ---------------------------------------------------------------- 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> ---------------------------------------------------------------- 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