[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
Doug, It seems to me that once the MSH has deposited a message in its persistent store, it has fulfilled its obligation to deliver the message to the application. If it then goes ahead and deletes the message, it may be pulling the rug out from under the application. Unless the MSG team wants to prescribe a transactional protocol between the MSH, persistent store, and application, the MSH must keep its paws off the message once it has deposited it in the persistent store. 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 ************************************************************************************* Doug Bunting <dougb62@yahoo.com> on 12/11/2001 12:47:14 PM To: ebxml-msg@lists.oasis-open.org cc: 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC