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]
