[rrd-developers] Accelerator Daemon
Sebastian Harl
sh at tokkee.org
Tue Jun 24 23:05:12 CEST 2008
Hi,
On Tue, Jun 24, 2008 at 10:28:08PM +0200, Tobias Oetiker wrote:
> about the design, I think there are two important things we should
> be extra careful to observe.
>
> a) make sure rrdtool will not write the rrd file directly if the
> daemon has data to write to it. One solution is locking, but it
> should also work it there is the rrdcached has a logfile to
> replay. Maybe the new 1.4 dataformat could contain something
> where the daemon can mark a file as 'pending-updates' which
> would prevent any direct write access.
I was thinking about that as well for a second (I've even opened my
editor to write an appropriate response) but then I decided this would
not be a very good idea, for the following reasons:
- Those indirect checks (i.e. the 'pending-updates' flag or some
logfile) are hard to implement if the daemon is running on another
host (which I suppose is a feature quite a few people will like).
- Let's assume some reasonable check could be implemented. Then what is
rrdtool supposed to do if there are updates pending by the daemon? It
could simply discard the updates but losing data is what we're
actually trying to avoid here. It could write the data to some
temporary location but that would be quite hard to keep track of and
merge at an appropriate time. Or, it could pass the data to the
daemon but that's what the user did not want for whatever reason. So,
imho either solution is not what we would want.
- I guess there could be quite a few ways how to get into that
situation (i.e. having pending updates) and I don't think it will be
possible to think of all of them. So this whole mechanism could be
quite error prone.
- The only way to be _really_ sure that there are pending updates it to
contact the daemon. Again, that's not what the user wants though. In
any case this would introduce quite some overhead if we had to check
the daemon any time we want to work with some RRD file.
So, I really think this should be up to the user to take care of. It was
her decision to switch from using the daemon to not using the daemon in
the first place. Imho a big fat warning in the manual should be
sufficient.
> b) have means (an environment variable) where one can tell rrdtool
> to use the daemon without changeing any source, since this will
> allow much easier testing and use with other frontends.
I was rather thinking about introducing a configuration file. Anyway,
that's details - I fully agree that having some means to configure that
would be a really good idea.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20080624/e7d70c27/attachment.bin
More information about the rrd-developers
mailing list