On Wed, Feb 21, 2018 at 10:41 AM, Remko Popma <remko.po...@gmail.com> wrote:
> 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. > I agree. Gary > > (Shameless plug) Every java main() method deserves http://picocli.info > > > On Feb 22, 2018, at 2:14, Benjamin Jaton <benjamin.ja...@gmail.com> > 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 <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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
