[rrd-developers] rrd cache work

[kevin brintnall]

On Thu, Sep 04, 2008 at 12:57:39PM +0200, Florian Forster wrote:
> >  * forward declarations in the relevant *.c files
> >  * internal-only include file
> >  * change rrd_flush to a no-op if no daemon connection
> 
> I'd use the second option. AfaIk `rrd_tool.h' is already such an
> internal-only file..

We came to the same conclusion independently.

> As far as I know, one of the goals for 1.4 is to imiprove the library to
> provide a ``real'' API, something very similar to the existing `*_r'
> functions. This means, of course, that some backwards-incompatible
> changes have to be made, but it might also be possible to provide a
> compatibility layer..
> [...]
> I think it's time for the old API to die. I see two big drawbacks to
> passing `argc' and `argv' to API functions:

I'll defer to Tobi on design changes of this magnitude.

> >  * if the rate is too low, then client applications may block for a long
> >    time waiting for flushes, while the hardware is idle (think graph with
> >    a lot of RRDs).
> 
> No, `flush' command don't honor the rate limit. It's a flush, not a case
> of ``Would be nice to have on disk again, in case of something goes
> wrong. Don't really care when this happens, though. Thanks.''

How do you propose implementing the rate lmit?

BTW I ran into an interesting bug that only appears under load..  the
sread() function doesn't handle this type of read well:

	first read	"UPDATE file 1:2:3:4\nUPDATE"
	second read	"FILE file2 3:4:5:6\n"

I think it would be best to consolidate the sread/swrite functions into a
single implementation that handles this case correctly.

Also, I am noticing that there are a few polling cycles that end up
installing NaN into my RRDs..  Have you run across this before?  I'm
instrumenting some more debugging code to track this down now :/

-- 
 kevin brintnall =~ /kbrint at rufus.net/