New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AutoLoadPlugin doesn't play well with aggregation plugin #535

Closed
faxm0dem opened this Issue Feb 5, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@faxm0dem
Contributor

faxm0dem commented Feb 5, 2014

The config below yields the following error message in the log:

plugin_value_list_clone: Unable to determine interval from context for value list "global/aggregation-num/memory". This indicates a broken plugin. Please report this problem to the collectd mailing list or at <http://collectd.org/bugs/>.
#
AutoLoadPlugin true
Interval 2
TimeOut  2

<LoadPlugin memory>
  Interval 2
</LoadPlugin>

<Plugin aggregation>
  <Aggregation>
    Type memory
    CalculateNum true
  </Aggregation>
</Plugin>

Moreover, when specifying aggregation's LoadPlugin explicitly, one sometimes gets the following:

uc_update: Value too old:

Rerunning sometimes makes it go away, sometimes not. It's quite unpredictable.

Last but not least, the actual value returned by aggregation (should be equal to 4 in theory) is quite unpredictable too: sometimes 0, sometimes 4, sometimes 8. Worse, if the interval of aggregation is N times larger than the interval of memory, the resulting num is 4N.

Am I doing something obvious very wrong?

@tokkee

This comment has been minimized.

Show comment
Hide comment
@tokkee

tokkee Feb 8, 2014

Member

The former issue is fixed in PR #539

I haven't looked into the aggregation plugin though.

Member

tokkee commented Feb 8, 2014

The former issue is fixed in PR #539

I haven't looked into the aggregation plugin though.

@mfournier

This comment has been minimized.

Show comment
Hide comment
@mfournier

mfournier Jul 24, 2014

Contributor

Closing since both these problems have independent issues opened (#539 and #297). Feel free to reopen if I misunderstood what you were talking about above !

Contributor

mfournier commented Jul 24, 2014

Closing since both these problems have independent issues opened (#539 and #297). Feel free to reopen if I misunderstood what you were talking about above !

@mfournier mfournier closed this Jul 24, 2014

@tokkee

This comment has been minimized.

Show comment
Hide comment
@tokkee

tokkee Jul 27, 2014

Member

I think this should be kept open. #539 is a PR addressing parts of this issue and #297 is a separate issue. Anyway, that said, I've looked further into the "value too old" issue. It turns out that it's a race during setup of the plugin (or rather in utils_vl_lookup). However, that should happen independent on whether the autoloading is enabled (but given that it's a race, different configs may make it more or less likely to happen). I'll send a separate PR in a bit.

Member

tokkee commented Jul 27, 2014

I think this should be kept open. #539 is a PR addressing parts of this issue and #297 is a separate issue. Anyway, that said, I've looked further into the "value too old" issue. It turns out that it's a race during setup of the plugin (or rather in utils_vl_lookup). However, that should happen independent on whether the autoloading is enabled (but given that it's a race, different configs may make it more or less likely to happen). I'll send a separate PR in a bit.

@tokkee tokkee reopened this Jul 27, 2014

tokkee added a commit to tokkee/collectd that referenced this issue Jul 27, 2014

utils_vl_lookup: Fixed a race when creating user objects.
This could cause multiple aggregation instances to be created in the
aggregation plugin when first writing data to the plugin. This, in turn, led
to "value too old" warnings because subsequently all data was submitted twice.

Thanks to @faxm0dem for reporting this in GH #535.
@mfournier

This comment has been minimized.

Show comment
Hide comment
@mfournier

mfournier Jan 21, 2016

Contributor

Closing as #539 was superseded by f596915, and the race issue was fixed by #676. The only issue left is #297.

Contributor

mfournier commented Jan 21, 2016

Closing as #539 was superseded by f596915, and the race issue was fixed by #676. The only issue left is #297.

@mfournier mfournier closed this Jan 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment