Counter decrement functionality causes error #357
Comments
|
Yeah seems I made the checks too tight in the helpers. It's related to #350 |
SaveTheRbtz
pushed a commit
to SaveTheRbtz/statsd
that referenced
this issue
Dec 31, 2013
This commit introduces following changes: * Be liberal in what you recieve - do not rely on regexps for packet parsing but instead accept anything that can be parsed by JavaScript as a number e.g: +1e-17, -0511, 0xDEADbeef, etc * Accept both positive and negative counters with explicit / implicit sign * Provides more strict error checking then regexp, for example following strings match previously used '([\-\+\d\.]+' regexp: . .123. .\-+\0\+-.1- Also while here added more tests. Closes: statsd#350 statsd#357 Signed-off-by: Alexey Ivanov <SaveTheRbtz@GMail.com> Signed-off-by: Alexey Ivanov <aivanov@linkedin.com>
SaveTheRbtz
pushed a commit
to SaveTheRbtz/statsd
that referenced
this issue
Dec 31, 2013
This commit introduces following changes: * Be liberal in what you recieve - do not rely on regexps for packet parsing but instead accept anything that can be parsed by JavaScript as a number e.g: +1e-17, -0511, 0xDEADbeef, etc * Accept both positive and negative counters with explicit / implicit sign * Provides more strict error checking then regexp, for example following strings match previously used '([\-\+\d\.]+' regexp: . .123. .\-+\0\+-.1- Also while here added more tests. Closes: statsd#350 statsd#357 Signed-off-by: Alexey Ivanov <SaveTheRbtz@GMail.com>
SaveTheRbtz
pushed a commit
to SaveTheRbtz/statsd
that referenced
this issue
Dec 31, 2013
This commit introduces following changes: * Be liberal in what you recieve - do not rely on regexps for packet parsing but instead accept anything that can be parsed by JavaScript as a number e.g: +1e-17, -0511, 0xDEADbeef, etc * Accept both positive and negative counters with explicit / implicit sign * Provides more strict error checking then regexp, for example following strings match previously used '([\-\+\d\.]+' regexp: . .123. .\-+\0\+-.1- Also while here added more tests. Closes: statsd#350 statsd#357 Signed-off-by: Alexey Ivanov <SaveTheRbtz@GMail.com>
|
+1 for this bug, i'm affected using the version 0.7.1 of StatsD. Any prevision of when this issue will be fixed? I've seen #350 but seems like the PR is not being updated :/// PS: I've seem #382 (which is actually merged (?)) but seems like the changes that it proposes is reverted before the release of v0.7.1, any info about it? |
|
this is fixed with #382 and the changes are in master |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
'+' and '-' characters are not allowed in counter packets, preventing a client from decrementing a counter. I tested this bug using my own c++ client, as well as the python client from the "examples" folder. In both cases I get a bad line error sending a packet of the form:
The problem seems to be in the lib/helpers.js file and was a result of commit 53fd384 which disallowed the '+' and '-' characters for all but gauge packets. A simple fix could be to add
fields[1] == 'c'as an additional condition to theif (fields[1] == 'g')statement since the format for both counters and gauges seem to be identical.The text was updated successfully, but these errors were encountered: