[LAZY CONSENSUS] Sending 2.6 release line to EOF

[Enrico Olivelli]

This thread is now to moving branch-2.6 (the Pulsar 2.6 release line)
to End-Of-Life status

What EOL means here:
- No more releases, even for security bugs
- No cherry-picks to branch-2.6

We will apply the Lazy Consensus rules
https://www.apache.org/foundation/glossary.html#LazyConsensus

If no-one objects within 72 hours I will send an official announcement
of the EOL status of 2.6.

Enrico


Il giorno mar 4 gen 2022 alle ore 06:04 Michael Marshall
 ha scritto:
>
> I agree with Dave. Lazy consensus gives us exactly what we need: to
> know if someone would like branch-2.6 to stay alive. If no one
> responds that they need it within the time period, then no one needs
> it.
>
> PIP 47 briefly mentions our EOL policy, but the policy doesn't cover
> our current case where we released fewer than 4 minor versions in a
> year. I think we'd benefit from clarifying and improving our
> documentation for our EOL policy.
>
> > This project VOTEs on more things than any Apache project I’ve been 
> > involved with during the last 14 years.
>
> The new PIP process, with its increased purview, has increased the
> number of votes. I have appreciated the increased development
> discussion on the ML, but maybe the discussions (especially the ones
> that look like votes) and then the subsequent votes are leading to the
> high vote volume.
>
> We could update the PIP process so that DISCUSSIONS without any
> pushback during a certain time period do not need VOTES.
>
> Thanks,
> Michael
>
>
> On Mon, Jan 3, 2022 at 6:00 PM Dave Fisher  wrote:
> >
> > This project VOTEs on more things than any Apache project I’ve been 
> > involved with during the last 14 years.
> >
> > For most projects lazy consensus applies: 
> > https://www.apache.org/foundation/glossary.html#LazyConsensus
> >
> > We also tend to “vote” during discussions which does not really advance a 
> > conversation.
> >
> > If we want to have a VOTE then there are good reasons to start it NOW.
> >
> > All the Best,
> > Dave
> >
> > > On Jan 3, 2022, at 3:48 PM, Sijie Guo  wrote:
> > >
> > > Agree to have a vote to keep a record.
> > >
> > > - Sijie
> > >
> > > On Mon, Jan 3, 2022 at 3:40 PM 陳智弘  wrote:
> > >
> > >> I think having a vote and quickly announce the EOF of 2.6.x will be 
> > >> better
> > >> to the community.
> > >>
> > >>
> > >> Dave Fisher  於 2022年1月4日 週二 06:06 寫道：
> > >>
> > >>> I don’t think we need a VOTE. Let’s do this by LAZY CONSENSUS.
> > >>>
> >  On Jan 3, 2022, at 10:05 AM, Enrico Olivelli 
> > >>> wrote:
> > 
> >  Hello,
> >  We are no more cutting releases out of branch-2.6
> > 
> >  We must declare 2.6 EOF.
> > 
> >  IIUC there is no process established for this at the moment in the
> > >> Pulsar
> >  project.
> > 
> >  So for this time I will call out a VOTE next week, as we did not cut
> >  releases for a few important bugs.
> > 
> >  Thoughts?
> > 
> >  Enrico
> > >>>
> > >>>
> > >>
> >

Re: [VOTE] PIP-121: Pulsar cluster level auto failover on client side

[Enrico Olivelli]

+1 (binding)

Enrico

Il giorno lun 10 gen 2022 alle ore 07:45 Hang Chen
 ha scritto:
