On Wed, Feb 21, 2018 at 12:03 PM, Matt Sicker <boa...@gmail.com> wrote:
> 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). > That what databases are good at, with an index on a timestamp column. Gary > > On 21 February 2018 at 11:41, 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. > > > > (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 > > > > > > > -- > Matt Sicker <boa...@gmail.com> >
