Skip to content
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

modules/statsd: ensure statsd failures do not stop execution #3819

Merged
merged 2 commits into from Apr 28, 2024

Conversation

ostap0207
Copy link
Contributor

Pre-Submission Checklist

  • Commit message has the format required by CONTRIBUTING guide
  • Commits are split per component (core, individual modules, libs, utils, ...)
  • Each component has a single commit (if not, squash them into one commit)
  • No commits to README files for modules (changes must be done to docbook files
    in doc/ subfolder, the README file is autogenerated)

Type Of Change

  • Small bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds new functionality)
  • Breaking change (fix or feature that would change existing functionality)

Checklist:

  • PR should be backported to stable branches
  • Tested changes locally
  • Related to issue #XXXX (replace XXXX with an open issue number)

Description

2 issues:

Issue 1:
Currently statsd functions return bool: true or false depending when
the function succeeds or fails respectively.

This value gets implicitly converted to int: true -> 1, false ->
0.

For Kamailio 1 means succesfull execution, but 0 means to stop
processing messages, which is not what we want as statsd should not impact
flow execution. Instead we want to return -1 which signifies error,
but the flow continues.

Issue 2:
statsd_init executes statsd_connect which tries to connect to statd
server.

If connection fails then kamailio fails to start.
This is not the desired behaviour as:

  1. Kamailio should continue working even if statsd server is down,
    metrics should not impact runtime.
  2. statsd_connect is also re-executed each time we try to send the metric https://github.com/salemove/kamailio/blame/master/src/modules/statsd/lib_statsd.c#L76,
    so it's initial result is not essential.

Note, that before 5.8 the result of init was already ignored due to
implicit conversion of false to 0
until after
0186246
was introduced (which could be considered a breaking change even if it
seemingly fixes a bug in conversion).

Currently statsd functions return bool: `true` or `false` depending when
the function succeeds or fails respectively.

This value gets implicitly converted to `int`: `true` -> `1`, `false` ->
`0`.

For Kamailio `1` means succesfull execution, but `0` means to stop
processing messages, which is not what we want as statsd should not impact
flow execution. Instead we want to return `-1` which signifies error,
but the flow continues.
return -1;
}

return 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the above line be return 1? Or I misunderstood the purpose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, correct, we noticed this in our local build but haven't updated here yet, will fix

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

statsd_init executes `statsd_connect` which tries to connect to statd
server.

If connection fails then kamailio fails to start.
This is not the desired behaviour as:
1. Kamailio should continue working even if statsd server is down,
   metrics should not impact runtime.
2. `statsd_connect` is also re-executed each time we try to send the metric https://github.com/salemove/kamailio/blame/master/src/modules/statsd/lib_statsd.c#L76,
so it's initial result is not essential.

Note, that before 5.8 the result of init was already ignored due to
implicit conversion of `false` to `0`
until after
kamailio@0186246
was introduced (which could be considered a breaking change even if it
seemingly fixes a bug in conversion).
@miconda
Copy link
Member

miconda commented Apr 28, 2024

Thanks!

@miconda miconda merged commit 5e66ba2 into kamailio:master Apr 28, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants