Re: [JDBC] New driver logging proposal - Mailing list pgsql-jdbc

Yes, I agree with Vladimir, I don't like the idea of a wrapper (anti-pattern), JUL can be mostly fine if configured correctly.

Most performance degradation claims are related to using others logging frameworks and using a bridge to redirect from JUL to SLF4J and that by design it can not impersonate JUL api.

The focus should be that when the logging is disabled it don't introduce some degradation when using slf4j+some other framework (IMO there is where an impact in performance can be found), in other words, when it's disabled, it's truly disabled.

The second focus should be make the logging useful for end users, most of the logging is for developers and related to the protocol, having fixed categories like the proposed ones can help a lot here, and as contradictory as it seems there is needed a lot more log messages. In the mssql-jdbc for instance there is a lot more verbose messages and have a lot entering and exiting messages (not the approach I would use but it's there).

In the issue #788 I have to recompile the driver with more log messages simply because the ones that are there are simply not enough to found a problem in the code.

In the mssql-jdbc the connection id (and statements and resultsets) are simply incremental id, and should be more than enough to identify calls related to a connection/statement/resultset, I mean if you call a prepared statement for instance and you set parameters to it, in a highly concurrent enviroment a setString() related to a prepared statement can seems that was called by another prepared statement in the log.

So far I have seen more benefits of using JUL than claims of performance degradation (and most of the claims are when using slf4j bridge). Of course there is more to do, it might be not the best choice but was that or introduce a optional dependency of SLF4J (wich is a bad idea based on the SLF4J developers https://www.slf4j.org/faq.html#optional_dependency) or simply introduce a direct dependency of SLF4J making a forced used of a dependency that not many want. This is like the chicken-egg problem.

On Sun, Apr 9, 2017 at 3:54 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:

Daniel,

I wonder if adding "logging=true" property is required to meed the performance requirements at all.

I would like to refrain from adding new configuration options.

What bothers me with "replace jul with abc" approach is it will be yet another 100500+lines change that is hard to review.

I wonder how far can we go with keeping jul interfaces. Is it possible/enough to just add relevant "log level caching at the resultset/etc levels"?

Daniel>Show connection IDs in the log messages to identify connections, and not in logging categories

ConnectionIDs are unpredictable, so I can hardly imagine a case when end-user would activate logging based on the connection id (e.g. enable debug for a specific ID only).

On the other hand, having something like "org.postgresql.sql.DB_NAME.USER_NAME.CONN_ID" as a logging category could make sense.

Vladimir