[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 ;-)


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