In that case, you could log to a file and have a separate process collect and sort logs, or you can log directly to a networked appender and take the performance hit (which is probably higher than a heap-based approach).
On 21 February 2018 at 11:41, Remko Popma <[email protected]> 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. > > (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] > > -- Matt Sicker <[email protected]>
