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 <remko.po...@gmail.com> 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 <boa...@gmail.com> wrote: > > > > 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> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
