[logback-dev] [JIRA] Issue Comment Edited: (LBCLASSIC-176) Asynchronous File appender

[Ceki (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11469#action_11469 ] 

Ceki edited comment on LBCLASSIC-176 at 12/21/09 9:54 AM:
----------------------------------------------------------

AsyncAppender presents several interesting questions. One of them is what happens when the rate of service of the queue is slower than arrival the rate, that is when logs are arrive faster than they can be written. If this happens for any lengthy period of time, then events will be accumulated in the queue and eventually result in an OutOfMemoryException. Thus, AsyncAppender MUST have a bounded buffer.

If non-blocking behaviror is desired, then, assuming the buffer is full, new events must be dropped. If events cannot be dropped then the caller will be blocked until room in the buffer is freed. The latest versions of log4j can drop events if configured to do so. I call this the (optionally) lossy AsyncAppender.

We can have a more refined behavior prioritizing events depending on the level of incoming events. For example, for buffer size B, if occupancy is below 2/3, then accept all events, if the occupancy rate is above 2/3, then drop events of level TRACE, DEBUG, INFO, accepting events of level WARN and ERROR. If the occupancy rate is 100%, i.e. if there are B events in the buffer, then drop events of level TRACE, DEBUG and INFO and for events of level WARN and ERROR block until room becomes availalbe. I think such a policy strikes a very good balance between availability and performance. As in log4j, lossiness should be optional/configurable.

Anyway, thank you for both for your contributions. Would you be interested in coding the policy outlined above?



      was (Author: ceki at qos.ch):
    AsyncAppender presents several interesting questions. One of them is what happens when the rate of service of the queue is slower than arrival the rate, that is when logs are arrive faster than they can be written. If this happens for any lengthy period of time, then events will be accumulated in the queue and eventually result in an OutOfMemoryException. Thus, AsyncAppender MUST have a bounded buffer.

If non-blocking behaviror is desired, then, assuming the buffer is full, new events must be dropped. If events cannot be dropped then the caller will be blocked until room in the buffer is freed. The latest versions of log4j can drop events if configured to do so. I call this the (optionally) lossy AsyncAppender.

We can have a more refined behavior prioritizing events depending on the level of incoming events. For example, for buffer size B, if occupancy is below 2/3, then accept all events, if the occupancy rate is above 2/3, then drop events of level TRACE, DEBUG, INFO, accepting events of level WARN and ERROR. If the occupancy rate is 100%, i.e. if
there are B events in the buffer, then drop events of level TRACE, DEBUG and INFO and for events of level WARN and ERROR block until room becomes availalbe. I think such a policy strikes a very good balance between availability and performance. As in log4j, lossiness should be optional/configurable.

Anyway, thank you for both for your contributions. Would you be interested in coding the policy outlines above?


  
> Asynchronous File appender
> --------------------------
>
>                 Key: LBCLASSIC-176
>                 URL: http://jira.qos.ch/browse/LBCLASSIC-176
>             Project: logback-classic
>          Issue Type: New Feature
>          Components: appender
>            Reporter: Konstantin Alexandrov
>            Assignee: Logback dev list
>         Attachments: asynch.zip, AsynchRollingFileAppender.java, AsynchRollingFileAppender.java
>
>
> I implement asynch rolling file appender for my application, the reason is to decrease logging time in time critical part of application.
> This logger save up to 2 time logging time and decrease total IO concurrency. If you found this appender usable, then please include
> to distribution.
> Thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira