Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Benedict]

No, there is another perfectly sensible option: just implement a simple serialisation format ourselves. I am against forking their code; that is a much higher maintenance burden than just writing something simple ourselves. We’ve spent longer collectively discussing and maintaining this dependency than it would take to implement the features we use. I still have not heard a compelling reason we adopted it as a dependency in the first place. On 19 Sep 2024, at 16:26, Josh McKenzie <jmcken...@apache.org> wrote:  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