Join 34,000+ subscribers and receive articles from our
blog about software quality, testing, QA and security.

Flush BackLog


Hi Tobias,

there is some method with SmartInspect Framework to flush the backlog queue ? At the end of program, before exit i write some status information but i have to genrate and error to flush them.

On the other side can I disable backlog on the fly. Old packets are not important for me so I can clear queue, disable backLog and write status information in normal way.

Ing Giuseppe Monteleone

P.S: about prints: I agree with you they aren’t orrible, just basic ;-)))


Hello Giuseppe,

there is currently no way to manually flush or temporarily disable the backlog queue functionality of a connection but I added it to the feature request list. Thanks for the suggestions.


Is there now the possibility to flush the backlog?

I did enable the backlog functionality, but do have the problem that the remaining log entries in the Backlog will not get send via Tcp. A work around is to send an Error before calling Dispose, but this is not nice, because I do have an error in the log afterwards.

Thanks and regards


Hello Jan,

Thanks for your posting! The backlog was designed for the use case of minimal error logging and it can only be triggered by an error (or the log level you configured). So, sending an error log entry is the recommended way to clear the backlog if you want the last chunk of log entries in the log even if you haven’t logged an actual error.

An alternative might be to use the memory protocol and then flush this explicitly before exiting your application.

I hope this helps!



Thanks for your reply!

Maybe I did not find the proper protocol then. For us the use case is that we like to monitor several instances of our application with the console. The instances are distributed over several nodes and can be accessed via Tcp.

So I guess using memory protocol is not an option. Is there any other option. Based on the discussion here I came to the conclusion that the router is also not what we need and want.

Thank you so much


Hi Jan,

For production system and monitoring, we would recommend using the file protocol and regular log files instead. This does not have the performance implications of the TCP or named pipe protocols so you wouldn’t necessarily need to use the backlog feature at all. Would this also work for you?