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 >
