Hopefully one of the log4net guys can apply that issue in near future :-) If you have more such valuable contributions, they are much mor ethan welcome - we are just a little short of manpower here
Cheers On Thu, Jul 19, 2012 at 7:26 PM, George Chung <[email protected]> wrote: > 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 > > > > > > -- http://www.grobmeier.de https://www.timeandbill.de
