Re: New driver logging proposal

On 9 April 2017 at 20:42, Jorge Solórzano <jorsol(at)gmail(dot)com> wrote:

> 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.
>
> Has anyone benchmarked the code before and after ?

> 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.
>
>
To be honest in 15 years of developing the driver I've never used logging
to debug the driver. It is almost always possible to run the driver in a
debugger to see what is going on.

The only time this is useful is when a user can't do this but can turn on
debugging to send protocol messages.

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

How would the bridge degrade performance if logging is off ?

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

>
>
> On Sun, Apr 9, 2017 at 3:54 PM, Vladimir Sitnikov <
> sitnikov(dot)vladimir(at)gmail(dot)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
>>
>>>
>