[
https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288947#comment-13288947
]
Ron Grabowski commented on LOG4NET-344:
---------------------------------------
When I posted a link to AsyncBulkInsertAppender.cs I wanted the focus to be
more on the threading code rather than limiting it to just BulkInsert
operations.
Taking the interesting parts AsyncBulkInsertAppender.cs and extending
BufferingForwardingAppender gives us async support in about 30 lines of code:
//
https://github.com/lorenzomelato/rhino-commons/blob/master/Rhino.Commons/Logging/AsyncBulkInsertAppender.cs
protected override void SendBuffer(LoggingEvent[] events)
{
ThreadPool.QueueUserWorkItem(delegate
{
lock (syncLock)
{
eventsList.AddLast(events);
if (anotherThreadAlreadyHandlesLogging)
return;
anotherThreadAlreadyHandlesLogging = true;
}
while (true)
{
LoggingEvent[] current;
lock (syncLock)
{
if (eventsList.Count == 0)
{
anotherThreadAlreadyHandlesLogging = false;
return;
}
current = eventsList.First.Value;
eventsList.RemoveFirst();
}
base.SendBuffer(current);
}
});
}
Some suggestions for improving your AsyncForwardingAppender...change the
variable names that reference "File" and make the buffer size settable. I don't
see the benefit of using dedicated thread in this case because you aren't
giving the thread a chance to shutdown and process its messages when the
repository shutsdown. Modern CLRs have lots of threads available in the pool,
just use one of those.
> 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 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
