On 20 February 2018 at 11:32, Benjamin Jaton <benjamin.ja...@gmail.com>

> In the case of a multi threaded application, not async, would it be
> possible to have avoid the potential mis ordering by having a 500ms (for
> example) window of collection for log events, and instead of logging the
> next log event in the queue, the logic would be search for the oldest event
> in the queue and log it.

So like a priority queue/heap, where ordering is determined by log event
timestamp? Sounds like that could make a neat appender meta plugin (meta
like the routing appender, though perhaps it could be a plugin specific to
async loggers like a policy/strategy type class), though it may be overkill
for most scenarios unless log files must absolutely be done in exact
timestamp order. Plus, if you're using async logging, this could
potentially have a noticeable affect on performance (e.g., we could use
BlockingPriorityQueue, though now we cancel out the performance gains of
avoiding a blocking queue; or we could use a persistent data structure, but
then we lose GC-free logging, though chances are that BPQ already causes
garbage as it is).

The tl;dr of this is that if you're logging synchronously and want events
in order, fitting in a PriorityQueue or BlockingPriorityQueue (depending on
single or multi producer scenarios respectively) would be the general way
to go, though it's not ideal for performance probably.

Matt Sicker <boa...@gmail.com>

Reply via email to