[GitHub] [pulsar-client-node] zhaoyajun2009 commented on issue #188: When installing the Pulsar Node.js client, the operation steps need to be optimized

[GitBox]

zhaoyajun2009 commented on issue #188:
URL: 
https://github.com/apache/pulsar-client-node/issues/188#issuecomment-1006386780


   > you need to install gcc and g++ dependency
   
   you need to install gcc and g++ dependency


-- 
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-client-node] zhaoyajun2009 edited a comment on issue #188: When installing the Pulsar Node.js client, the operation steps need to be optimized

[GitBox]

zhaoyajun2009 edited a comment on issue #188:
URL: 
https://github.com/apache/pulsar-client-node/issues/188#issuecomment-1006386780


   > you need to install gcc and g++ dependency with the command of ‘yum 
install’。
   
   


-- 
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-client-node] zhaoyajun2009 commented on issue #188: When installing the Pulsar Node.js client, the operation steps need to be optimized

[GitBox]

zhaoyajun2009 commented on issue #188:
URL: 
https://github.com/apache/pulsar-client-node/issues/188#issuecomment-1006389761


   > I am facing the same. @zhaoyajun2009 did you get it working?
   you need to install gcc and g++ dependency with the command of ‘yum install’。


-- 
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-client-node] zhaoyajun2009 removed a comment on issue #188: When installing the Pulsar Node.js client, the operation steps need to be optimized

[GitBox]

zhaoyajun2009 removed a comment on issue #188:
URL: 
https://github.com/apache/pulsar-client-node/issues/188#issuecomment-1006386780


   > you need to install gcc and g++ dependency with the command of ‘yum 
install’。
   
   


-- 
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: [DISCUSSION] PIP-132: Include message header size when check maxMessageSize of non-batch message on the client side.

[Haiting Jiang]

Hi Zike,

Thank you for pointing this out. Indeed, the metadata size is not exactly the 
same.

I think we don't need to calculate the exact final message size for chunking 
size, just need 
to make sure all chunked message can be produced successfully, as we don't 
check max 
message size if chunking is enabled, it's default behavior in client and 
PIP-131 disabled the 
check on broker side.

So in order to produce chunk message successfully, we can just use
`ClientCnx.getMaxMessageSize() - msgMetadata.getSerializedSize()` as chunk size.
as the varint field won't take too much space (several bytes each), and broker 
have 10KB 
buffer for maxMessageSize.

Thanks,
Haiting Jiang


On 2022/01/05 08:11:06 Zike Yang wrote:
> > as we have the same header size for each chunk message.
> 
> The message metadata of different chunks will not be the same. There
> are serval fields with different values such as chunk id, publish
> time. Because some type of that fields is varint, I think the size of
> the header is not always the same.
> 
> 
> On Tue, Jan 4, 2022 at 11:51 AM Haiting Jiang  wrote:
> >
> > Good point,  I think we should shrink chunk size to 
> > "ClientCnx.getMaxMessageSize() - chunkMessageHeaderSize", as we have the 
> > same header size for each chunk message.
> >
> > Thanks,
> > Haiting Jiang
> >
> > On 2022/01/04 03:27:00 Zike Yang wrote:
> > > But how do we handle chunked messages? The chunked message is split
> > > based on the maxMessageSize(max payload size). This would seem to make
> > > `op.getMessageHeaderAndPayloadSize() > ClientCnx.getMaxMessageSize()`
> > > always true.
> > >
> > > Thanks,
> > > Zike
> > >
> > > On Fri, Dec 31, 2021 at 8:11 PM Haiting Jiang  
> > > wrote:
> > > >
> > > > Sorry, it should be PIP-132.
> > > >
> > > > Thanks,
> > > > Haiting Jiang
> > > >
> > > > On 2021/12/31 12:05:54 Haiting Jiang wrote:
> > > > > https://github.com/apache/pulsar/issues/13591
> > > > >
> > > > > Pasted below for quoting convenience.
> > > > >
> > > > > ——
> > > > >
> > > > > ## Motivation
> > > > >
> > > > > Currently, Pulsar client (Java) only checks payload size for max 
> > > > > message size validation.
> > > > >
> > > > > Client throws TimeoutException if we produce a message with too many 
> > > > > properties, see [1].
> > > > > But the root cause is that is trigged TooLongFrameException in broker 
> > > > > server.
> > > > >
> > > > > In this PIP, I propose to include message header size when check 
> > > > > maxMessageSize of non-batch
> > > > > messages, this brings the following benefits.
> > > > > 1. Clients can throw InvalidMessageException immediately if 
> > > > > properties takes too much storage space.
> > > > > 2. This will make the behaviour consistent with topic level max 
> > > > > message size check in broker.
> > > > > 3. Strictly limit the entry size less than maxMessageSize, avoid 
> > > > > sending message to bookkeeper failed.
> > > > >
> > > > > ## Goal
> > > > >
> > > > > Include message header size when check maxMessageSize for non-batch 
> > > > > message on the client side.
> > > > >
> > > > > ## Implementation
> > > > >
> > > > > ```
> > > > > // Add a size check in 
> > > > > org.apache.pulsar.client.impl.ProducerImpl#processOpSendMsg
> > > > > if (op.msg != null // for non-batch messages only
> > > > > && op.getMessageHeaderAndPayloadSize() > 
> > > > > ClientCnx.getMaxMessageSize()) {
> > > > > // finish send op with InvalidMessageException
> > > > > releaseSemaphoreForSendOp(op);
> > > > > op.sendComplete(new PulsarClientException(new 
> > > > > InvalidMessageException, op.sequenceId));
> > > > > }
> > > > >
> > > > >
> > > > > // 
> > > > > org.apache.pulsar.client.impl.ProducerImpl.OpSendMsg#getMessageHeaderAndPayloadSize
> > > > >
> > > > > public int getMessageHeaderAndPayloadSize() {
> > > > > ByteBuf cmdHeader = cmd.getFirst();
> > > > > cmdHeader.markReaderIndex();
> > > > > int totalSize = cmdHeader.readInt();
> > > > > int cmdSize = cmdHeader.readInt();
> > > > > int msgHeadersAndPayloadSize = totalSize - cmdSize - 4;
> > > > > cmdHeader.resetReaderIndex();
> > > > > return msgHeadersAndPayloadSize;
> > > > > }
> > > > > ```
> > > > >
> > > > > ## Reject Alternatives
> > > > > Add a new property like "maxPropertiesSize" or "maxHeaderSize" in 
> > > > > broker.conf and pass it to
> > > > > client like maxMessageSize. But the implementation is much more 
> > > > > complex, and don't have the
> > > > > benefit 2 and 3 mentioned in Motivation.
> > > > >
> > > > > ## Compatibility Issue
> > > > > As a matter of fact, this PIP narrows down the sendable range. 
> > > > > Previously, when maxMessageSize
> > > > > is 1KB, it's ok to send message with 1KB properties and 1KB payload. 
> > > > > But with this PIP, the
> > > > > sending will fail with InvalidMessageException.
> > > > >
> > > > > One conservative way is to add a boolean config 
> > > > > "includeHeaderInSizeCheck" to enable this
> > > > > feature. Bu

