Is there any reason why the number of ring buffers and the number of their entries should match?
Gary On Mon, Nov 25, 2019 at 12:13 AM <hmijail+lo...@gmail.com> wrote: > I'm sympathetic to the anxiety for getting everything designed right, but > at some point it's better to stop pondering possibilities and just get > something working ;). > > I have some experience in this kind of design space but 0 knowledge about > log4j internals, and my totally unrequested suggestion is that, since > probably simplicity / speed / garbage-free operation are valued, I'd go for > N ring buffers of N entries each, with N defined and everything allocated > at start-up time. Every new trigger swaps in a new ring buffer to be used > while the previous ring/s get drained. For the extreme case of multiple > triggers coming in a burst, you'd be swapping rings at every entry. Rings > are emptied until the triggering entry, it's the simplest (or only?) way to > have a well-defined result. > > For my immediate needs I guess I'll have to make do with some external > post-processing... > Thank you! > > Best, > --- Horacio > > > On 25 Nov 2019, at 2:47 pm, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > See https://issues.apache.org/jira/browse/LOG4J2-1137 < > https://issues.apache.org/jira/browse/LOG4J2-1137>. It has been on my > todo list for quite a while. What I plan on implementing is a > “TriggeringAppender” where you can attach a custom trigger or triggers to > cause the event to fire. The problem I haven’t figure out is in capturing > and emitting the events. It should use a ring buffer but when the event > fires you don’t want to cause a pause while all the events are logged so > you would probably need more than one RingBuffer. And what if the trigger > fires again before the first trigger has logged all the events? I want to > figure out this behavior before I start writing it and I just haven’t had > the time to design it. > > > > Ralph > > > >> On Nov 24, 2019, at 8:52 PM, hmijail+lo...@gmail.com wrote: > >> > >> Hi all, > >> > >> I am looking for a way to do a lookahead regex filter: ignore log > lines, unless there is a match with a given pattern, in which case the N > previous lines should be stored. > >> > >> The RegexFilter filter doesn't seem to support this, or at least I > haven't managed to make it work. (I would have been surprised to find it > worked anyway) > >> > >> Any tip on how to do this kind of thing? > >> > >> Best, > >> --- Horacio > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >> > >> > > > >
