I could be wrong, but I think the performance impact would be prohibitive. Instead I would suggest doing some post-processing on the log files.
(Shameless plug) Every java main() method deserves http://picocli.info > On Feb 22, 2018, at 2:14, Benjamin Jaton <[email protected]> wrote: > > Ah thanks for the thoughts /feedback. I was just curious to know what you > would think of such a design for apps that needs to guaranty ordering. > Thanks! > >> On Tue, Feb 20, 2018 at 2:36 PM, Remko Popma <[email protected]> wrote: >> >> 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 http://picocli.info >> >>> On Feb 21, 2018, at 7:15, Matt Sicker <[email protected]> wrote: >>> >>> On 20 February 2018 at 11:32, Benjamin Jaton <[email protected]> >>> 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 <[email protected]> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