Re: [DISCUSSION] PIP-132: Support Pulsar system event.

[Haiting Jiang]

Hi mattison,

> For this part, I think we need to discuss. Do we create a specific event 
> class or use properties in json format?

I think String value would be enough for most cases. 
IMHO, these system event is mostly for administrators, so the data should be 
readable.


> Maybe the better way is to record some system internal event like node 
> changed, ledger deleted etc.

This PIP can start with a small scope of events that requires the attention of 
administrators, like ledger delete failure, zk session timeout, etc.

Thanks, 
Haiting Jiang


On 2022/01/06 05:23:52 mattison chao wrote:
> Hi, Haiting Jiang
> 
> 
> >>  CompletableFuture trigger(SystemEventMessage message);
> > 
> > Maybe `record` make more sense? 
> 
> +1
> 
> >>  SystemEventMessageBuilder properties(Map properties);
> >> 
> >>  SystemEventMessageBuilder addProperty(String key, Object value);
> > 
> > How to handle  the serialization and deserialization if the value type is 
> > Object?  
> 
> For this part, I think we need to discuss. Do we create a specific event 
> class or use properties in json format?
> 
> 
> > I think we don't need to record normal message producing and consuming 
> > event? 
> > That would make the system topic store too much data.
> 
> 
> Agree with you.
> 
> Maybe the better way is to record some system internal event like node 
> changed, ledger deleted etc.
> 
> 
> 
> 
> 
> 
> > On Jan 6, 2022, at 12:10 PM, Haiting Jiang  > > wrote:
> > 
> > 
> >>  CompletableFuture trigger(SystemEventMessage message);
> > 
> > Maybe `record` make more sense? 
> > 
> >>  SystemEventMessageBuilder properties(Map properties);
> >> 
> >>  SystemEventMessageBuilder addProperty(String key, Object value);
> > 
> > How to handle  the serialization and deserialization if the value type is 
> > Object?  
> > 
> >> - [ ] Producer publish
> >> - [ ] Message delivered
> >> - [ ] Message acked
> > 
> > I think we don't need to record normal message producing and consuming 
> > event? 
> > That would make the system topic store too much data.
> > 
> > 
> > On 2022/01/05 15:27:33 mattison chao wrote:
> >> Original PIP : https://github.com/apache/pulsar/issues/13628 
> >> 
> >> 
> >> Pasted bellow for quoting convenience.
> >> 
> >> —— 
> >> 
> >> ## Motivation
> >> 
> >> In some case or for better observability. We can support Pulsar event 
> >> notification mechanism, that can let user subscribe this system topic to 
> >> receive some **"we need notice to user"** event.
> >> 
> >> ## Goal
> >> 
> >> Enable users to receive Pulsar system event.
> >> 
> >> ## API Changes
> >> 
> >> 1. Add config ``pulsarSystemEventEnabled``
> >> 
> >> ```java
> >> pulsarSystemEventEnabled=false
> >> ```
> >> 2. Add ``SystemEventMessageBuilder``
> >> ```java
> >> 
> >> 
> >> public interface SystemEventMessageBuilder {
> >> 
> >>  SystemEventMessageBuilder eventType(SystemEvent event);
> >> 
> >>  SystemEventMessageBuilder properties(Map properties);
> >> 
> >>  SystemEventMessageBuilder addProperty(String key, Object value);
> >> 
> >>  SystemEventMessage build();
> >> 
> >> }
> >> 
> >> ```
> >> 3. Add ``SystemEventService``
> >> 
> >> ```java
> >> 
> >> public interface SystemEventService {
> >> 
> >>  void init();
> >> 
> >>  CompletableFuture trigger(SystemEventMessage message);
> >> 
> >>  void close();
> >> }
> >> 
> >> ```
> >> 
> >> ## Implementation
> >> 
> >> This PIP just is a simple version, it's purpose is to discuss what event 
> >> we need to trigger? how to trigger? and what is the event message 
> >> structure.
> >> 
> >> I think we need to trigger some event as bellow:
> >> 
> >> - [ ] Client connected
> >> - [ ] Client disconnected
> >> - [ ] Consumer subscribe
> >> - [ ] Consumer unsubscribe
> >> - [ ] Producer publish
> >> - [ ] Message delivered
> >> - [ ] Message acked
> >> 
> >> These are far from enough, and we need to continue to make supplements 
> >> here.
> >> Please fell free to give me more advice for this PIP.
> >> 
> >> ## Reject Alternatives
> >> 
> >> none.
> >> 
> >> Thanks,
> >> Mattisonchao
> > 
> > Thanks,
> > Haiting Jiang
> 
> 

