[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck application process

["Stefan Bodewig (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14386458#comment-14386458 ] 

Stefan Bodewig commented on LOG4NET-344:
----------------------------------------

For some reason we've all forgotten there already is an AsyncAppender inside log4net's examples.  Furthermore there is an implementation using TPL in LOG4NET-407.

The existing example code seems to be similar to Ron's suggestion (it doesn't perform any bulk processing, but I'd rather see async and buffering/forwarding as two separate issues anyway.  Right now I'm leaning towards adding AsyncAppender to log4net's core using either the existing example code or Tom's implementation for .NET < 4.0 and the TPL version for .NET >= 4.0.

Tests would be good :-)

> Make AdoNetAppender not to stuck application process
> ----------------------------------------------------
>
>                 Key: LOG4NET-344
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-344
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Appenders
>    Affects Versions: 1.2.10
>         Environment: Windows series
>            Reporter: Tom Tang
>              Labels: patch
>             Fix For: 3.5
>
>         Attachments: AdoNetAppender.cs, AsyncForwardingAppender.cs
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The original AdoNetAppender could stuck application during log insertion.
> Because it use the sync method call to do database insert, once the DB is unavailable or table was locked.
> I change the implementation that has an inner queue inside to store the messages, and the other independent thread will be going to cunsuming the queue messages and do DB insertion.
> This implementation will not have any impact on application performance and much stable.
> Trade off: Once the queue max buffer was full, the later coming log message would be ignored and gone forever. But log4net is not designed for guarantee delivery in purpose, right? So it's not big deal at all. :)  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)