>
> This is the voting thread for PIP-121. It will stay open for at least 48
> hours.
>
> https://github.com/apache/pulsar/issues/13315
>
> Pasted below for quoting convenience.
>
> -
> ### Motivation
> We have geo-replication to support Pulsar cluster level failover. We
> can set up Pulsar cluster A as a primary cluster in data center A, and
> setup Pulsar cluster B as backup cluster in data center B. Then we
> configure geo-replication between cluster A and cluster B. All the
> clients are connected to the Pulsar cluster by DNS. If cluster A is
> down, we should switch the DNS to point the target Pulsar cluster from
> cluster A to cluster B. After the clients are resolved to cluster B,
> they can produce and consume messages normally. After cluster A
> recovers, the administrator should switch the DNS back to cluster A.
>
> However, the current method has two shortcomings.
> 1. The administrator should monitor the status of all Pulsar clusters,
> and switch the DNS as soon as possible when cluster A is down. The
> switch and recovery is not automatic and recovery time is controlled
> by the administrator, which will put the administrator under heavy
> load.
> 2. The Pulsar client and DNS system have a cache. When the
> administrator switches the DNS from cluster A to Cluster B, it will
> take some time for cache trigger timeout, which will delay client
> recovery time and lead to the product/consumer message failing.
>
> ### Goal
> It's better to provide an automatic cluster level failure recovery
> mechanism to make pulsar cluster failover more effective. We should
> support pulsar clients auto switching from cluster A to cluster B when
> it detects cluster A has been down according to the configured
> detecting policy and switch back to cluster A when it has recovered.
> The reason why we should switch back to cluster A is that most
> applications may be deployed in data center A and they have low
> network cost for communicating with pulsar cluster A. If they keep
> visiting pulsar cluster B, they have high network cost, and cause high
> produce/consume latency.
>
> In order to improve the DNS cache problem, we should provide an
> administrator controlled switch provider for administrators to update
> service URLs.
>
> In the end, we should provide an auto service URL switch provider and
> administrator controlled switch provider.
>
> ### Design
> We have already provided the `ServiceUrlProvider` interface to support
> different service URLs. In order to support automatic cluster level
> failure auto recovery, we can provide different ServiceUrlProvider
> implementations. For current requirements, we can provide
> `AutoClusterFailover` and `ControlledClusterFailover`.
>
>  AutoClusterFailover
> In order to support auto switching from the primary cluster to the
> secondary, we can provide a probe task, which will probe the activity
> of the primary cluster and the secondary one. When it finds the
> primary cluster failed more than `failoverDelayMs`, it will switch to
> the secondary cluster by calling `updateServiceUrl`. After switching
> to the secondary cluster, the `AutoClusterFailover` will continue to
> probe the primary cluster. If the primary cluster comes back and
> remains active for `switchBackDelayMs`, it will switch back to the
> primary cluster.
> The APIs are listed as follows.
>
> In order to support multiple secondary clusters, use List to store
> secondary cluster urls. When the primary cluster probe fails for
> failoverDelayMs, it will start to probe the secondary cluster list one
> by one, once it finds the active cluster, it will switch to the target
> cluster. Notice: If you configured multiple clusters, you should turn
> on cluster level geo-replication to ensure the topic data sync between
> all primary and secondary clusters. Otherwise, it may distribute the
> topic data into different clusters. And the consumers won’t get the
> whole data of the topic.
>
> In order to support different authentication configurations between
> clusters, we provide the authentication relation configurations
> updated with the target cluster.
>
> ```Java
> public class AutoClusterFailover implements ServiceUrlProvider {
>
>private AutoClusterFailover(AutoClusterFailoverBuilderImpl builder) {
> //
> }
>
> @Override
> public void initialize(PulsarClient client) {
> this.pulsarClient = client;
>
> // start to probe primary cluster active or not
> executor.scheduleAtFixedRate(catchingAndLoggingThrowables(() -> {
> // probe and switch
> }), intervalMs, intervalMs, TimeUnit.MILLISECONDS);
>
> }
>
> @Override
> public String getServiceUrl() {
> return this.currentPulsarServiceUrl;
> }
>
> @Override
> public void close() {
> this.executor.shutdown();
> }
>
> // probe pulsar cluster available
> private boolea

Re: [VOTE] PIP-122: Change loadBalancer default loadSheddingStrategy to ThresholdShedder

[Enrico Olivelli]

+1 (binding)

Enrico

Il giorno lun 10 gen 2022 alle ore 07:47 Hang Chen
 ha scritto:

>
> This is the voting thread for PIP-122. It will stay open for at least 48
> hours.
>
> https://github.com/apache/pulsar/issues/13340
>
> Pasted below for quoting convenience.
>
> 
>
> ### Motivation
> The ThresholdShedder load balance policy since Pulsar 2.6.0 by
> https://github.com/apache/pulsar/pull/6772. It can resolve many load
> balance issues of `OverloadShedder` and works well in many Pulsar
> production clusters.
>
> In Pulsar 2.6.0, 2.7.0, 2.8.0 and 2.9.0, Pulsar's default load balance
> policy is `OverloadShedder`.
>
> I think it's a good time for 2.10 to change default load balance
> policy to `ThresholdShedder`, it will make throughput more balance
> between brokers.
>
> ### Proposed Changes
> In 2.10 release，for `broker.conf`, change
> `loadBalancerLoadSheddingStrategy` from
> `org.apache.pulsar.broker.loadbalance.impl.OverloadShedder` to
> `org.apache.pulsar.broker.loadbalance.impl.ThresholdShedder`

Re: [VOTE] PIP-121: Pulsar cluster level auto failover on client side

[PengHui Li]

+1 (binding)

Penghui

On Mon, Jan 10, 2022 at 4:38 PM Enrico Olivelli  wrote:

> +1 (binding)
>
> Enrico
>
> Il giorno lun 10 gen 2022 alle ore 07:45 Hang Chen
>  ha scritto:
> >
> > This is the voting thread for PIP-121. It will stay open for at least 48
> > hours.
> >
> > https://github.com/apache/pulsar/issues/13315
> >
> > Pasted below for quoting convenience.
> >
> > -
> > ### Motivation
> > We have geo-replication to support Pulsar cluster level failover. We
> > can set up Pulsar cluster A as a primary cluster in data center A, and
> > setup Pulsar cluster B as backup cluster in data center B. Then we
> > configure geo-replication between cluster A and cluster B. All the
> > clients are connected to the Pulsar cluster by DNS. If cluster A is
> > down, we should switch the DNS to point the target Pulsar cluster from
> > cluster A to cluster B. After the clients are resolved to cluster B,
> > they can produce and consume messages normally. After cluster A
> > recovers, the administrator should switch the DNS back to cluster A.
> >
> > However, the current method has two shortcomings.
> > 1. The administrator should monitor the status of all Pulsar clusters,
> > and switch the DNS as soon as possible when cluster A is down. The
> > switch and recovery is not automatic and recovery time is controlled
> > by the administrator, which will put the administrator under heavy
> > load.
> > 2. The Pulsar client and DNS system have a cache. When the
> > administrator switches the DNS from cluster A to Cluster B, it will
> > take some time for cache trigger timeout, which will delay client
> > recovery time and lead to the product/consumer message failing.
> >
> > ### Goal
> > It's better to provide an automatic cluster level failure recovery
> > mechanism to make pulsar cluster failover more effective. We should
> > support pulsar clients auto switching from cluster A to cluster B when
> > it detects cluster A has been down according to the configured
> > detecting policy and switch back to cluster A when it has recovered.
> > The reason why we should switch back to cluster A is that most
> > applications may be deployed in data center A and they have low
> > network cost for communicating with pulsar cluster A. If they keep
> > visiting pulsar cluster B, they have high network cost, and cause high
> > produce/consume latency.
> >
> > In order to improve the DNS cache problem, we should provide an
> > administrator controlled switch provider for administrators to update
> > service URLs.
> >
> > In the end, we should provide an auto service URL switch provider and
> > administrator controlled switch provider.
> >
> > ### Design
> > We have already provided the `ServiceUrlProvider` interface to support
> > different service URLs. In order to support automatic cluster level
> > failure auto recovery, we can provide different ServiceUrlProvider
> > implementations. For current requirements, we can provide
> > `AutoClusterFailover` and `ControlledClusterFailover`.
> >
> >  AutoClusterFailover
> > In order to support auto switching from the primary cluster to the
> > secondary, we can provide a probe task, which will probe the activity
> > of the primary cluster and the secondary one. When it finds the
> > primary cluster failed more than `failoverDelayMs`, it will switch to
> > the secondary cluster by calling `updateServiceUrl`. After switching
> > to the secondary cluster, the `AutoClusterFailover` will continue to
> > probe the primary cluster. If the primary cluster comes back and
> > remains active for `switchBackDelayMs`, it will switch back to the
> > primary cluster.
> > The APIs are listed as follows.
> >
> > In order to support multiple secondary clusters, use List to store
> > secondary cluster urls. When the primary cluster probe fails for
> > failoverDelayMs, it will start to probe the secondary cluster list one
> > by one, once it finds the active cluster, it will switch to the target
> > cluster. Notice: If you configured multiple clusters, you should turn
> > on cluster level geo-replication to ensure the topic data sync between
> > all primary and secondary clusters. Otherwise, it may distribute the
> > topic data into different clusters. And the consumers won’t get the
> > whole data of the topic.
> >
> > In order to support different authentication configurations between
> > clusters, we provide the authentication relation configurations
> > updated with the target cluster.
> >
> > ```Java
> > public class AutoClusterFailover implements ServiceUrlProvider {
> >
> >private AutoClusterFailover(AutoClusterFailoverBuilderImpl builder) {
> > //
> > }
> >
> > @Override
> > public void initialize(PulsarClient client) {
> > this.pulsarClient = client;
> >
> > // start to probe primary cluster active or not
> > executor.scheduleAtFixedRate(catchingAndLoggingThrowables(() -> {
> > // probe and switch
> > }), intervalMs, intervalMs, TimeUnit.MI

[GitHub] [pulsar-helm-chart] mkoertgen commented on issue #124: pulsar waiting to start: PodInitializing

[GitBox]

mkoertgen commented on issue #124:
URL: 
https://github.com/apache/pulsar-helm-chart/issues/124#issuecomment-1008661834


   @lhotari Good point. I will check today with upgrading to 2.7.8.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [LAZY CONSENSUS] Sending 2.6 release line to EOF

[Chris Herzog]

I agree with 2.6 EOL.

On Mon, Jan 10, 2022 at 2:35 AM Enrico Olivelli  wrote:

> This thread is now to moving branch-2.6 (the Pulsar 2.6 release line)
> to End-Of-Life status
>
> What EOL means here:
> - No more releases, even for security bugs
> - No cherry-picks to branch-2.6
>
> We will apply the Lazy Consensus rules
> https://www.apache.org/foundation/glossary.html#LazyConsensus
>
> If no-one objects within 72 hours I will send an official announcement
> of the EOL status of 2.6.
>
> Enrico
>
>
> Il giorno mar 4 gen 2022 alle ore 06:04 Michael Marshall
>  ha scritto:
> >
> > I agree with Dave. Lazy consensus gives us exactly what we need: to
> > know if someone would like branch-2.6 to stay alive. If no one
> > responds that they need it within the time period, then no one needs
> > it.
> >
> > PIP 47 briefly mentions our EOL policy, but the policy doesn't cover
> > our current case where we released fewer than 4 minor versions in a
> > year. I think we'd benefit from clarifying and improving our
> > documentation for our EOL policy.
> >
> > > This project VOTEs on more things than any Apache project I’ve been
> involved with during the last 14 years.
> >
> > The new PIP process, with its increased purview, has increased the
> > number of votes. I have appreciated the increased development
> > discussion on the ML, but maybe the discussions (especially the ones
> > that look like votes) and then the subsequent votes are leading to the
> > high vote volume.
> >
> > We could update the PIP process so that DISCUSSIONS without any
> > pushback during a certain time period do not need VOTES.
> >
> > Thanks,
> > Michael
> >
> >
> > On Mon, Jan 3, 2022 at 6:00 PM Dave Fisher  wrote:
> > >
> > > This project VOTEs on more things than any Apache project I’ve been
> involved with during the last 14 years.
> > >
> > > For most projects lazy consensus applies:
> https://www.apache.org/foundation/glossary.html#LazyConsensus
> > >
> > > We also tend to “vote” during discussions which does not really
> advance a conversation.
> > >
> > > If we want to have a VOTE then there are good reasons to start it NOW.
> > >
> > > All the Best,
> > > Dave
> > >
> > > > On Jan 3, 2022, at 3:48 PM, Sijie Guo  wrote:
> > > >
> > > > Agree to have a vote to keep a record.
> > > >
> > > > - Sijie
> > > >
> > > > On Mon, Jan 3, 2022 at 3:40 PM 陳智弘  wrote:
> > > >
> > > >> I think having a vote and quickly announce the EOF of 2.6.x will be
> better
> > > >> to the community.
> > > >>
> > > >>
> > > >> Dave Fisher  於 2022年1月4日 週二 06:06 寫道：
> > > >>
> > > >>> I don’t think we need a VOTE. Let’s do this by LAZY CONSENSUS.
> > > >>>
> > >  On Jan 3, 2022, at 10:05 AM, Enrico Olivelli  >
> > > >>> wrote:
> > > 
> > >  Hello,
> > >  We are no more cutting releases out of branch-2.6
> > > 
> > >  We must declare 2.6 EOF.
> > > 
> > >  IIUC there is no process established for this at the moment in the
> > > >> Pulsar
> > >  project.
> > > 
> > >  So for this time I will call out a VOTE next week, as we did not
> cut
> > >  releases for a few important bugs.
> > > 
> > >  Thoughts?
> > > 
> > >  Enrico
> > > >>>
> > > >>>
> > > >>
> > >
>


-- 


Chris Herzog Messaging Team | O 630 300 7718 | M 815 263 3764 |
www.tibco.com

[GitHub] [pulsar-helm-chart] lhotari merged pull request #192: [CI] Upgrade k8s to 1.18 and also upgrade helm, kind & chart releaser versions

[GitBox]

lhotari merged pull request #192:
URL: https://github.com/apache/pulsar-helm-chart/pull/192


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on a change in pull request #198: Added -Dlog4j2.formatMsgNoLookups=true to PULSAR_MANAGER_OPTS

[GitBox]

lhotari commented on a change in pull request #198:
URL: https://github.com/apache/pulsar-helm-chart/pull/198#discussion_r781545470



##
File path: charts/pulsar/templates/pulsar-manager-deployment.yaml
##
@@ -89,6 +89,8 @@ spec:
 {{- else }}
 name: "{{ template "pulsar.fullname" . }}-{{ 
.Values.pulsar_manager.component }}-secret"
 {{- end }}
+  - name: PULSAR_MANAGER_OPTS
+value: "$(PULSAR_MANAGER_OPTS) -Dlog4j2.formatMsgNoLookups=true"

Review comment:
   I'm not familiar to this type of syntax, how does 
`$(PULSAR_MANAGER_OPTS)` behave? can you point to the docs? /cc 
@michaeljmarshall 




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on a change in pull request #198: Added -Dlog4j2.formatMsgNoLookups=true to PULSAR_MANAGER_OPTS

[GitBox]

lhotari commented on a change in pull request #198:
URL: https://github.com/apache/pulsar-helm-chart/pull/198#discussion_r781547003



##
File path: charts/pulsar/templates/pulsar-manager-deployment.yaml
##
@@ -89,6 +89,8 @@ spec:
 {{- else }}
 name: "{{ template "pulsar.fullname" . }}-{{ 
.Values.pulsar_manager.component }}-secret"
 {{- end }}