About the implementation of a Mail Queue using Pulsar in Apache James

[Benoit TELLIER]

Hello Pulsar folks!

I am a member of the Apache James PMC, whose maintain the Java Apache
Mail Extensible Server (for the intimates hence James). The Distributed
James server aims at scaling emails on top of modern databases and
messaging technologies.

So far we relies on ActiveMQ/RabbitMQ as a messaging technology (please
don't judge us...). Features includes:
 - A mail queue (~work queue) supporting browsing, removes, delays
 - A messaging system for notifications (think IMAP IDLE spec)
 - Some smaller stuff: work-queues, ...

However this matter of fact will hopefully change as we receive a
contribution for a Mail Queue implemented with Pulsar [1].

As an Apache enthusiast, I think this could be an opportunity to
strengthen links between our communities. Who knows, some devs within
the Pulsar community might feel interested by this, and could share some
interesting insights on this. The Apache James PMC is mostly
Pulsar-naive so we might also benefit from an external eyes. In the
future we might also propose some work (eg GSOC 2022) on further
integrationg Pulsar into James, which could be an opportunity for
cooperation.

I apologize if this mail is of no interest to the Apache Pulsar
community or if it is the wrong place to post this kind of stuff.

Best regards,

Benoit TELLIER

[1] The aforementioned Pulsar PR :
https://github.com/apache/james-project/pull/808

Re: About the implementation of a Mail Queue using Pulsar in Apache James

[Enrico Olivelli]

Benoit,

Il Gio 6 Gen 2022, 10:54 Benoit TELLIER  ha scritto:

> Hello Pulsar folks!
>
> I am a member of the Apache James PMC, whose maintain the Java Apache
> Mail Extensible Server (for the intimates hence James). The Distributed
> James server aims at scaling emails on top of modern databases and
> messaging technologies.
>
> So far we relies on ActiveMQ/RabbitMQ as a messaging technology (please
> don't judge us...). Features includes:
>  - A mail queue (~work queue) supporting browsing, removes, delays
>  - A messaging system for notifications (think IMAP IDLE spec)
>  - Some smaller stuff: work-queues, ...
>
> However this matter of fact will hopefully change as we receive a
> contribution for a Mail Queue implemented with Pulsar [1].
>


This is great.

I have been working on mail queue systems for years and I will be happy to
review the PR and help with this opportunity to engage with the James
community

Cheers
Enrico


> As an Apache enthusiast, I think this could be an opportunity to
> strengthen links between our communities. Who knows, some devs within
> the Pulsar community might feel interested by this, and could share some
> interesting insights on this. The Apache James PMC is mostly
> Pulsar-naive so we might also benefit from an external eyes. In the
> future we might also propose some work (eg GSOC 2022) on further
> integrationg Pulsar into James, which could be an opportunity for
> cooperation.
>
> I apologize if this mail is of no interest to the Apache Pulsar
> community or if it is the wrong place to post this kind of stuff.
>
> Best regards,
>
> Benoit TELLIER
>
> [1] The aforementioned Pulsar PR :
> https://github.com/apache/james-project/pull/808
>
>

Re: [ANNOUNCE] Apache Pulsar 2.8.2 released

[PengHui Li]

Thanks for the great work!

Regards,
Penghui

On Wed, Jan 5, 2022 at 10:16 PM linlin  wrote:

> The Apache Pulsar team is proud to announce Apache Pulsar version 2.8.2.
>
> Pulsar is a highly scalable, low latency messaging platform running on
> commodity hardware. It provides simple pub-sub semantics over topics,
> guaranteed at-least-once delivery of messages, automatic cursor management
> for
> subscribers, and cross-datacenter replication.
>
> For Pulsar release details and downloads, visit:
>
> https://pulsar.apache.org/download
>
> Release Notes are at:
> http://pulsar.apache.org/release-notes
>
> We would like to thank the contributors that made the release possible.
>
> Regards,
>
> The Pulsar Team
>

Other rates are still valid when updating part rates in resource group

[Ruguo Yu]

Hi Pulsar Community,
Currently, the resource group has four rates, including publishRateInMsgs, 
publishRateInBytes, dispatchRateInMsgs and dispatchRateInBytes, but other rates 
if previously set or updated will be invalid when we update part rates, which 
does not conform to the semantics of the `update` and makes it easy for users 
to generate confuse.
 

The purposr of PR[0] is to truly implement the semantics of the `update` to 
ensure that the other rates remain the original value during an update 
operation.

 

Obviously, this is a behavior change and it is necessary to let everyone know, 
please point out if you have other questions.

 

Thanks,

Ruguo Yu

 

[0] https://github.com/apache/pulsar/pull/13543

[GitHub] [pulsar-client-node] Hoskins355 commented on issue #188: When installing the Pulsar Node.js client, the operation steps need to be optimized

[GitBox]

Hoskins355 commented on issue #188:
URL: 
https://github.com/apache/pulsar-client-node/issues/188#issuecomment-1006598382


   I am trying to install with Docker 
https://gist.github.com/Hoskins355/c36c9d4c1c69e55427d5ec58d44a2009 using base 
image "apachepulsar/pulsar-build:centos-7" which should have all dependencies. 
I tried to add gcc and g++ as well but I am still getting the same error. 


-- 
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: Other rates are still valid when updating part rates in resource group

[Kaushik Ghosh]

Not clear what exactly the concern is (i.e., what "other rates" will become
invalid) on a resource group when a new rate is set.
Among the rates in each direction (dispatch/publish), the semantics are
that throttling will kick in whenever any of the *RateInMsgs and,
*RateInBytes is hit during an evaluation interval.

Regards,
Kaushik

On Thu, Jan 6, 2022 at 5:04 AM Ruguo Yu  wrote:

> [ External sender. Exercise caution. ]
>
> Hi Pulsar Community,
> Currently, the resource group has four rates, including publishRateInMsgs,
> publishRateInBytes, dispatchRateInMsgs and dispatchRateInBytes, but other
> rates if previously set or updated will be invalid when we update part
> rates, which does not conform to the semantics of the `update` and makes it
> easy for users to generate confuse.
>
>
> The purposr of PR[0] is to truly implement the semantics of the `update`
> to ensure that the other rates remain the original value during an update
> operation.
>
>
>
> Obviously, this is a behavior change and it is necessary to let everyone
> know, please point out if you have other questions.
>
>
>
> Thanks,
>
> Ruguo Yu
>
>
>
> [0] https://github.com/apache/pulsar/pull/13543
>
>

Re: Other rates are still valid when updating part rates in resource group

[Ravi Vaidyanathan]

Hi Ruguo,

When we were doing this feature it was decided that we will keep it clean and 
assume that the user will do a  read, modify, write. This will ensure that the 
user can preserve the current values if the intent is to do so.

Thanks.
Ravi.

> On Jan 6, 2022, at 5:03 AM, Ruguo Yu  wrote:
> 
> [ External sender. Exercise caution. ]
> 
> Hi Pulsar Community,
> Currently, the resource group has four rates, including publishRateInMsgs, 
> publishRateInBytes, dispatchRateInMsgs and dispatchRateInBytes, but other 
> rates if previously set or updated will be invalid when we update part rates, 
> which does not conform to the semantics of the `update` and makes it easy for 
> users to generate confuse.
> 
> 
> The purposr of PR[0] is to truly implement the semantics of the `update` to 
> ensure that the other rates remain the original value during an update 
> operation.
> 
> 
> 
> Obviously, this is a behavior change and it is necessary to let everyone 
> know, please point out if you have other questions.
> 
> 
> 
> Thanks,
> 
> Ruguo Yu
> 
> 
> 
> [0] https://github.com/apache/pulsar/pull/13543
> 

Re: [ANNOUNCE] Apache Pulsar 2.8.2 released

[Enrico Olivelli]

Thanks!

Congrats

Enrico

Il Gio 6 Gen 2022, 13:26 PengHui Li  ha scritto:

> Thanks for the great work!
>
> Regards,
> Penghui
>
> On Wed, Jan 5, 2022 at 10:16 PM linlin  wrote:
>
> > The Apache Pulsar team is proud to announce Apache Pulsar version 2.8.2.
> >
> > Pulsar is a highly scalable, low latency messaging platform running on
> > commodity hardware. It provides simple pub-sub semantics over topics,
> > guaranteed at-least-once delivery of messages, automatic cursor
> management
> > for
> > subscribers, and cross-datacenter replication.
> >
> > For Pulsar release details and downloads, visit:
> >
> > https://pulsar.apache.org/download
> >
> > Release Notes are at:
> > http://pulsar.apache.org/release-notes
> >
> > We would like to thank the contributors that made the release possible.
> >
> > Regards,
> >
> > The Pulsar Team
> >
>

Re: Lifting Kubernetes minimum version requirement for Apache Pulsar Helm Charts from k8s 1.14 to 1.18

[Sijie Guo]

Can you clarify what is the main change? I see most of the changes are done
in the CI part.

- Sijie

On Tue, Jan 4, 2022 at 1:41 AM Lari Hotari  wrote:

> Hi all,
>
> Currently k8s 1.14 version is used in CI to verify the Helm chart changes.
>
> k8s 1.14 became end-of-life 2019-12-11 , over 2 years ago [1].
> The oldest maintained version for Kubernetes is 1.20 and it will become
> end-of-life on 2022-02-28, in less than 2 months from now [2].
>
> There's a PR to lift the minimum requirement for Apache Pulsar Helm Charts
> to 1.18 so that we don't fall too far behind.
> https://github.com/apache/pulsar-helm-chart/pull/192
>
> Please review. If the PR gets approved and merged, the Kubernetes minimum
> version requirement will be lifted to Kubernetes 1.18.
>
>
> Best regards,
>
> Lari
>
>
> [1]
> https://kubernetes.io/releases/patch-releases/#non-active-branch-history
> [2] https://kubernetes.io/releases/patch-releases/#1-20
>

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

[Sijie Guo]

+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
> >
>

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

[Sijie Guo]

+1 ThresholdShedder is a much better policy

On Tue, Jan 4, 2022 at 6:24 AM Hang Chen  wrote:

> 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: Voting time period minimum

[Sijie Guo]

I believe 48 hours vote is only for PIP, which was agreed in the dev@.

For other activities, this project follows the ASF 72 hours rule.

- Sijie

On Mon, Jan 3, 2022 at 8:17 PM Dave Fisher  wrote:

> Yes please! I did not notice that.
>
> Personally I would be ok with 72 hours lazy consensus, but if we must vote
> then 72 hours is a minimum.
>
> Thanks,
> Dave
>
> Sent from my iPhone
>
> > On Jan 3, 2022, at 8:10 PM, Haiting Jiang 
> wrote:
> >
> > Hi Dave,
> >
> > The "48 hours" rule is on [1].
> > Maybe we should update the wiki and PIP template first?
> >
> > [1]
> https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-%28PIP%29
> >
> >> On 2022/01/04 03:59:45 Dave Fisher wrote:
> >> The ASF considers that the minimum time for a vote is 72 hours for a
> few reasons particularly:
> >>
> >> (1) to allow the world to spin. People are in most time zones.
> >> (2) to allow for weekends.
> >> (3) to allow time for contributors who are not working full time on the
> project.
> >>
> >> Many projects use a 7 day vote.
> >>
> >> We just had 2 PIP votes called for 48 hours so this rule is worth
> reiterating!
> >>
> >> All the best,
> >> Dave
> >>
> >> Sent from my iPhone
> >>
> >
> >
> > Thanks,
> > Haiting Jiang
>
>

Re: upcoming change: Apache Pulsar Helm Chart switching from Pulsar 2.7.4 version to 2.8.2; known issue with ZK when TLS is enabled

[Sijie Guo]

The fundamental problem I see is that we don't have a proper helm chart
release and we don't have good versioning guidance.

Chart should have its own version, which is independent of the Pulsar
version.

Also, we need to provide a guide to the community - most of the time, you
don't need to upgrade zookeeper and bookkeeper. Because these two
components are rarely changed.

That means:

1. We should have a separate `version` from `appVersion`.
2. We should use the Pulsar image version as the `appVersion`.
3. It is okay to only update broker and proxy images version and leave
zookeeper and bookkeeper version unchanged.

That's probably not the final guide. But at least, we can have something to
get started to formalize the process. This guide will then help us handle
such situations better.

- Sijie

On Wed, Jan 5, 2022 at 6:00 AM 陳智弘  wrote:

> Hi everyone,
>
>   From my side, I think currently merging the request without regarding the
> known issue and announcing this information on the website is a good
> option.
>
> <
> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> 不含病毒。www.avg.com
> <
> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Lari Hotari  於 2022年1月5日 週三 下午9:04寫道：
>
> > Reminder: we need to decide about the developement of Apache Pulsar Helm
> > chart.
> > Please reply to the email or review
> > https://github.com/apache/pulsar-helm-chart/pull/190 .
> > That PR is blocked since a decision must be made whether it's fine to
> make
> > the change, although there's a known issue in Zookeeper when TLS is
> > enabled.
> > The issue is ZOOKEEPER-3988 /
> > https://github.com/apache/pulsar/issues/11070 .
> > The bug currently only impacts TLS since the change
> > https://github.com/apache/pulsar-helm-chart/pull/180 switched
> > to use NIOServerCnxnFactory for Zookeeper. NIOServerCnxnFactory doesn't
> > support TLS and the impacted NettyServerCnxnFactory must be used for TLS.
> >
> > How do we handle the decision? Can we proceed in merging
> > https://github.com/apache/pulsar-helm-chart/pull/190 regardless of the
> > known issue?
> >
> > BR,
> > Lari
> >
> > On Mon, Jan 3, 2022 at 4:39 PM Lari Hotari  wrote:
> >
> > > Hi all,
> > >
> > > There's an upcoming change in the Apache Pulsar Helm chart to finally
> > > switch to Pulsar 2.8.x, more specifically to Apache Pulsar version
> 2.8.2
> > .
> > > The latest Apache Pulsar Helm Chart release uses the Apache Pulsar
> 2.7.4
> > > image.
> > >
> > > The pull request to switch to Apache Pulsar image version 2.8.2 is
> > current
> > > in review:
> > > https://github.com/apache/pulsar-helm-chart/pull/190
> > >
> > > There's a known issue that Zookeeper TLS isn't stable because of
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-3988 (also reported in
> > > apache/pulsar as https://github.com/apache/pulsar/issues/11070) .
> > > The fix https://github.com/apache/zookeeper/pull/1770 is planned for
> > > Zookeeper 3.7.1 version.
> > > There's a workaround in the Apache Pulsar Helm chart when TLS isn't
> > > enabled for Zookeeper. That was added by
> > > https://github.com/apache/pulsar-helm-chart/pull/180 .
> > > However, the workaround cannot be applied when TLS is enabled for
> > > Zookeeper.
> > >
> > > Should we postpone switching to Apache Pulsar 2.8.2 in the Helm chart
> > > until there's a fix for ZOOKEEPER-3988 /
> > > https://github.com/apache/pulsar/issues/11070 ?
> > >
> > > BR,
> > > Lari
> > >
> >
>

Re: [PR] Pulsar non root docker image

[Sijie Guo]

Is Functions being verified?

- Sijie

On Wed, Jan 5, 2022 at 11:26 AM Michael Marshall 
wrote:

> PR 13376 is ready for review, PTAL.
>
> What approach should we take regarding docker image size?
> I propose providing a minimal image along with documentation
> on how to add your own debugging tools. Is that sufficient?
>
> I'd like to include this feature in 2.10.0.
>
> Note that you can test the new docker image here:
> michaelmarshall/pulsar:2.10.0-SNAPSHOT-1dec8b9
>
> Thanks,
> Michael
>
>
>
> On Wed, Dec 22, 2021 at 1:51 PM Michael Marshall 
> wrote:
> >
> > Thanks for raising this important topic, Enrico.
> >
> > > Basically if you are running as non root, you cannot add tools on
> demand,
> > > so we need to add basic tools, like netstat/vim/unzip otherwise
> when
> > > you have a problem you are trapped.
> >
> > I agree that running as a non root user presents challenges for
> > debugging. However, I don't think we should optimize our production
> > image for debugging. We should instead optimize for a minimal docker
> > image with as few dependencies as possible to decrease the image's
> > attack surface.
> >
> > Also, I think it would be valuable to audit the current
> > dependencies we already ship in our docker image. For example, this
> > single `RUN` command [0] adds 1 GB of dependencies to our
> > docker image.
> >
> > If there is a need for an image with debug tools, we could publish a
> > "debug" image that extends our production image with extra tooling.
> > Users could swap out the prod image with the debug image, as needed.
> > However, it is pretty easy and quick to extend a public docker image
> > to add your own tooling. By documenting how to extend our docker
> > image, we could avoid decisions about which tools should be in our
> > image.
> >
> > > there are ways to inject tools, but they are very hard to execute for
> > > people who is not very experienced
> >
> > We can solve this through additional documentation. Freeznet asked a
> > similar question about debugging on the PR. I provided some methods for
> > debugging here [1].
> >
> > Thanks,
> > Michael
> >
> > [0]
> https://github.com/apache/pulsar/blob/5dd60dbd748e446f8da396b448a5bb16a2ae6902/docker/pulsar/Dockerfile#L46-L55
> > [1] https://github.com/apache/pulsar/pull/13376#discussion_r773580954
> >
> >
> >
> >
> > On Wed, Dec 22, 2021 at 1:29 AM Enrico Olivelli 
> wrote:
> > >
> > > Michael,
> > >
> > > I would like to add this item to the list
> > > https://github.com/apache/pulsar/pull/10815
> > >
> > > Basically if you are running as non root, you cannot add tools on
> demand,
> > > so we need to add basic tools, like netstat/vim/unzip otherwise
> when
> > > you have a problem you are trapped.
> > >
> > > there are ways to inject tools, but they are very hard to execute for
> > > people who is not very experienced
> > >
> > > Enrico
> > >
> > >
> > > Il giorno mer 22 dic 2021 alle ore 04:40 Haiting Jiang <
> > > jianghait...@apache.org> ha scritto:
> > >
> > > > > 1. Pulsar configuration is read in only from configuration files in
> > > > > `/pulsar/conf`. A non root user must be able to update these files
> to
> > > > > have run with custom configuration.
> > > >
> > > > About the configurations, I also see similar require like this
> lately [0].
> > > > IMHO, update any configs without redeploy service is a useful
> feature.
> > > > I would like post a PIP for this later.
> > > > Basic idea is like make all configs dynamic by default except
> > > > `metadataStoreUrl` and all configs are stored under path
> > > > "/admin/configuration" in metadata store.
> > > >
> > > > [0] https://github.com/apache/pulsar/pull/13074
> > > >
> > > > On 2021/12/21 20:16:44 Michael Marshall wrote:
> > > > > All tests are now passing for this PR [0]. I built the docker image
> > > > > and pushed it to my personal repository to simplify testing [1] for
> > > > > anyone interested in verifying the changes.
> > > > >
> > > > > I would like our docker image to be as close to immutable as
> possible.
> > > > > As far as I can tell, here are the only reasons the image cannot be
> > > > > immutable:
> > > > >
> > > > > 1. Pulsar configuration is read in only from configuration files in
> > > > > `/pulsar/conf`. A non root user must be able to update these files
> to
> > > > > have run with custom configuration.
> > > > > 2. The Pulsar function worker unpacks nar files to
> > > > > `/pulsar/download/pulsar_functions` by default.
> > > > > 3. Pulsar tiered storage writes to `/pulsar` by default when using
> > > > > filesystem storage.
> > > > > 4. The Presto SQL worker writes to `/pulsar/lib/presto/` by
> default.
> > > > > 5. Pulsar-admin and functions write to `/pulsar/log` by default
> > > > > (possibly other components too).
> > > > >
> > > > > Note that even though bookkeepers and zookeepers write to
> > > > > `/pulsar/data`, they should be writing to docker volumes, in which
> > > > > case, the host's file system permissions are all

[GitHub] [pulsar-client-node] zhaoyajun2009 commented on issue #188: When installing the Pulsar Node.js client, the operation steps need to be optimized

[GitBox]

zhaoyajun2009 commented on issue #188:
URL: 
https://github.com/apache/pulsar-client-node/issues/188#issuecomment-1007068131


   I installed the dependency by install RPM 
package,(https://pulsar.apache.org/docs/en/client-libraries-cpp/#compilation),
   The success result is the file as below is created in /usr/lib ：
   lrwxrwxrwx  1 root root   18 12月 30 22:21 libpulsar.so -> 
libpulsar.so.2.9.1
   lrwxrwxrwx  1 root root   23 12月 30 22:21 libpulsarnossl.so -> 
libpulsarnossl.so.2.9.1
   
   Then I installed the gcc and g++ by yum as below：
   sudo yum -y install gcc automake autoconf libtool make
   sudo yum -y install gcc-c++
   
   -
   > I am trying to install with Docker 
https://gist.github.com/Hoskins355/c36c9d4c1c69e55427d5ec58d44a2009 using base 
image "apachepulsar/pulsar-build:centos-7" which should have all dependencies. 
I tried to add gcc and g++ as well but I am still getting the same error.
   
   


-- 
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-client-node] zhaoyajun2009 edited a comment on issue #188: When installing the Pulsar Node.js client, the operation steps need to be optimized

[GitBox]

zhaoyajun2009 edited a comment on issue #188:
URL: 
https://github.com/apache/pulsar-client-node/issues/188#issuecomment-1007068131


   I installed the dependency by install RPM 
package,(https://pulsar.apache.org/docs/en/client-libraries-cpp/#compilation),
   The success result is the files as below  created in /usr/lib ：
   lrwxrwxrwx  1 root root   18 12月 30 22:21 libpulsar.so -> 
libpulsar.so.2.9.1
   lrwxrwxrwx  1 root root   23 12月 30 22:21 libpulsarnossl.so -> 
libpulsarnossl.so.2.9.1
   
   Then I installed the gcc and g++ by yum as below：
   sudo yum -y install gcc automake autoconf libtool make
   sudo yum -y install gcc-c++
   
   -
   > I am trying to install with Docker 
https://gist.github.com/Hoskins355/c36c9d4c1c69e55427d5ec58d44a2009 using base 
image "apachepulsar/pulsar-build:centos-7" which should have all dependencies. 
I tried to add gcc and g++ as well but I am still getting the same error.
   
   


-- 
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: [DISCUSSION] PIP-132: Support Pulsar system event.

[Michael Marshall]

This is a great topic, thanks for starting the discussion Mattison.

The PIP only mentions topic events right now--I think we should
include (or plan to include) metadata related events, too.

I proposed a similar feature in April 2021. There was good discussion
then that is relevant now [0].

I think a system or audit topic (more likely a collection of topics)
would be extremely valuable. However, last year's discussion raised
several important concerns that PIP 132 does not yet address.

First, we need to ensure this feature is not a single point of failure
for the rest of the cluster. That requires defining how we will handle
failures when publishing audit messages. Joe Francis had several
good notes on this topic [0]. Also, the feature must be scalable: it
should work with 100+ brokers and 1,000,000+ topics.

> Also if this pip is for user use cases then there needs to be isolation at 
> the tenant level.

Great point. Further, if these events are also meant for system admins
(super users), we'll need to prevent tenant admins from hiding events
or creating fake events (by deleting system topics/subscriptions or
publishing to system event topics). That will require careful attention to
authorization.

The question of tenant isolation presupposes event classification.
Namespace and topic level events obviously belong to a tenant, so
the event topic for those events could live in a tenant namespace.
Tenant level events like tenant creation/deletion or changes in broker
state would likely require a "system event tenant" to host this tenant
agnostic information.

Alternatively, we could use a system event tenant for all system events. The
namespaces could map to tenant names with an extra namespace for tenant
agnostic events. We might need to use topic level policies to achieve proper
tenant isolation. Personally, I think a dedicated tenant might be the best
solution, but I need to think about it more.

If I understand it correctly, PIP 45 opens the path for us to move towards a
zookeeper-less metadata solution. If that solution relies on Pulsar topics
for metadata, would we get a kind of system event topic for free? We
should make sure we're not duplicating efforts.

This is a great feature, and I'd like to make sure it is robust and well defined
before we start its implementation.

Thanks,
Michael

[0] https://lists.apache.org/thread/h4cbvwjdomktsq2jo66x5qpvhdrqk871







On Thu, Jan 6, 2022 at 3:42 AM Haiting Jiang  wrote:
>
> Hi mattison,
>
> > For this part, I think we need to discuss. Do we create a specific event 
> > class or use properties in json format?
>
> I think String value would be enough for most cases.
> IMHO, these system event is mostly for administrators, so the data should be 
> readable.
>
>
> > Maybe the better way is to record some system internal event like node 
> > changed, ledger deleted etc.
>
> This PIP can start with a small scope of events that requires the attention 
> of administrators, like ledger delete failure, zk session timeout, etc.
>
> Thanks,
> Haiting Jiang
>
>
> On 2022/01/06 05:23:52 mattison chao wrote:
> > Hi, Haiting Jiang
> >
> >
> > >>  CompletableFuture trigger(SystemEventMessage message);
> > >
> > > Maybe `record` make more sense?
> >
> > +1
> >
> > >>  SystemEventMessageBuilder properties(Map properties);
> > >>
> > >>  SystemEventMessageBuilder addProperty(String key, Object value);
> > >
> > > How to handle  the serialization and deserialization if the value type is 
> > > Object?
> >
> > For this part, I think we need to discuss. Do we create a specific event 
> > class or use properties in json format?
> >
> >
> > > I think we don't need to record normal message producing and consuming 
> > > event?
> > > That would make the system topic store too much data.
> >
> >
> > Agree with you.
> >
> > Maybe the better way is to record some system internal event like node 
> > changed, ledger deleted etc.
> >
> >
> >
> >
> >
> >
> > > On Jan 6, 2022, at 12:10 PM, Haiting Jiang  > > > wrote:
> > >
> > >
> > >>  CompletableFuture trigger(SystemEventMessage message);
> > >
> > > Maybe `record` make more sense?
> > >
> > >>  SystemEventMessageBuilder properties(Map properties);
> > >>
> > >>  SystemEventMessageBuilder addProperty(String key, Object value);
> > >
> > > How to handle  the serialization and deserialization if the value type is 
> > > Object?
> > >
> > >> - [ ] Producer publish
> > >> - [ ] Message delivered
> > >> - [ ] Message acked
> > >
> > > I think we don't need to record normal message producing and consuming 
> > > event?
> > > That would make the system topic store too much data.
> > >
> > >
> > > On 2022/01/05 15:27:33 mattison chao wrote:
> > >> Original PIP : https://github.com/apache/pulsar/issues/13628 
> > >> 
> > >>
> > >> Pasted bellow for quoting convenience.
> > >>
> > >> ——
> > >>
> > >> ## Motivation
> > >>
> > >> In some case or for better observabi

Re: upcoming change: Apache Pulsar Helm Chart switching from Pulsar 2.7.4 version to 2.8.2; known issue with ZK when TLS is enabled

[Enrico Olivelli]

Sijie,

Il Ven 7 Gen 2022, 01:58 Sijie Guo  ha scritto:

> The fundamental problem I see is that we don't have a proper helm chart
> release and we don't have good versioning guidance.
>
> Chart should have its own version, which is independent of the Pulsar
> version.
>
> Also, we need to provide a guide to the community - most of the time, you
> don't need to upgrade zookeeper and bookkeeper. Because these two
> components are rarely changed.
>

I agree with you and I want to add that one of the problems is that we are
using the Pulsar docker images to start Zookeeper and Bookies.
And we are wrapping the entrypoints (I mean the command line to launch the
service) with the Pulsar command.
So the version you use for zookeeper and BookKeeper is tied to the Pulsar
version.
Usually it is hard to explain to users to use Pulsar 2.x for the bookies
and Pulsar 2.y for the brokers.

We should move to using the standard docker images for zookeeper and
BookKeeper.




> That means:
>
> 1. We should have a separate `version` from `appVersion`.
> 2. We should use the Pulsar image version as the `appVersion`.
> 3. It is okay to only update broker and proxy images version and leave
> zookeeper and bookkeeper version unchanged.
>
> That's probably not the final guide. But at least, we can have something to
> get started to formalize the process. This guide will then help us handle
> such situations better.
>

I would fix the helm chart now and t let people upgrade to Pulsar 2.8/2.9
and then we can provide a better solution.

Otherwise people are forced to use third party helm charts, and I really
don't like this situation

Enrico



> - Sijie
>
> On Wed, Jan 5, 2022 at 6:00 AM 陳智弘  wrote:
>
> > Hi everyone,
> >
> >   From my side, I think currently merging the request without regarding
> the
> > known issue and announcing this information on the website is a good
> > option.
> >
> > <
> >
> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >
> > 不含病毒。www.avg.com
> > <
> >
> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > Lari Hotari  於 2022年1月5日 週三 下午9:04寫道：
> >
> > > Reminder: we need to decide about the developement of Apache Pulsar
> Helm
> > > chart.
> > > Please reply to the email or review
> > > https://github.com/apache/pulsar-helm-chart/pull/190 .
> > > That PR is blocked since a decision must be made whether it's fine to
> > make
> > > the change, although there's a known issue in Zookeeper when TLS is
> > > enabled.
> > > The issue is ZOOKEEPER-3988 /
> > > https://github.com/apache/pulsar/issues/11070 .
> > > The bug currently only impacts TLS since the change
> > > https://github.com/apache/pulsar-helm-chart/pull/180 switched
> > > to use NIOServerCnxnFactory for Zookeeper. NIOServerCnxnFactory doesn't
> > > support TLS and the impacted NettyServerCnxnFactory must be used for
> TLS.
> > >
> > > How do we handle the decision? Can we proceed in merging
> > > https://github.com/apache/pulsar-helm-chart/pull/190 regardless of the
> > > known issue?
> > >
> > > BR,
> > > Lari
> > >
> > > On Mon, Jan 3, 2022 at 4:39 PM Lari Hotari  wrote:
> > >
> > > > Hi all,
> > > >
> > > > There's an upcoming change in the Apache Pulsar Helm chart to finally
> > > > switch to Pulsar 2.8.x, more specifically to Apache Pulsar version
> > 2.8.2
> > > .
> > > > The latest Apache Pulsar Helm Chart release uses the Apache Pulsar
> > 2.7.4
> > > > image.
> > > >
> > > > The pull request to switch to Apache Pulsar image version 2.8.2 is
> > > current
> > > > in review:
> > > > https://github.com/apache/pulsar-helm-chart/pull/190
> > > >
> > > > There's a known issue that Zookeeper TLS isn't stable because of
> > > > https://issues.apache.org/jira/browse/ZOOKEEPER-3988 (also reported
> in
> > > > apache/pulsar as https://github.com/apache/pulsar/issues/11070) .
> > > > The fix https://github.com/apache/zookeeper/pull/1770 is planned for
> > > > Zookeeper 3.7.1 version.
> > > > There's a workaround in the Apache Pulsar Helm chart when TLS isn't
> > > > enabled for Zookeeper. That was added by
> > > > https://github.com/apache/pulsar-helm-chart/pull/180 .
> > > > However, the workaround cannot be applied when TLS is enabled for
> > > > Zookeeper.
> > > >
> > > > Should we postpone switching to Apache Pulsar 2.8.2 in the Helm chart
> > > > until there's a fix for ZOOKEEPER-3988 /
> > > > https://github.com/apache/pulsar/issues/11070 ?
> > > >
> > > > BR,
> > > > Lari
> > > >
> > >
> >
>