Implement AsyncAppender

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Duplicate
  • Affects Version/s: unspecified
  • Fix Version/s: 0.9.10
  • Component/s: Other
  • Labels:
    None
  • Environment:
    Operating System: Windows
    Platform: PC
  • Bugzilla Id:
    55

Description

Being able to write log files in the background is a requirement for production deployments of anything we would write on top of logback.

Bonus points for including a feature to periodically flush the output.

Issue Links

depends on

Improvement - An improvement or enhancement to an existing feature or task. LBCORE-48 compression should happen in a separate thread

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Mike Mansell added a comment -
Has anyone started looking at this bug? I'm not as concerned about the log append being async but I'm using a rolling file appender with compression and I think during log rotation I'm seeing everything block while the rotation / compression happens.



Show
Mike Mansell added a comment - Has anyone started looking at this bug? I'm not as concerned about the log append being async but I'm using a rolling file appender with compression and I think during log rotation I'm seeing everything block while the rotation / compression happens.
Hide
Permalink
Ceki added a comment -
Mike,

Looking at the rollover code, logging stops as long as compression is in progress (as you rightly observe). Actually, I think it is possible to get around this by performing the compression in another thread after renaming happens.

For your particular case, there is no need for AsyncAppender.
Show
Ceki added a comment - Mike, Looking at the rollover code, logging stops as long as compression is in progress (as you rightly observe). Actually, I think it is possible to get around this by performing the compression in another thread after renaming happens. For your particular case, there is no need for AsyncAppender.
Hide
Permalink
Ceki Gulcu added a comment - - edited
I am closing this issue as the requirement is not actually AsyncAppender but a way to do compression asynchronously, which is very different.

I invite those really interested in AsyncAppender to create a separate issue.
Show
Ceki Gulcu added a comment - - edited I am closing this issue as the requirement is not actually AsyncAppender but a way to do compression asynchronously, which is very different. I invite those really interested in AsyncAppender to create a separate issue.
Hide
Permalink
Wascally Wabbit added a comment -
This issue has been closed but the ORIGINAL poster's request for AsyncAppender was not addressed (the second poster linked generic AsyncAppender to compression for whatever reason and looks like Ceki was addressing this poster when he closed the issue).

At work,I was *this* (little space) close to recommending a migration from log4j/jul/jcl to slf4j+logback but the lack of an AsyncAppender as the original poster noted is a significant issue for use in production. We have many large applications (by usage) and custom log4j appenders that will migrate beautifully *iff* we also had AsyncAppender.

So why the lack of an async decorator? Does anyone really use custom database/jms appenders without this in production for high volume?

At this point, even if you've got something "internal" I'll take it!

Thanks,
WW
Show
Wascally Wabbit added a comment - This issue has been closed but the ORIGINAL poster's request for AsyncAppender was not addressed (the second poster linked generic AsyncAppender to compression for whatever reason and looks like Ceki was addressing this poster when he closed the issue). At work,I was *this* (little space) close to recommending a migration from log4j/jul/jcl to slf4j+logback but the lack of an AsyncAppender as the original poster noted is a significant issue for use in production. We have many large applications (by usage) and custom log4j appenders that will migrate beautifully *iff* we also had AsyncAppender. So why the lack of an async decorator? Does anyone really use custom database/jms appenders without this in production for high volume? At this point, even if you've got something "internal" I'll take it! Thanks, WW
Hide
Permalink
Ceki Gulcu added a comment -
Hello Wascally,

The original request was more about file compression than AsyncAppender. In order to avoid confusing the two issues, may I please ask you to create a separate *new* issue asking for AsyncAppender?
Show
Ceki Gulcu added a comment - Hello Wascally, The original request was more about file compression than AsyncAppender. In order to avoid confusing the two issues, may I please ask you to create a separate *new* issue asking for AsyncAppender?

People

  • Assignee:
    Logback dev list
    Reporter:
    Anders Wallgren
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: