Re: T2, Proposed solution for ... Re: SyncReplyandReliableMessagingMethod in QualityOfServiceInfo

[christopher ferris <chris.ferris@Sun.COM>]

Okay, I won't tell you.

Cheers,

Chris

David Fischer wrote:
> 
> So GC is accomplished by perusing the list and throwing out all entries where
> persistDuration has passed.  Retry would then be limited to less than
> persistDuration - (RetryInterval/2).  Sounds OK to me.  How is persistDuration
> set?  Please don't tell me it's in the CPA . . .
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
> Sent: Thursday, September 20, 2001 10:51 AM
> To: David Fischer
> Cc: Dan Weinreb; arvola@tibco.com; ebxml-msg@lists.oasis-open.org
> Subject: Re: T2, Proposed solution for ... Re: SyncReply
> andReliableMessagingMethod in QualityOfServiceInfo
> 
> David,
> 
> 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.
> 
> As for some additional parameter in the CPA that indentifies
> the NRR archival parameters (how long will I keep messages,
> not just the artifacts for business/legal reasons) I think that
> should be taken up by the CPP/A team.
> 
> I don't think that it is the MSH responsibility to perform
> the archive-for-nrr-audit function. That could be handled
> at a level above the MSH.
> 
> Cheers,
> 
> Chris
> 
> David Fischer wrote:
> >
> > Chris,
> >
> > Yes, I agree.  Should we specify something here rather than leave it as
> > implementation dependant?  Making a note about minimum times between GC might
> > help with Interoperability.  Unfortunately, I can see this as a site parameter
> > rather than a CPA value -- could be a problem.  Any ideas what to do?
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
> > Sent: Thursday, September 20, 2001 9:59 AM
> > To: David Fischer
> > Cc: Dan Weinreb; arvola@tibco.com; ebxml-msg@lists.oasis-open.org
> > Subject: Re: T2, Proposed solution for ... Re: SyncReply
> > andReliableMessagingMethod in QualityOfServiceInfo
> >
> > David,
> >
> > Let's not confuse GC with NRR archiving requirements.
> > From an RM perspective, the MSH must be able to perform GC
> > or it cannot be expected to perform with any degree of
> > efficiency.
> >
> > Cheers,
> >
> > Chris
> >
> > David Fischer wrote:
> > >
> > > We have discussed this in the past and I have asserted that garbage
> collection
> > > would actually never happen at the To Party (unless it was some sort of IM
> > such
> > > as a Mailroom).  For legal reasons, garbage collection of business documents
> > > cannot occur until after 7 years (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.
> > >
> > > I suppose such a restriction would have something to do with either
> > > PersistDuration, TimeToLive or n*Retries*RetryInterval.  Or maybe this is
> > > something new which should go in the CPA?  I would lean toward
> PersistDuration
> > > but I am not sure we have a definitive understanding of what this should be.
> > > OTOH, this question might be out of scope.
> > >
> > > Ralph works for an EDI software company, how often is archiving typically
> > done?
> > > Is it done?
> > >
> > > Regards,
> > >
> > > David Fischer
> > > Drummond Group.
> > >
> > > -----Original Message-----
> > > From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> > > Sent: Wednesday, September 19, 2001 10:25 PM
> > > 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 21:30:37 -0500
> > >    From: David Fischer <david@drummondgroup.com>
> > >
> > >                                                         The From Party can
> > perform
> > >    a Retry at any time it deems appropriate.
> > >
> > > Well, actually, I think there has to be some kind of restriction or
> > > else the To Party would never be able to garbage-collect its set of
> > > already-received message ID's, as we've discussed in the past.
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>