Hi Nicko, I'm glad to hear you're planning to add a method to allow the ado appender to be flushed programmatically. That would be great! Meanwhile we'll keep our default logging settings at 1 event per buffer.
--Howard -----Original Message----- From: Nicko Cadell [mailto:[EMAIL PROTECTED] Sent: Saturday, April 16, 2005 4:49 PM To: Log4NET User Subject: RE: Buffer Flushing and Table Maintenance in the ADONetAppender I agree with Ron on the scope of the AdoNetAppender. The database provides wonderful tools to manage the data stored: stored procedures, triggers, and DTS packages (or equivalent). I happen to think that in production the AdoNetAppender should connect to the database with a restricted account that only allows execution of a single stored procedure that logs an event. As for flushing the buffer, this is rather more difficult than it needs to be, or rather it is not possible with the current implementation of the BufferingAppenderSkeleton, however it is simple enough to add. It is possible to do something like logging a very high level event and configure an Evaluator on the appender to force the buffer to be flushed when the event is received, however this does have some drawbacks; you need to hide the special event from the DB (you could do this by calling a stored procedure to insert the event), you also need to hide the event from any other appenders that might receive it. I will add a method to allow the ado appender to be flushed programmatically, you can patch your source and rebuild if you require that functionality immediately. I have created an issue to track this: http://issues.apache.org/jira/browse/LOG4NET-24 Cheers, Nicko > -----Original Message----- > From: Howard Weisberg [mailto:[EMAIL PROTECTED] > Sent: 14 April 2005 23:15 > To: Log4NET User > Subject: RE: Buffer Flushing and Table Maintenance in the > ADONetAppender > > OK, I can see your point of view. For example, my son doesn't think > that cleaning up his room falls under the scope of a child, and > proposes that it be done by a separate housekeeper. > > Just kidding, this is no big deal. > > What about flushing the output buffer? We are building a log viewer > application. Before it makes a display for the user, it needs to issue > a command to flush the buffer so the user will be able to see the most > recent entries. > > -----Original Message----- > From: Ron Grabowski [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 14, 2005 3:02 PM > To: Log4NET User > Subject: RE: Buffer Flushing and Table Maintenance in the > ADONetAppender > > Personally I don't think that database maintenance falls under the > scope of a logger. If you really want that functionality, a good > starting point may be to introduce <timer> nodes for the > AdoNetAppender appender that executes <commandText> when a > <datePattern> changes: > > <appender ... > > <bufferSize ... /> > <connectionType .../> > <connectionString ... /> > <commandText ... /> > <parameter ... /> > <parameterName ... /> > <dbType ... /> > <layout /> > </parameter> > <timer> > <!-- delete DEBUG level records every month --> > <datePattern value="yyyMM" /> > <commandText value="DELETE FROM Logs WHERE [Level] = 'DEBUG'" /> > </timer> <timer> > <!-- delete all records older than 12 hours every day --> > <datePattern value="yyyMMdd" /> > <commandText value="DELETE FROM Logs WHERE [date] < DATEADD(Hour, > -12, GETDATE())" /> </timer> </appender> > > I just made up those sql statements so they probably cancel each other > out in terms of what data they delete. I would imagine some people > would want some <commandText> executed every XX log entries. I can't > think of a good way to express that. I've looked at some of the > elements that make up a RollingFileAppender but those don't convert > well to databases... > > - Ron > > --- Howard Weisberg <[EMAIL PROTECTED]> wrote: > > If someone implements the Table Maintenance part, I think > it should be > > > configurable by Level and also by expiration date and/or maximum > > number of rows. > > > > -----Original Message----- > > From: Burger, Erik [mailto:[EMAIL PROTECTED] > > Sent: Thursday, April 14, 2005 3:48 AM > > To: 'Log4NET User' > > Subject: RE: Buffer Flushing and Table Maintenance in the > > ADONetAppender > > > > Hi Howard, > > > > As far as I know, you have to roll your own. What I did > (probably not > > the only way) is add a Job to the SQL Server Agent to execute the > > following T-SQL command every hour: > > DELETE > > FROM <tablename> > > WHERE [date] < DATEADD(Hour, -12, GETDATE()) > > > > This will delete all entries older than 12 hours. Of course, the > > [date] field might differ per configuration. In my > particular case I > > needed to save the date and time as two separate strings to support > > legacy code. > > My command is therefor slightly more complicated :) But it > works well. > > > > I would love to know if there is a better way of doing > this. Also, a > > configuration setting in log4net would be great! If I had > the time I > > would try my hand at it myself. Being able to limit either > the age of > > entries or the number of rows would be a godsend. Maybe (but that > > would be pushing it a > > bit) it would even be possible to 'relog' the > soon-to-be-deleted rows > > to a FileAppender or SmtpAppender. > > > > Mmmm..coolness.. > > > > Anyway, hope this helps, > > Erik > > > > ------------------------------- > > Lead Developer > > Research and Development Group > > GPXS Wireless Ltd. > > Southampton, United Kingdom > > Phone: +44 (0) 23 8076 2519 > > Fax: +44 (0) 23 8076 2555 > > Email: [EMAIL PROTECTED] > > > > > > -----Original Message----- > > From: Howard Weisberg [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 13, 2005 7:36 PM > > To: [email protected] > > Subject: Buffer Flushing and Table Maintenance in the ADONetAppender > > > > > > Is there support for programmatically flushing the buffer? > > > > Is there support for deleting records in the SQL table that > are older > > than a specified amount (to keep the table from growing without > > bounds) or do I need to roll my own? > > The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system.
