-
Notifications
You must be signed in to change notification settings - Fork 3
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
Remove noisy warning #101
Remove noisy warning #101
Conversation
2b1be65
to
6752c10
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ok for not spamming graylog anymore, but I have to admit I'm not completely sure about the implications of this thread not running at it's configured rate.
Maybe a better way (out of this PR) would be to set some kind of flag/tag on the data whenever this happens, so the correlation between missing data and thes slow poll loop iterations can be investigated without spamming the log system?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with removing the text-based logger ... in any case, logging in a real-time thread/handler is a bad idea, since the logging affects it's performance in the first place ... we should replace text-based logging in hot-paths entirely and maybe (maybe) replace it with a proper metrics logger (<-> logged via prometheus) and server-local diagnostics property.
I agree with you, logging does not make much sense here / generally in code which possibly is called within high rate. I opened an issue to fix it in a general way: #102 |
merged it, thank you for the review ! |
I was to quick with adding that warning in #92. The warning was printed alot on different servers, filling up our graylog with nonsense messages.
I tried to increase the poll duration to get rid of the warning. Though for some frontends, as soon as no warning was displayed, the number of received samples per time on the FESA side did not match the expectations any more (in some cases as well lost buffers were observed).
So I suppose it is normal / can be expected that ocasionally no waiting needs to be done, and it should not lead to a warning.