To come back to our questions, what version of Log4j are you using?
Are you seeing log entries that are out of order in the same thread? 

(Shameless plug) Every java main() method deserves

> On Feb 21, 2018, at 7:15, Matt Sicker <> wrote:
> On 20 February 2018 at 11:32, Benjamin Jaton <>
> wrote:
>> 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 <>

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to