I can, yes.

Nick

On Jul 26, 2013, at 5:20 PM, Gary Gregory wrote:

> 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 <[email protected]> 
> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to