If only the info message is a concern, then the debug parameter can be set to 1. The info logs are sort of special 'debug' messages that can occur many times and the solution is to lower debug threshold. It is not unusual that connections are lost because of client side or intermediary nodes like nat or ip routers, firewalls, ...

If you want to suggest turning info to debug message in this case, then over the time we can end up only with two log levels debug and print-always (or error), while the current design with many more log levels expect that info level can still be pretty verbose, but not as debug.

Besides info messages, I don't see errors, so I am not sure what you mean with the remark in the title that cannot be terminated. It may take time to be removed from the internal list, clean up being done on timer. Or maybe you can elaborate more what is the exact problem: the info logs or something else behind that.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.