On 20 February 2018 at 11:32, Benjamin Jaton <benjamin.ja...@gmail.com> 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 <boa...@gmail.com>
