Skip to content

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

Closed
Totktonada opened this issue May 31, 2019 · 3 comments · Fixed by #205
Closed

Support logging #194

Totktonada opened this issue May 31, 2019 · 3 comments · Fixed by #205
Labels
feature A new functionality

Comments

@Totktonada
Copy link
Member

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.

@Totktonada Totktonada added the feature A new functionality label May 31, 2019
@nicktorwald
Copy link

nicktorwald commented Jun 4, 2019

A few thoughts about the logging in Java:

  1. there are several famous logging implementations such as log4j2, logback, and JUL;
  2. All of them provide logger/appender abstractions which allow choosing a proper logging level (i.e. ERROR/WARNING/INFO/TRACE etc.) as well as a target destination (file, console, socket etc.)
  3. there are a couple of facades over them such as JCL and SLF4j.
loggers:
a. log4j2 / logback
props: advanced features (lazy eval, async appenders), performant; simple SLF4j integration
cons: external dependency;
b. JUL 
props: JDK built-in component (minimal dependency footprint); compatible with JDBC API.
cons: some performance issues, lack of async appenders, a bit confusing API; some drawbacks with SLF4j integration.
  • The first way to do logging is to use some implementation directly. This way fits the project needs but requires to resolve loggers compatibility by apps which use the connector. (for instance, the app uses logback and the connector uses JUL).

  • The second way is to use facade API such as SLF4j. Then the connector is not responsible for
    actual logging backend but requires that apps use the facade too.

  • The third way is to define its own logging abstraction and use runtime info what the implementation/facade is located in CLASSPATH. This is a more expensive way but it can support both
    direct loggers as well as facades to perform the logging.

It seems 1st way + JUL bunch is the cheapest (Postgres, MSSQL etc.);
2nd way + any facade bunch is not a popular option at all (IMO because of next option);
3rd way + set of loggers bunch is the most flexible and modern way to use the logging in libraries (MariaDb, MySQL, MongoDb, Hibernate and many others).

@Totktonada
Copy link
Member Author

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.

nicktorwald added a commit that referenced this issue Jul 11, 2019
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
nicktorwald added a commit that referenced this issue Jul 11, 2019
Add the example how internal logger can be used.

Follows on: #194
@Totktonada
Copy link
Member Author

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).

nicktorwald added a commit that referenced this issue Sep 9, 2019
Add a warning message if some of the obtained cluster addresses are
invalid and skipped from the processing.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 9, 2019
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
nicktorwald added a commit that referenced this issue Sep 9, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 9, 2019
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
nicktorwald added a commit that referenced this issue Sep 9, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 9, 2019
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
nicktorwald added a commit that referenced this issue Sep 9, 2019
Add a warning message if some of the obtained cluster addresses are
invalid and skipped from the processing.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 9, 2019
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
nicktorwald added a commit that referenced this issue Sep 9, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 17, 2019
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
nicktorwald added a commit that referenced this issue Sep 17, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 17, 2019
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
nicktorwald added a commit that referenced this issue Sep 17, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 17, 2019
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
nicktorwald added a commit that referenced this issue Sep 17, 2019
Add a warning message if some of the obtained cluster addresses are
invalid and skipped from the processing.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 17, 2019
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
nicktorwald added a commit that referenced this issue Sep 17, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 24, 2019
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
nicktorwald added a commit that referenced this issue Sep 24, 2019
Add a warning message if some of the obtained cluster addresses are
invalid and skipped from the processing.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 24, 2019
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
nicktorwald added a commit that referenced this issue Sep 24, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 26, 2019
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
nicktorwald added a commit that referenced this issue Sep 26, 2019
Add a warning message if some of the obtained cluster addresses are
invalid and skipped from the processing.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 26, 2019
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
nicktorwald added a commit that referenced this issue Sep 26, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 27, 2019
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
nicktorwald added a commit that referenced this issue Sep 27, 2019
Add a warning message if some of the obtained cluster addresses are
invalid and skipped from the processing.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 27, 2019
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
nicktorwald added a commit that referenced this issue Sep 27, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 27, 2019
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
nicktorwald added a commit that referenced this issue Sep 27, 2019
Add a warning message if some of the obtained cluster addresses are
invalid and skipped from the processing.

Follows on: #194
nicktorwald added a commit that referenced this issue Sep 27, 2019
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
nicktorwald added a commit that referenced this issue Sep 27, 2019
Add basic info about supported logging system in the connector.

Follows on: #194
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A new functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants