No reason to issue a warning in the log for any clock-related shifts.

[moreaki]

For years, people's logs have been filled up with warnings about thread starvation and retrograde clock change detections. This change sets the logger level to info for the following reasons:

• There is really nothing the end user can do with this warning, the code solves the issue by itself.
• It creates many questions and searches for solutions on the Internet because people see a WARN, where clearly an INFO would be sufficient
• None of the code paths which follows (hot or cold) has any WARN statements, therefore the granularity of the logger is misleading

[thiagosperandio]

That happened to me too.

I agree that it should be a WARN, because we always need to be aware of problems that may occur in a production environment.

So, it's a warning about hibernation, either of the machine or our service thread.

Maybe can increasing some additional information, like "checks if the machine was suspended".

[moreaki]

That happened to me too.

I agree that it should be a WARN, because we always need to be aware of problems that may occur in a production environment.

So, it's a warning about hibernation, either of the machine or our service thread.

Maybe can increasing some additional information, like "checks if the machine was suspended".

Confused by your reply. With whom do you agree? Certainly not with me (which is fine, but your explanation makes little sense). I clearly made a patch to set the level to INFO from WARN, so we don't get pointless information. Did you read my explanation? There is nothing that you're being warned for which you can influence at all and all cold and warm code paths following that statement are on level INFO.

In short: a WARN level statement in the logs at this point in the code, as argued in my original statement, makes absolutely NO sense.

Let me know if I misunderstood something from your reply. Also, I would be extremely happy to hear from you on how you intend to address the issue outside of the already existing code which amends the reported issue further down in the code path. Any insights that a human intervention can do to alleviate this wrongly reported issue as a WARN would be most welcome, and probably close dozens of stackoverflow questions with people equally wondering why their logs fill up with statements of a potential issue over which they don't seem to have an influence.

[benedictdube]

I clearly made a patch to set the level to INFO from WARN, so we don't get pointless information. Did you read my explanation? There is nothing that you're being warned for which you can influence at all and all cold and warm code paths following that statement are on level INFO.

In short: a WARN level statement in the logs at this point in the code, as argued in my original statement, makes absolutely NO sense.

I'm in the early stages of my career in software eng. and would like to confirm, is it not appropriate to log at WARN level when there is something in the program that might (or can) lead to an unwanted state?
For example; If I encounter this frequently, it could guide my decisions in the scheduled jobs I have on my droplet/EC2 instance if I encounter this frequently? Saving me from waiting for a higher logging level which might cause unavailability for the service. This, I doubt I would pick up if it were logged at INFO level.