[rrd-developers] [PATCH] rrdcached "SLURP" for extreme update rates

Tobias Oetiker tobi at oetiker.ch
Fri Oct 3 20:49:48 CEST 2008


Hi Kevin,

Yesterday kevin brintnall wrote:

> Tobi,
>
> I thought about it a little..  We can restrict it to the daemon user (who
> arguably could do just as much damage to the files anyway).. but the file
> system case introduces some strange race conditions.

:-)

> > There are a couple difficulties there..  You may not know how many lines
> > you'll be submitting until you're done (unless you buffer them all in
> > memory first to count them).  To get around that, we would need some sort
> > of special command to terminate output, and a finite state machine to
> > track which state we're in.
>
> I think this is the way to go...  We will have to convert the daemon to
> stdio, but that's something I want to do anyway.  We will have to be
> careful to fflush() in the right places to avoid deadlock.

> As long as one side of the protocol always knows when to block, we should
> be OK.  In other words, it will still be synchronous, but potentially with
> much larger exchanges.
>
>     ->	MULTIUPDATE
>     <- 	0 Go ahead.  Terminate with '.' on its own line (is this necesary?)
>     ->	x.rrd 1:2
>     -> 	y.rrd 2:3
>     -> 	.
>     <-	2 results
>     <- 	x.rrd ??
>     <-	y.rrd ??
>
> A few questions:
>
>  ? Should we do without the initial "0 Go ahead"?

Maybe get inspiration from SMTP ?

I think a termination command makes sense from a 'language' design
point of view, since otherwhise the rrdtool update lines become
commands in their own right.

>  ? how do we match up updates/responses?
>    - if using a separate key, how do we separate from the filename?
>    - what if the user doesn't care about response? (empty key?)

I would only send back complaints, input linenumber followed by the
error. The client can then make sense of it since it can keep track
of the stuff it sent ...

this brings up the question of how to react on an error. Will the
deamon ignore further updates to the same rrd but continue
processing updates to other rrds, or will it abort completely ?


cheers
tobi
> Let me know what you think...  I'll get started on converting to stdio.
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900



More information about the rrd-developers mailing list