Re: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

[Martin W Sachs <mwsachs@us.ibm.com>]

Can't we expect that the IP hop count will take care of messages lurking in
the network?

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
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 09/21/2001 06:00:49 AM

Please respond to Dan Weinreb <dlw@exceloncorp.com>

To:   david@drummondgroup.com
cc:   arvola@tibco.com, ebxml-msg@lists.oasis-open.org
Subject:  Re: T2, Proposed solution for ... Re: SyncReply and
      ReliableMessagingMethod in QualityOfServiceInfo



   Date: Wed, 19 Sep 2001 23:45:42 -0500
   From: "David Fischer" <david@drummondgroup.com>

                        (garbage collection is not in the spec is it?).
   Instead of garbage collection, the To Party might occasionally Archive,
which
   almost amounts to the same thing.  Even this would be infrequent.

Certainly they can archive stored legal documents, but for duplicate
elimination, they have to keep a set of message ID's online.  The
question is when that ever-growing set can be GC'ed.  This should be
in the spec.

   Ralph works for an EDI software company, how often is archiving
typically done?
   Is it done?

I, too, would be interested in knowing what is currently done in
practice, in existing EDI systems, about keeping around business
documents.

   From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
   Sent: Thursday, September 20, 2001 10:51 AM

   persistDuration applies in this case. It specifies how long an
   MSH will keep the necessary information (usually MessageId)
   in persistent storage so that idempotency checks can be assured.

I agree, and as I discussed in earlier mail, we must use time-to-live
to deal with messages that might lurk in the network for a time
greater than persistDuration and then reappear as undetected
duplicates.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>