> a jerk move, but they started it with this weird release model I think that's the only option given their release model and lack of backporting bugfixes to the latest ea. Either you run tip of the spear, pay them for bugfixes, or run what's effectively an unsupported LTS in the form of ea.
So doesn't seem like a jerk move to me as much as it seems like an eventuality of their release model. On Wed, Sep 18, 2024, at 7:02 PM, Nate McCall wrote: > I feel like a group of us discussed this IRL a bit at ApacheCon in Vegas ~ > 2019 maybe? Anyhoo, the tidbit sticking in my mind was someone explaining the > string operations overhead in the JVM of log concatenation vs slapping binary > to CQ’s off heap-and-append operation was substantial. > > We could hostile fork and bring the bits we use in tree (a jerk move, but > they started it with this weird release model). I’d rather avoid this, but > it’s an option seeing as how it’s ASFv2. > > On Thu, 19 Sep 2024 at 5:08 AM, Jeremiah Jordan <jeremiah.jor...@gmail.com> > wrote: >> >>> When it comes to alternatives, what about logback + slf4j? It has appenders >>> where we want, it is sync / async, we can code some nio appender too I >>> guess, it logs it as text into a file so we do not need any special tooling >>> to review that. For tailing which Chronicle also offers, I guess "tail -f >>> that.log" just does the job? logback even rolls the files after they are >>> big enough so it rolls the files the same way after some configured period >>> / size as Chronicle does (It even compresses the logs). >> >> Yes it was considered. The whole point was to have a binary log because >> serialization to/from (remember replay is part off this) text explodes the >> size on disk and in memory as well as the processing time required and does >> not meet the timing requirements of fqltool. >> >> -Jeremiah
