Return-Path: Delivered-To: apmail-jakarta-log4j-dev-archive@apache.org Received: (qmail 64772 invoked from network); 1 Apr 2003 07:26:03 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 1 Apr 2003 07:26:03 -0000 Received: (qmail 16358 invoked by uid 97); 1 Apr 2003 07:28:03 -0000 Delivered-To: qmlist-jakarta-archive-log4j-dev@nagoya.betaversion.org Received: (qmail 16351 invoked from network); 1 Apr 2003 07:28:03 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 1 Apr 2003 07:28:03 -0000 Received: (qmail 64404 invoked by uid 500); 1 Apr 2003 07:25:59 -0000 Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@jakarta.apache.org Received: (qmail 64335 invoked from network); 1 Apr 2003 07:25:58 -0000 Received: from mail.telia.se (HELO maile.telia.se) (131.115.230.91) by daedalus.apache.org with SMTP; 1 Apr 2003 07:25:58 -0000 Received: from W2K-RO-NYGREN.Telia.se ([131.115.184.91]) by 131.115.230.91 with InterScan Messaging Security Suite; Tue, 01 Apr 2003 09:28:16 +0200 Message-Id: <5.2.0.9.0.20030401081158.077cceb8@tmsimap.telia.se> X-Sender: rony00@tmsimap.telia.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Apr 2003 08:26:04 +0100 To: "Log4J Developers List" From: Roland Nygren Subject: Re: JDBC Appender Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >Hello all, > >I finally have more time as a major deadline has passed at work. I was >thinking about writing an improved JDBC appender. My intention is to >create a new appender from scratch. As discussed previously, I figured I >would have an abstract base class with an abstract getConnection() class >and two concrete derivatives; one for getting the connection from a JNDI >context and one for getting the connection from the DriverManager. > >I just wanted to check in to see if anybody is working on this already. I >also have a couple of questions: > >1) The original JDBCAppender class has a buffer where it stored the >events until a limit is hit. I'm not sure I understand the rationale >behind this. Doesn't this cause most loggings to be fast but once in a >while one client pays the bill for the rest? It also seems to have been a >source of bugs in the past. Does anyone have a compelling reason for >including it in the new appenders? > >2) Is there a good place to look to get a feel for how the configuration >works? > >Thanks, >Ray A couple of weeks ago we ran into the JDBCAppender bug that was fixed in 1.2.8. While looking at the source code we found the bug and a few other improvement possibilities. Below are two mail I sent to this list. Perhaps I need to explain better my thoughts here. >To: log4j-dev@jakarta.apache.org >From: Roland Nygren >Subject: JDBCAppender - faster buffer handling >Cc: >Bcc: >X-Eudora-Signature: >Date: Thu, 06 Mar 2003 10:50:52 +0100 > > >In JDBCAppender there are two ArrayLists: > /** > * ArrayList holding the buffer of Logging Events. > */ > protected ArrayList buffer; > > /** > * Helper object for clearing out the buffer > */ > protected ArrayList removes; > >Why not just use one ArrayList instead of two to speed things up. >Using the ArrayList buffer as a FIFO-register could look like: > public synchronized void flushBuffer() { > //Do the actual logging > LoggingEvent logEvent = null; > while (buffer.size() >0) { > try { > logEvent = (LoggingEvent)buffer.remove(0); > } catch(Exception e) { > break; > } > try { > String sql = getLogStatement(logEvent); > execute(sql); > } catch (SQLException sqle) { > // Unable to store LogEvent i database, put it back in buffer. > if (logEvent != null) { > buffer.add(0, logEvent); > } > errorHandler.error("Failed to excute sql", sqle, > ErrorCode.FLUSH_FAILURE); > } > } > } > >To: log4j-dev@jakarta.apache.org >From: Roland Nygren >Subject: JDBCAppender - release user thread from writing to database >Cc: >Bcc: >X-Eudora-Signature: >Date: Thu, 06 Mar 2003 11:05:55 +0100 > >It might be a good idea to release the user-thread from doing the actual >database writing. >With a LogThread as in the example below the user-thread will return as >soon as the LogEvent is stored in the buffer. > >Depending on how Log4j is used it might not be permitted to create threads >(like in an EJB container). >A configuration parameter that controlles if the JDBCAppender should use >the thread or not might be useful. >Such configuration is not included below. > > > LogWorker logThread = new LogWorker(this); > > public JDBCAppender() { > super(); > buffer = new ArrayList(bufferSize); > logThread.start(); > } > > public void append(LoggingEvent event) { > buffer.add(event); > if (buffer.size() >= bufferSize) > logThread.wakeup(); > } > > class LogWorker extends Thread { > JDBCAppender parent; > logWorker (JDBCAppender p) { > parent = p; > } > public void run() { > while (true) { > try { > synchronized(this) { > wait(); > } > } catch (InterruptedException e) { } > parent.flushBuffer(); > } > } > > public synchronized void wakeup() { > notify(); > } > } --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: log4j-dev-help@jakarta.apache.org