[
https://issues.apache.org/jira/browse/LOG4NET-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657612#action_12657612
]
Ron Grabowski commented on LOG4NET-190:
---------------------------------------
I wouldn't recommending using the AsyncAppender code directly. I'd always
envisioned a buffering appender sitting in front of that so logging events were
dispatched to the ThreadPool only when the buffer filled. Ayende created an
interesting async appender for database inserts a while ago with a minimal
amount of locking (just two quick lock calls):
https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-commons/Rhino.Commons/Logging/AsyncBulkInsertAppender.cs
The BatchWaitTime property probably needs to be expressed as a int so it can be
set via the xml config file. The 'else if' block in Activate was a bit
confusing...is there a cleaner way to write this:
// copy items from the old queue to the new queue (might have different size)
newQueue[(_head + i)%_queueCapacity] = _queue[(_head + i)%oldCapacity];
In the Append method you'll probably need to Fix each of the LoggingEvent
objects:
// Derive class expects fixed events
foreach (LoggingEvent loggingEvent in loggingEvents)
{
loggingEvent.Fix = this.Fix;
}
because they're going to be processed on another thread and you want to record
the information from the thread that they originated from.
Does the Join call in OnClose wait forever for the background thread to
finish? Should a reasonable timeout be set?
I kind of envisioned an async appender extending BufferingForwardingAppender so
it could take advantage of the Evaluator functionality: immediately flush if a
WARN or higher message is encountered no matter how many items are currently
buffered.
Would it be better for the locking code for the queue to be in its own class,
LockingQueue, to keep the appender itself less cluttered and allow for the
locking internals to be improved over time without changing the appender
itself? What happens when the queue is full? Does the appender block, throw
away LoggingEvents, or grow its internal LoggingEvents array?
Thanks for the patch! I must admit that I'm not a multi-threading ninja so any
contributions with an async appender are welcomed.
> [Patch] Need true asynchronous appender
> ---------------------------------------
>
> Key: LOG4NET-190
> URL: https://issues.apache.org/jira/browse/LOG4NET-190
> Project: Log4net
> Issue Type: New Feature
> Components: Appenders
> Affects Versions: 1.2.11
> Environment: DotNet
> Reporter: Kenneth Xu
> Fix For: 1.2.11
>
> Attachments: AsyncAppenderPatch.patch
>
>
> The AsycAppender in the example uses .Net ThreadPool, a busy logging system
> can quickly fill up the queue of the work item. As the ThreadPool is also
> used by the framework itself, using it for async logging is inappropriate.
> Thus, a true asynchronous appender with its dedicated queue and thread has
> been asked by the community many times.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
