Hi Lari > I disagree on making a change to the Pulsar 4.0 default value since Pulsar 4.0 has already been released.
Since PR #9292 introduced a regression, we'd better make it the default carefully. We can change it as default-enabled at the following feature releases On Mon, Dec 30, 2024 at 4:38 AM Lari Hotari <lhot...@apache.org> wrote: > I disagree on making a change to the Pulsar 4.0 default value since Pulsar > 4.0 has already been released. > Instead of changing the default for 4.0.2, it's better to guide users to > set this to false if they'd like to upgrade and later downgrade without > losing individual ack information. > We should have a separate upgrade guide where this is explained. > In general users will benefit of the PR-9292 behavior so there shouldn't > be a reason to postpone this for 5.0. > > -Lari > > On 2024/12/24 02:16:26 Yubiao Feng wrote: > > Hi Penghui > > > > > And for the feature version release, user should also able to downgrade > > from 4.x to 3.x without any compatibility issues, so for any feature > > releases between 4.0 to 5.0 should also disable it by default. > > > Cherry-pick to 3.0 sounds good to me with disabled by default, but we > need > > to highlight in the documentation and configuration file that enabling > this > > feature will break the backward compatibility if user wants to rollback > to > > 2.11. > > > > Agree. > > > > On Tue, Dec 24, 2024 at 1:50 AM PengHui Li <peng...@apache.org> wrote: > > > > > Hi Yubiao, > > > > > > Thanks for driving this fix. Based on the LTS version strategy, user > should > > > able to upgrade from 3.0 to 4.0 without and compatibility issues and > > > downgrade from 4.0 to 3.0 without any compatibility issues. > > > > > > > > > > https://pulsar.apache.org/contribute/release-policy/#compatibility-between-releases > > > > > > So, we should also disable it by default in 4.0, but we can consider to > > > make it as default in 5.0. > > > > > > And for the feature version release, user should also able to downgrade > > > from 4.x to 3.x without any compatibility issues, so for any feature > > > releases between 4.0 to 5.0 should also disable it by default. > > > > > > Cherry-pick to 3.0 sounds good to me with disabled by default, but we > need > > > to highlight in the documentation and configuration file that enabling > this > > > feature will break the backward compatibility if user wants to > rollback to > > > 2.11. > > > > > > Regards, > > > Penghui > > > > > > On Mon, Dec 23, 2024 at 01:43 Baodi Shi <ba...@apache.org> wrote: > > > > > > > +1 #9292 > > > > > > > > > > > > Thanks, > > > > Baodi Shi > > > > > > > > Yubiao Feng <yubiao.f...@streamnative.io.invalid> 于2024年12月23日周一 > > > 11:56写道： > > > > > > > > > > Hi all > > > > > > > > > > ## Background > > > > > PR #9292 improved the serialization for cursor metadata, which > reduces > > > > > Young GC and makes Pulsar persist more ack records of the cursor, > but > > > it > > > > > also caused two issues below > > > > > > > > > > **Issue-1: Downgrade compatibility issue** > > > > > - It changed the default implementation of cursor serialization. > > > > > - Users can not rollback to `3.0.x` once upgraded to `4.0.x` > because > > > > > `release:3.0.x` does not contain the deserialization introduced by > it, > > > > > > > > > > **Issue-2: It is in conflict with another config > > > > > unackedRangesOpenCacheSetEnabled** > > > > > - If users disabled `unackedRangesOpenCacheSetEnabled`, the cursor > ack > > > > > records will always be lost. see details > > > > > https://github.com/apache/pulsar/pull/23759 > > > > > > > > > > ## Goal > > > > > > > > > > - Add an optional config to disable the feature that compresses > cursor > > > > > metadata, which was contributed by #9292 > > > > > > > > > > ``` > > > > > cursorMetadataSerialization=V2 > > > > > ``` > > > > > > > > > > - Since it reduced Young GC, I want to cherry-pick it into > branch-3.0 > > > > with > > > > > a disabled default value. > > > > > > > > > >
