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:geo...@glympse.com] 
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 <geo...@glympse.com> wrote:

Actually, I implemented an AsyncSqlAppender.

 

On Thu, Jun 14, 2012 at 12:34 PM, George Chung <geo...@glympse.com> 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 <bode...@apache.org> wrote:

On 2012-06-08, Christian Grobmeier wrote:

> Hi,

> On Fri, Jun 8, 2012 at 8:39 AM, Dominik Psenner <dpsen...@gmail.com>
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

 

 

 

Reply via email to