Builder collectd-60-solaris10-i386 Build #40

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The AnyBranchScheduler scheduler named 'schedule-collectd-60' triggered this build

Steps and Logfiles:

1. git update ( 5 secs )
   1. stdio
2. setproperty property 'ciflags' set ( 0 secs )
   1. stdio
   2. property changes
3. shell '/opt/csw/bin/bash ./build.sh' ( 27 secs )
   1. stdio
4. shell_1 './configure --prefix=/opt/csw ...' ( 40 secs )
   1. stdio
   2. config.log
5. shell_2 'gmake -k ...' ( 1 mins, 45 secs )
   1. stdio
6. shell_3 'gmake check' ( 13 secs )
   1. stdio
   2. test-suite.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Leonard Göhrs

   l.goehrsohnoyoudont@pengutronix.de

Timing:

All Changes:

:

1. Change #170976

   Category	None
   Changed by	Leonard Göhrs <l.goehrsohnoyoudont@pengutronix.de>
   Changed at	Sun 26 Mar 2023 19:47:57
   Repository	https://github.com/collectd/collectd
   Project	collectd/collectd
   Branch	collectd-6.0
   Revision	44185083d848b4618811d001a8be51a53cc3c1dd

   Comments

   src/daemon/plugin.c: init fam.{time,interval} before uc_update(fam) on dispatch
   
   The changes in commit
   
     55efb56a ([collectd 6] src/daemon/plugin.c: Use one thread per write plugin)
   
   changed the order in which the time and interval on a to-be-dispatched metric
   family were set and uc_update() was called on the metric family.
   
   The time and interval inside a metric family have to be set before calling
   uc_update() on it, otherwise warnings like these will be generated en masse[1]:
   
     uc_update: Value too old: … value time = 0.000; last cache update = 0.000;
   
   And the "missing" handlers for the metric family will be called resulting in
   plugins like write_prometheus dropping the value, resulting in it not showing
   up when queried [2].
   
   This change requires the inroduction of a second metric_family_clone() in the
   dispatch path:
   
    plugin_dispatch_metric_family()
    | \
    |  Has to modify the passed fam to initialize the correct time and interval.
    |  So it has to metric_family_clone() the input.
    v
    plugin_dispatch_metric_internal()
    | \
    |  Calls the filter chains and uc_update(fam), which both require correct
    |  times and intervals to be set.
    |
    |     plugin_dispatch_metric_internal() calls either fc_process_chain() or
    v <-- fc_default_action() depending on if a chain is configured.
    |\
    | fc_process_chain()
    | |
    | v
    | plugin_write()
    |   \
    |    A chain may call plugin_write() multiple times with the same fam.
    |    This means plugin_write() can not take "ownership" of the fam,
    |    put it in a queue and free it once it feels like it.
    |    It must instead create another clone to put into the queue.
    v
    fc_default_action()
    |
    v
    plugin_write()
      \
       This is the much more common case, as filter chains are a niche feature,
       and in this case we could actually transfer ownership of the fam to
       plugin_write and save a clone, but we would have to tell plugin_write()
       that it is responsible for freeing the passed fam.
   
   The negative performance impact of the clone could be mitigated by adding a
   reference count to the metric_family_t struct and only freeing it once all
   references to it are gone. But that would be a larger change and not a bug fix.
   
   Only fix the "uninitialized time and interval" bug for now.
   
   [1]: https://github.com/collectd/collectd/pull/4026#issuecomment-1463884930
   [2]: https://github.com/collectd/collectd/issues/4098
   
   Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>

   Changed files

   • src/daemon/plugin.c