[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: replayLogStartTime

Sharon Chisholm wrote:

Hi

It occurs to me that we are trying to overload a single variable with
two bits of information
  - What time the log starts
  - Earliest notification in the log (still need to worry about the no
notification case).

Should we simply have two separate items? Wouldn't that be simpler?


I like Simon's proposal.
Should there be 2 timestamps (per stream)?

  replayLogCreationTime -- if exists, the time the log was opened
  replayLastDropTime -- if exists, eventTime value of the last notification
           deleted from the replay log

Is the log creation time really needed, or just the timestamp
of the last dropped notification from the log?



Sharon


Andy



-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Friday, September 07, 2007 5:18 AM 
To: simon.leinen@switch.ch
Cc: Chisholm, Sharon (CAR:ZZ00); ietf@andybierman.com;
netconf@ops.ietf.org
Subject: Re: replayLogStartTime

Simon Leinen <simon.leinen@switch.ch> wrote:

Martin Bjorklund writes:
There are two things different from the current spec. The first part gives you the creation time unless notifs has been dropped. I think this is good. The second part is that you want the timestamp of the last notif dropped instead of the timestamp of the first one in the log. I'm not sure I understand why this would be better. I think both definitions work equally well - the reason this object is 


there is to let the client know if it has missed any notifs.
I think you just answered your own question (why "timestamp of last notification dropped" is better): Because it tells me *exactly* from when on the record in the notification buffer (or "replay buffer") is complete. (Which is the information you need to find out whether you missed something, just expressed as its complement.)
The time of the oldest notification that still is in the buffer (what's currently in the draft) only tells me an approximation, and when there was a long period of silence preceding that oldest notification (such long periods of silence do occur in our notification logs, we actually like those :-), the approximation can be very imprecise. 

Ok, you've convinced me.  Your definition gives more information to a
client.

With the original definition, if a client's latest notification has
timestamp t, and replayLogStartTime is s, s > t, the client would have
to assume that he has missed some notifs.  Which may or may not be true.
WIth your definition, if s > t the client knows for sure that he has
missed some notifs.

So, I agree, we should change the semantics of replayLogStartTime to say
what you said:

  * the time the buffer was created and started recording notifications,
    or,
  * if notifications already had to be dropped, the time of the most
    recent notification that had to be dropped.

Maybe modify the name replayLogStartTime as well...


/martin

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>





--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>