[collectd] PluginRetries
Sebastian Harl
sh at tokkee.org
Sun Dec 9 12:36:20 CET 2007
Hi Justo,
(Please reply on-list in the future.)
On Sun, Dec 09, 2007 at 11:56:17AM +0100, Justo Alonso wrote:
> On Dec 5, 2007 8:41 PM, Sebastian Harl <sh at tokkee.org> wrote:
> > On Wed, Dec 05, 2007 at 04:54:17PM +0100, Justo Alonso wrote:
> > > when a plugin read fail, "The time between the calls of the function
> > is
> > > increased exponentially until one day (86400 seconds)". Maybe a
> > > "PluginRetries" global parameter can be useful.
> > >
> > > Two option (I think) ...
> > > - First, an integer to the max seconds (now hardcoded 86400).
> > > - Second option is a string with a increment especification
> > (like
> > > at mail queue runner), p.e. "F,2h,15m; G,16h,1h,1.5; F,4d,6h" ....
> >
> > What kind of benefit would that be for the user? Any such option should
> > not be
> > hard to implement but I don't really see any benefits from it (besides
> > confusing most of the users)...
>
> Currently, I'm working on a tomcat plugin (soon I will send you , I'm
> testing it). When I need stop the tomcat (not-hot deploy, patchs, etc...) I
> need restart collectd. With a 30 seconds interval .. if I stop the tomcat by
> 180 seconds, I have a no-stats period of 480-960 seconds .. ;-(
So, do you need it for testing purposes only? In this case you could simply
make sure, the tomcat read callback returns 0 in all cases.
Else it might make more sense (as this seems to be a tomcat-specific issue) to
add an option (to the plugin configuration) to ignore the case when tomcat
cannot be contacted and return 0 from the read callback in that case. Does
this sound reasonable to you? Maybe you want to send in a pre-release of your
plugin so we can already have a look at it and discuss it in more detail.
> > > And .. this configuration per plugin ??
> >
> > Hum... making this configurable on a per plugin base would make things
> > somewhat complex - I'm not sure if it's worth the efforts.
>
> Maybe a new callback function on the plugin ... interval( int mode, int
> seconds ). If the callback function is not NULL, when need the interval we
> call to interval function with PLUGIN_INTERVAL_GET mode ... when we need
> increase interval call it with PLUGIN_INTERVAL_INCREASE mode and when we
> need reset interval (read function ok), call it with PLUGIN_INTERVAL_RESET
> mode .... If the callback function is NULL all work at this time.
This adds a lot of complexity for (imho) very little benefit. As Florian
already pointed out, this is not going to happen.
> tia, and sorry for my english ;-)
Don't worry - most of us are (I believe) non-native speakers ;-)
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://mailman.verplant.org/pipermail/collectd/attachments/20071209/99466154/attachment.pgp
More information about the collectd
mailing list