+  - name: PULSAR_MANAGER_OPTS
+value: "$(PULSAR_MANAGER_OPTS) -Dlog4j2.formatMsgNoLookups=true"

Review comment:
   found the docs, 
https://kubernetes.io/docs/tasks/inject-data-application/define-interdependent-environment-variables/
 , it seems. 




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] lhotari commented on a change in pull request #198: Added -Dlog4j2.formatMsgNoLookups=true to PULSAR_MANAGER_OPTS

[GitBox]

lhotari commented on a change in pull request #198:
URL: https://github.com/apache/pulsar-helm-chart/pull/198#discussion_r781547436



##
File path: charts/pulsar/templates/pulsar-manager-deployment.yaml
##
@@ -89,6 +89,8 @@ spec:
 {{- else }}
 name: "{{ template "pulsar.fullname" . }}-{{ 
.Values.pulsar_manager.component }}-secret"
 {{- end }}
+  - name: PULSAR_MANAGER_OPTS
+value: "$(PULSAR_MANAGER_OPTS) -Dlog4j2.formatMsgNoLookups=true"

Review comment:
   LGTM




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-manager] sourabhaggrawal commented on pull request #435: Fix for Sidebar items not visible to admin and superadmin

[GitBox]

sourabhaggrawal commented on pull request #435:
URL: https://github.com/apache/pulsar-manager/pull/435#issuecomment-1009555011


   Hi @eolivelli @tuteng  Please take a look.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-manager] sourabhaggrawal commented on pull request #436: Allow user to assign tenant as resource to role

