Agree with Benedict's proposal here. In circumstances when I've needed to capture and work with FQL, I've
found it cumbersome to work with Chronicle. The dial-home functionality and release process changes put it
over the top for me. – Scott On Sep 19, 2024, at 8:40 AM, Josh McKenzie <jmcken...@apache.org> wrote:
there is another perfectly sensible option My apologies; I wasn't clear. If we choose to continue to use
chronicle queue , what I enumerated was the only logical option I saw for us. Altogether I think we should
just move away from the library as you've laid out here Benedict. On Thu, Sep 19, 2024, at 11:34 AM,
Benedict wrote: 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
