-
Notifications
You must be signed in to change notification settings - Fork 19
Support logging #194
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
Comments
A few thoughts about the logging in Java:
It seems |
Thanks for charging me with needed background! 3rd way looks most promising for me except that I'm against of autoconfiguration based on CLASSPATH. It is possible that several loggers are in CLASSPATH and such automation confuses more than helps IMHO. I would let user configure logger system explicitly. The default would be no-op or JUL (because it is built-in). The latter choice would lead to hard dependency on it, so maybe no-op is the better choice. It would be good to have general logger API that will allow to enable any logging system on a user side and provide bunch of built-in adaptors for loggers. I hope it is possible to do so w/o hard dependency on each supported logger. It would be good if a user will able to share its logger adaptor with us to make it built-in w/o modifications: I mean that our built-in logger adaptors should use the same public API as external ones. We should choose which logger systems we should support natively: my thought here is that we should target modern apps in the first place. So it seems that it worth to support SLF4j and logback as modern and relatively popular loggers (please, correct me if I'm wrong). Others can be added if there will be a visible demand. I have several thoughts about logging in the mind:
Don't sure whether these point can be handled on a logger system side (at least because it cannot distinguish similar messages from different ones, I guess). So we possibly should handle them on our side. How big the API of our logger expected to be? I suspect it should be quite small and it worth to going in the 3rd way, but if I'm wrong we possibly should reconsider this. |
Add a logging abstraction over foreign logger backends. The internal logger supports JUL and SLF4J (Logback) loggers in this commit. Parametrized messages are supported via MessageFormat instead of relying on external loggers support. Closes: #194
Add the example how internal logger can be used. Follows on: #194
In #205 (comment) Nikolai points that some kind of filtering and throttling can be organized on a logger side, so let's skip this part (within the scope of this issue at least). |
Add a warning message if some of the obtained cluster addresses are invalid and skipped from the processing. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add a logging abstraction over foreign logger backends. The internal logger supports JUL and SLF4J (Logback) loggers in this commit. Parametrized messages are supported via MessageFormat instead of relying on external loggers support. Closes: #194
Add a warning message if some of the obtained cluster addresses are invalid and skipped from the processing. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add a logging abstraction over foreign logger backends. The internal logger supports JUL and SLF4J (Logback) loggers in this commit. Parametrized messages are supported via MessageFormat instead of relying on external loggers support. Closes: #194
Add a warning message if some of the obtained cluster addresses are invalid and skipped from the processing. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add a logging abstraction over foreign logger backends. The internal logger supports JUL and SLF4J (Logback) loggers in this commit. Parametrized messages are supported via MessageFormat instead of relying on external loggers support. Closes: #194
Add a warning message if some of the obtained cluster addresses are invalid and skipped from the processing. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add a logging abstraction over foreign logger backends. The internal logger supports JUL and SLF4J (Logback) loggers in this commit. Parametrized messages are supported via MessageFormat instead of relying on external loggers support. Closes: #194
Add a warning message if some of the obtained cluster addresses are invalid and skipped from the processing. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add a logging abstraction over foreign logger backends. The internal logger supports JUL and SLF4J (Logback) loggers in this commit. Parametrized messages are supported via MessageFormat instead of relying on external loggers support. Closes: #194
Add a warning message if some of the obtained cluster addresses are invalid and skipped from the processing. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
Add a logging abstraction over foreign logger backends. The internal logger supports JUL and SLF4J (Logback) loggers in this commit. Parametrized messages are supported via MessageFormat instead of relying on external loggers support. Closes: #194
Add a warning message if some of the obtained cluster addresses are invalid and skipped from the processing. Follows on: #194
Add logging waring messages when client tries establishing connection to Tarantool instance. All the request that cannot be processed because of some transient errors are also traced. Disable JUL logging for test classes by default. Follows on: #194
Add basic info about supported logging system in the connector. Follows on: #194
We have cases where an error can be overcomed and the connector able to proceed further. Such cases should be reported for a user, because they can appear due to a configuration error. Also now we have the background job: periodical cluster discovery for cluster client, which discards incorrect results. A user may expect that a next scheduled discovery was proceeded successfully if there are no warnings and exclude old nodes from a cluster.
We need to support logging by default (are there a mechanism in Java for that?) and provide the ability to change logger: to filter, silent, redirect or change a format of logs.
Also I propose to add logging for discarded cluster discovery results in the scope of this feature. Don't sure about retried transient errors in cluster client: maybe it worth to warn about them too.
The text was updated successfully, but these errors were encountered: