This message was deleted.

This message was deleted.

This message was deleted.

We are at 1.8.0 node client. While bringing up the application we are creating a set of producers(they can be already there in pulsar). During this process few producers are created(if not already there) ok but get stick after that. Is this known issue?

This message was deleted.

This message was deleted.

can someone help me with this pr https://github.com/apache/pulsar/pull/19605? The job keeps failing

Pulsar SQL :: Pulsar Presto Connector Packaging .... FAILURE

https://github.com/apache/pulsar/actions/runs/4610589145/jobs/8153115665?pr=19605 The pr doesn't have anything to do with Pulsar IO module.

Hi We ran into a similar issue that we have previously ran into before. Pulsar is not able to move the cursor forward. Please see the screenshot below. The cursors got stuck all at the same position across multiple subscriptions

All of these consumers are using the golang client v0.8.1

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

Hello, do I need to specify a tokenAuthClaim for a serperate function worker running with authentication enabled. Not seeing a configuration for something like that as there is for the broker.

Hi all, I'm getting really slow transaction performance, it never gets above about 1/sec. I'm testing with

bin/pulsar-perf transaction --topics-c dev/testns/test --topics-p dev/testns/test -threads 1 -ntxn 50 -ss testSub  -nmp 1 -nmc 1

, which on a standalone docker cluster gets a few hundred a second without an issue. Any suggestions for where to look for the cause? There's very little in the logs on broker or bookies related to it, nothing helpful to me at least. It does seem to be a new thing, I don't recall ever running into problems on this cluster before, but there's been no config changes to my knowledge. Broker pods haven't been restarted in over a month so there's certainly no change to config files, and I'm testing in a new namespace so settings are at default there.

Effectively-once semantics is a feature in Apache Pulsar that ensures that messages are processed and delivered only once, even in the face of failures and retries. It guarantees that messages are processed exactly once, avoiding duplicates and inconsistencies in the system. In Apache Pulsar, effectively-once semantics is achieved through a combination of features such as message deduplication which ensires that if a producers sends duplicate messages, that only one copy is retained, combined with transactional producers and consumers. When a message is consumer by a transactional consumer, it is assigned a unique transaction ID that is used to ensure that the message is processed exactly once. If a failure occurs during message processing, the transaction is rolled back along with any corresponding output messages, ensuring that it is not processed multiple times.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

Is it normal to test the performance of the 4-core 4G virtual machine pulsar standalone service using pulsar perf with a result of 152.361 msg/s to 1.190 Mbit/s?

This message was deleted.

This message was deleted.

This message was deleted.