Remove noisy warning #101
Remove noisy warning #101
Conversation
alexxcons
force-pushed
the
remove_unnecesarry_warning
branch
from
2b1be65
to
6752c10
Compare
There was a problem hiding this comment.
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.
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.