logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Connection leak with JDBCAppender
Date Fri, 26 Jul 2013 22:20:12 GMT
The approach currently implemented sounds good to me.

Nick, can you document the appender's behavior to avoid further confusion?

Thank you,
Gary

On Jul 26, 2013, at 14:32, Nick Williams <nicholas@nicholaswilliams.net> wrote:

> Yes, this is the intended behavior, and a false-positive on the part of the leak detection.
>
> If the JDBCAppender has to open and close a connection and prepare the same statement
for each logging event (even if it just has to borrow a connection from a pool and prepare
the same statement for each logging event), this could significantly slow down the performance
of the Appender. The reason this isn't a "leak" is because the Appender never gets a new connection
(which would eventually consume your entire pool). It merely re-uses the same connection for
every event. This will perform very well.
>
> I'm open to someone trying to convince me otherwise, but I believe this is the best approach.
>
> Nick
>
> On Jul 26, 2013, at 1:23 PM, Scott Lemke wrote:
>
>> Hello,
>>
>> I'm working on using the JDBCAppender and am seeing a leaked connection.
>> I'm using Glassfish 3.1 with Jersey and Oracle using a JNDI connection for
>> log4j.
>> In my test app just doing a single log will reach the database fine, but
>> then I get the leaked
>> connection warning from Glassfish for the pool.
>>
>> Looking at the code, and please correct me where I am wrong as I'm just now
>> getting into it,
>> it looks like that after JDBCDatabaseManager.writeInternal() the statement
>> doesn't get closed,
>> nor the connection, as JDBCDatabaseManager.disconnectInternal() isn't
>> called until the appender
>> is stopped or the manager is replaced, leaving both open for a potentially
>> long time.
>>
>> I can see arguments on both sides of leaving them open vs closing after
>> each insert,
>> or doing a mix of both allowing for a configurable close time. But my
>> question is,
>> is this intended behavior? If so, I could turn off leak detection.
>>
>> Scott Lemke
>>
>> --
>> "The only thing necessary for the triumph of evil is for good men to do
>> nothing" --Edmund Burke
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message