Hi, Thanks for taking a look at my "contribution". J
Just fyi, I am not a log4net developer.just a user who hacked up an AsyncSqlAppender. I am using it in a production environment with good results.feel free to use and comment. >From what I can gather from the discussions on this email list, the development team is exploring a more generic Async framework to support Async logging. Cheers, George From: Roman Konovalov [mailto:[email protected]] Sent: Tuesday, July 17, 2012 9:11 PM To: 'Log4NET Dev' Subject: RE: Async logging Hi, Is Async Logging already part of official release? If not, can you please advise when it might be? Many thanks in advance. Best regards, Roman From: George Chung [mailto:[email protected]] Sent: den 15 juni 2012 01:18 To: Log4NET Dev Subject: Re: Async logging Based on the log4net-1.2.11 source tree... Just stick AsyncSqlAppender.cs into the Appender folder. See attached log4net.config file for example of how to use it. Please note, that I set the bufferSize = 1. No need to buffer if you're logging asynchronously. And I think I make an assumption that the LoggingEvents has a size of 1. Minor changes to existing files I modified AppenderSkeleton to make the append lock virtual. AsyncSqlAppender does not need to synchronize multiple writers Sql Server does a fine job of that. :) I fixed AdoNetAppender to swizzle "(null)" and "NOT AVAILABLE" to a real NULL in the db. I fixed AspNetRequestPatternConverter to handle situations where there is no request object. On Thu, Jun 14, 2012 at 12:36 PM, George Chung <[email protected]> wrote: Actually, I implemented an AsyncSqlAppender. On Thu, Jun 14, 2012 at 12:34 PM, George Chung <[email protected]> wrote: Yes, and when you submit async operations, those async requests are queued by the runtime and the completion routines are executed by threads from this thread pool. No need to manage threads at all. I did a pretty trivial hack to the AdoNetAppender to perform Async Sql inserts and it's been working flawlessly in our production environment. I'll attach the modified files shortly. On Fri, Jun 8, 2012 at 4:32 AM, Stefan Bodewig <[email protected]> wrote: On 2012-06-08, Christian Grobmeier wrote: > Hi, > On Fri, Jun 8, 2012 at 8:39 AM, Dominik Psenner <[email protected]> wrote: >> * the ThreadPool should be used in favour over a designated worker Thread > no idea becuase I have no clue on .NET, but it sounds like fun :-) .Net has a built-in thread pool it uses for all kinds of internal stuff, including async executions of user events or serving ASP.NET requests - and it provides access to it for user code. Rather than creating new ad-hoc Threads you re-use one of the pool. Stefan