[GitBox]

sourabhaggrawal commented on pull request #436:
URL: https://github.com/apache/pulsar-manager/pull/436#issuecomment-1009555720


   HI @eolivelli @tuteng please take a look


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-manager] sourabhaggrawal commented on pull request #437: Set read/write access to resource for each role

[GitBox]

sourabhaggrawal commented on pull request #437:
URL: https://github.com/apache/pulsar-manager/pull/437#issuecomment-1009555903


   Hi @tuteng @eolivelli please take a look.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-manager] tuteng merged pull request #438: Updated to fix Log4J security vulnerabilities

[GitBox]

tuteng merged pull request #438:
URL: https://github.com/apache/pulsar-manager/pull/438


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [VOTE] PIP-130: Apply redelivery backoff policy for ack timeout

[PengHui Li]

Thanks for your participates.

Close the vote with 3 (+1) bindings and 3 (+1) non-bindings, 0 (-1).

Regards,
Penghui

On Fri, Jan 7, 2022 at 8:43 AM Sijie Guo  wrote:

> +1
>
> On Wed, Jan 5, 2022 at 12:12 AM Ran Gao  wrote:
>
> > +1
> >
> > Best,
> > Ran Gao
> >
> > On 2022/01/04 03:34:33 PengHui Li wrote:
> > > This is the voting thread for PIP-130. It will stay open for at least
> 48
> > > hours.
> > >
> > > https://github.com/apache/pulsar/issues/13528
> > >
> > > Pasted below for quoting convenience.
> > >
> > > -
> > >
> > > PIP 130: Apply redelivery backoff policy for ack timeout
> > >
> > > ## Motivation
> > >
> > > PIP 106
> > >
> >
> https://github.com/apache/pulsar/wiki/PIP-106%3A-Negative-acknowledgment-backoff
> > > introduced negative acknowledgment message redelivery backoff which
> > allows
> > > users to achieve
> > > more flexible message redelivery delay time control. But the redelivery
> > > backoff policy only
> > > apply to the negative acknowledgment API, for users who use ack timeout
> > to
> > > trigger the message
> > > redelivery, not the negative acknowledgment API, they can't use the new
> > > features introduced by
> > > PIP 106.
> > >
> > > So the proposal is to apply the message redelivery policy for the ack
> > > timeout mechanism.
> > > Users can specify an ack timeout redelivery backoff, for example, apply
> > an
> > > exponential backoff
> > > with 10 seconds ack timeout:
> > >
> > > ```java
> > > client.newConsumer()
> > > .ackTimeout(10, TimeUnit.SECOND)
> > > .ackTimeoutRedeliveryBackoff(
> > > ExponentialRedeliveryBackoff.builder()
> > > .minDelayMs(1000)
> > > .maxDelayMs(6).build());
> > > .subscribe();
> > > ```
> > >
> > > The message redelivery behavior should be:
> > >
> > > |  Redelivery count   | Redelivery delay  |
> > > |    |   |
> > > | 1 | 10 + 1 seconds |
> > > | 2 | 10 + 2 seconds |
> > > | 3 | 10 + 4 seconds |
> > > | 4 | 10 + 8 seconds |
> > > | 5 | 10 + 16 seconds |
> > > | 6 | 10 + 32 seconds |
> > > | 7 | 10 + 60 seconds |
> > > | 8 | 10 + 60 seconds |
> > >
> > > ## Goal
> > >
> > > Add an API to the Java Client to provide the ability to specify the ack
> > > timeout message redelivery
> > > backoff and the message redelivery behavior should abide by the
> > redelivery
> > > backoff policy.
> > >
> > >
> > > ## API Changes
> > >
> > > 1. Change `NegativeAckRedeliveryBackoff` to `RedeliveryBackoff`, so
> that
> > we
> > > can use the
> > > MessageRedeliveryBackoff for both negative acknowledgment API and ack
> > > timeout message redelivery.
> > >
> > > 2. Change `NegativeAckRedeliveryExponentialBackoff` to
> > > `ExponentialRedeliveryBackoff`, and add `multiplier`
> > > for `RedeliveryExponentialBackoff` with default value 2.
> > >
> > > ExponentialRedeliveryBackoff.builder()
> > > .minDelayMs(1000)
> > > .maxDelayMs(6)
> > > .multiplier(5)
> > > .build()
> > >
> > > 3. Add `ackTimeoutRedeliveryBackoff` method for the `ConsumerBuilder`:
> > >
> > > ```java
> > > client.newConsumer()
> > > .ackTimeout(10, TimeUnit.SECOND)
> > > .ackTimeoutRedeliveryBackoff(
> > > ExponentialRedeliveryBackoff.builder()
> > > .minDelayMs(1000)
> > > .maxDelayMs(6).build());
> > > .subscribe();
> > > ```
> > >
> > > ## Compatibility and migration plan
> > >
> > > Since the negative acknowledgment message, redelivery backoff has not
> > been
> > > released yet,
> > > so we can modify the API directly.
> > >
> > > ## Tests plan
> > >
> > > - Verify the introduced `multiplier` of ExponentialRedeliveryBackoff
> > > - Verify the ack timeout message redelivery work as expected
> > >
> > > Regards,
> > > Penghui
> > >
> >
>