Log datetime #2191
Log datetime #2191
Conversation
| @@ -129,7 +129,7 @@ handle_status(Client &client, [[maybe_unused]] Request args, Response &r) | |||
| COMMAND_STATUS_PLAYLIST ": {}\n" | |||
| COMMAND_STATUS_PLAYLIST_LENGTH ": {}\n" | |||
| COMMAND_STATUS_MIXRAMPDB ": {}\n" | |||
| COMMAND_STATUS_STATE ": {}\n", | |||
There was a problem hiding this comment.
Which commit introduced this bug? This should be mentioned in the commit message so we know whether a backport is necessary.
|
Your commit message doesn't contain an explanation for why you believe this is necessary. |
…at arguments introduced by commit b24b3c1
Time was only in minutes before. Seconds is more useful in analyzing the log for example with issues of timeouts, and reponse times.
When running with stdout output to debug the server or misbehaving clients, it is useful to have the timestamp to detect timing issues and response times. Especially when opening and playing online sources that block the connection thread sometime for a significantly long time that makes the client-server unresponsive and cause timeouts in clients.
…in log_date() This function may be called by multiple threads concurrently. But it uses a static buffer for the datetime string which can be written into simultanously by multiple thread. If it is not thread local, for it to corrent it must be assumed that the implementation writing to the buffer never conflicts with itself in a way that may result in a bogus timestamp output.
Having milliseconds resolution in the log gives more information than just seconds when debugging or analyzing response time issues or effects of changes in server or client code.
geneticdrift
force-pushed
the
log-datetime
branch
from
7f3efb6 to
00fbaa5
Compare
|
Thanks for the review. I've added more explanations in the commit messages as well as the commit number. The logging timestamp format can be made optional by configuration if you prefer. |
No description provided.