3 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Peijen Lin commented  ·  April 17, 2013 10:52 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I am currently using TraceSource for logging and have implemented a queued TraceListener. It uses a ConcurrentQueue to store log message and do a batch flush when queue reaches a configurable value. We are able to reduce the time significantly (don't have the number on hand but it's at least 75% reduction).

  Maybe a similar implementation would be great. The problem with my implementation is I didn't bother to implement rollover, cleanup, multi-process write and other stuff.

• Steve Powell commented  ·  April 10, 2013 12:20 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I too would love a buffered logging listener (hence async by nature) or a buffer I could wrap around any listener before the listener instance fires. I've implemented my own buffered listener at at least 3 different Fortune 500 companies so it seems to be a common need. NLog has a simple bufferning mechanism. Re data loss: has not been a significant issue and a risk that I am willing to take; since it is logging after all.

• glenatron commented  ·  January 31, 2013 2:33 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I am currently using Enterprise Library 5 for a degree of async logging by pushing messages through an MSMQ and then collecting them from there into the database. However it would be nice to be able to cut out the middle man in this situation.