-
Notifications
You must be signed in to change notification settings - Fork 19
Internal logging support #205
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is I understood right that slf4j is the optional dependency?
Are logback users will be obligated to use slf4j?
Are we want to skip logging of reconnects and retried requests for now? Is this the reason to postpone implementing of throttling / filtering of logs? Please, comment it in the issue if so.
I was against of runtime guessing to choose a logger backend. Please, clarify your points if you are disagree (in the issue).
I would rename the 2nd commit: it is not an exampe, it is the implementation of logging of warnings from cluster discovery.
I would add a short example to README: how to attach another logger implementation and set it for the connector.
I would think, whether it worth to test that we emit right warnings. I don't see much value in that for now, to be honest.
src/main/java/org/tarantool/cluster/TarantoolClusterStoredFunctionDiscoverer.java
Show resolved
Hide resolved
Yes, a packaged connector JAR file is dependency-free from
Looks that always,
This can be done in scope of this PR but separate commit.
This is usually out of our responsibility and user's environment configures those options. <configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<logger name="org.tarantool.jdbc" level="INFO" />
<logger name="org.tarantool.cluster" level="DEBUG" />
<logger name="org.tarantool.cluster.TarantoolClientImpl" level="TRACE" />
<root level="debug">
<appender-ref ref="STDOUT" />
</root>
</configuration> Here, we chose About throttling, I think this is also should be configured by a user using logger capability. For example, <turboFilter class="ch.qos.logback.classic.turbo.DuplicateMessageFilter"/> As a result, we are only responsible for adding logger write methods to the right places and with the appropriate level. For client requests, it's usually used the lowest
I based this PR on typical practices used in other java libraries where there're a couple of approaches used in a chain: JVM argument like -Dproperty=value; SPI support (if user provide it's own implementation and registers it as a service provider then it will be used); finally we exploring the CLASSPATH and try to find first appropriate logger backend; if all methods fail it uses the default logging system - VoidLogger of JUL. Of course, we can skip classpath scanning if the logger isn't explicitly configured and pick JUL in the case.
Ok.
Ok.
Hm... Haven't seen that anyone tests this kinda functionality. Logging seems to be not so important for testing and it obviously reflects the current state which we test. |
Let's log at least reconnects: we need it to understand a cause of, say, such problems. Don't so sure about logging of retried requests: if it is easy, maybe it worth to add too (and log errors we got at failed attempts). In general I think that logging of all transient errors we got (and overcomed) is good.
It throttles the same messages: it does not work for a similar (but not same) messages. But it is okay for now I think.
If it is the behaviour that is expected by a user based on expirience with other libraries, so let's behave in this way: properties, SPI, CLASSPATH, JUL. It should not lead to a confusion so. |
d7131fe
to
73fc1f6
Compare
a095ee2
to
f2e638c
Compare
I would move BaseLogger changes to the first commit. Nit: Trailing whitespaces in README. |
f2e638c
to
91bf365
Compare
done |
91bf365
to
946ed15
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
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
Update maven wrapper as well as target maven version to 3.6.2.
946ed15
to
56ee9ea
Compare
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