<br><br><div class="gmail_quote">On Thu, Nov 1, 2012 at 1:31 PM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> > if you have:<br>
> ><br>
> > Time | Value<br>
> > 0 | 10<br>
> > 1 | 30<br>
> > 2 | 50<br>
> > 3 | 80<br>
> > 4 | 100<br>
> ><br>
> > If your delta-pollster is down at 1 and 2, you restart at 3,<br>
> > therefore at 4 you'll send "20" as usage (100 minus 80).<br>
> > So you miss the delta between 10 (time 0) and 80 (time 3)<br>
> > (therefore 70 for free!).  If you send right away 80 at<br>
> > time 3 when restarting, the API will be able to guess that<br>
> > between 0 and 3 the value went from 10 to 80.  With delta<br>
> > approach, the API cannot guess that.<br>
><br>
><br>
> Sure it can, you just need to move where the caching is done. Using a<br>
> local cache to maintain the previous time a value was published you<br>
> would know at time 3 that the last published value was 10, and so<br>
> send 70. So the total will be correct.<br>
<br>
</div>Good point, previously IIUC there was an implicit assumption that<br>
any prev time caching would be done in-memory, hence lost across<br>
process restarts.<br>
<br>
But as you point out, these data could be persisted locally by the<br>
compute agent.<br>
<br>
What would be the best way to achieve this? A small sqlite DB<br>
per-agent, or even simpler just a pickled dict? The latter would<br>
avoid the complexity of DB versioning and migration.<br></blockquote><div><br></div><div>I discussed this issue at the summit with James Penick of Yahoo, and he showed me some code in their agent that is using a sqllite db. We will want to build a nice API so pollsters can use the cache without having to worry about how it is implemented, which would let us deal with any versioning issues in a central spot.</div>
<div><br></div><div>Doug</div><div><br></div></div>