Fine. I’m convinced. Double checked the patch and I was wrong about the config option. Thanks for the clarification. Patch looks like a nice workaround the problem. Approved.
Need another approval and it’s ready to go unless Damien wants to rebase it first. Regards, Andor > On Aug 13, 2026, at 04:44, Dmitrii Duzhinskii <[email protected]> wrote: > > Hi all, > > A few clarifications on the patch: > > 1. #1716 doesn't introduce a new config option. Making the limit > independently configurable was discussed, > and ztzg explained why it isn't needed. it simply tracks jute.maxbuffer: > https://github.com/apache/zookeeper/pull/1716#issuecomment-866691807 > So there is nothing to deprecate later: when CloseSessionTxn goes away, the > check goes away with it. > The point of the patch is crash protection, not a new mechanism. > > 2. What it does introduce is a new error code, which old clients won't > recognize. > That's a real trade-off, but the alternative is the whole cluster going down. > An unknown error on the one misbehaving client is harmless in comparison. > > 3. On the -1: @eolivelli seems to have stepped back from it in Aug 2024. > "I think that we can resume this patch ... I don't have a better proposal at > the moment": > https://github.com/apache/zookeeper/pull/1716#issuecomment-2296414881 > > On process: the 2024 revival already turned into the non-fuzzy snapshot > discussion and then went quiet for lack of participants, > while the production problem stayed. I'd suggest keeping this thread to the > blockers for merging the fix - a broader discussion will most likely end the > same way. > > On ZOOKEEPER-4874 being small: technically perhaps, but conceptually it > reworks durability, > and I'd wait a few months after such a release before running it in > production anyway, so it can't be the near-term answer. > > Andor, as for our numbers and use case: I'd rather not build the case on our > specifics. Sharing details would have to go through internal approval, and > that takes time. > What I can say: I run ZooKeeper for many products in a large company, two > independent products hit this issue, and there are other reports of it too. > We used to run an old internally patched version and recently moved to the > latest open-source release, wanting to stay with the community, and this is > the first thing we hit. Let's focus on stopping the production crashes. > > Dmitrii > >> Hi all, >> >> We've hit ZOOKEEPER-4306 (CloseSessionTxn exceeding jute.maxbuffer takes >> down the whole ensemble) twice in production, in two independent deployments >> — I've also left a comment on the JIRA. >> >> PR #1716 has been open since 2021 and was rebased in Oct 2024 with a >> branch-3.9 backport (#2201), but both seem to have stalled since. >> >> Is anything still blocking them? If the 2021 review comments are the >> remaining concern, we'd be glad to help address them >> >> https://issues.apache.org/jira/browse/ZOOKEEPER-4306 >> https://github.com/apache/zookeeper/pull/1716 >> https://github.com/apache/zookeeper/pull/2201
