[collectd] PluginRetries

[Sebastian Harl]

Hi Justo,

On Mon, Dec 10, 2007 at 12:22:10PM +0100, Justo Alonso wrote:
> On Dec 9, 2007 12:36 PM, Sebastian Harl <sh at tokkee.org> wrote:
> > On Sun, Dec 09, 2007 at 11:56:17AM +0100, Justo Alonso wrote:
> > > 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.
> 
> Not, not for testing ... In production environment, some times, you need
> stop the service (apache, mysql, tomcat, etc..), for new versions, not
> hot-deploys, rotate logs, etc... Now, with the collectd increase interval
> method, I need restart the collectd daemon. Not only this plugin .. all
> plugins that connect to the service,  if you stop the service for a short
> time, you stop the stats for a medium-large time.

Well, usually a service does not take more than a couple of seconds to
restart. So (given a 10 second interval) usually only one read callback should
fail resulting in at most another skipped interval - i.e. you won't loose more
than a single value which is quite acceptable imho.

In general, you will lose at most as many intervals as the service requires to
restart (e.g. if your service takes 30 seconds to restart, collectd will skip
the read callback for at most another 30 seconds). If that's a problem, I'd
argue that something else is seriously broken.

> > 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.
> 
> I think that this issue is not plugin specific.  Ok ... I will start a new
> list thread with the plugin.

That's probably a good idea - If we can look at your code, we might be able to
find / propose better solutions :-)

> > > > >    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.
> 
> It's ok ... Nobody on the maillist support me, and Florian and you say not
> ... It's ok .. maybe I'm the only with interest on this issue.

Well, making the upper limit of the interval (currently 86400 seconds)
configurable can be done. If that's going to help you, tell us, and either
Florian or I will implement it.

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/20071210/9f39d32b/attachment.pgp