logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Tang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck application process
Date Thu, 31 May 2012 11:51:22 GMT

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

Tom Tang commented on LOG4NET-344:

Hi, Dominik:

Thanks for your quick reply.
1] Unfortunately, BufferingAppenderSkeleton is not using async way to consume these messages.

    It stored them and flush them once the counter reach the size limit. All are in sync invocation.
That's why I'm headache now.
    The most simple way to prove, use AdoNetAppender to write database log, then begin an
uncommitted updating transaction on the table, you will find your application suspend outside
till the execute timeout(30 sec in default).
    And every [buffersize] log invocation, your application will hang 30 sec till you end
up the transaction.

2] Got you. I can update the implementation by this.

3] My implementation won't have OutOfMemoryException issue., due to I drop these LoggingEvent
objects once if my inner queue is full. If there's no size limit design in my inner queue,
your concern could be true. 
    But you're right with the crash log could be missed from persistent log in DB during the
sleep duration.

4] Create a subclass for such implementation is now what my workaround is, but I'm not satisfied
with this situation. It makes our cross teams developers have to reference an external DLL
or source code for the subclass implementation. I would like if we can give one more parameter
to switch the sync/async mode in AdoNetAppender? If there's no such new parameter in configuration,
AdoNetAppender can do what it's doing now as usual.

About 3] again. I may not full-understand your design suggestion about using 2 queues.
> 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
>   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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message