This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

Hello everyone, for pulsar to run on k8s are there any recommendation on volume binding strategy (Dynamic/Static) that we should follow ?

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

I have a question on acking the message from inside the function. In my function config, I have

setProcessingGuarantees

to

MANUAL

and then inside my function all of my processing is async, including publishing to some output topics. The final callback I have on the `CompletableFuture`from the async processing calls this method:

public <T> T handle(T obj, Throwable ex, Context context){
        if (ex == null) {
            context.getCurrentRecord().ack();
            return obj;
        } else {
            context.getLogger().error("Error Processing record.", ex);
            context.getCurrentRecord().fail();
            return null;
        }
    }

Does all of that look like the right way to be acking / failing the record from inside a function using the

Context

? I ask because in my logs I'm seeing a lot of the following:

2023-02-08T14:13:09,961+0000 [pulsar-timer-6-1] INFO  org.apache.pulsar.client.impl.UnAckedMessageTracker - [ConsumerBase{subscription='bnr-url-function-sub', consumerName='45c52', topic='<persistent://q6/default/bnr_legacy'}>] 2634 messages will be re-delivered

However I'm not seeing error logs indicating that there were an equivalent number of message failures. I'm not seeing any failures right now, and I'm seeing many copies of the UnAckedMessageTracker logging that.

This message was deleted.

@David K Thank you. I'll save a reference to the message from the context when we start the function to be sure I am acking the "right" one.

This message was deleted.

Hi all! Pulsar Virtual Summit Europe is scheduled for May 23rd! More information here: https://apache-pulsar.slack.com/archives/C015MT1DE7N/p1675466741335729

This message was deleted.

👋 Hi everyone!

This message was deleted.

Benchmarks Errors - Producer

cluster2/broker1/bin/pulsar-perf produce -u <http://10.160.0.8:8080>,10.160.0.9:8080,10.160.0.10:8080 -r 10000 -m 100000  -threads 10 -z ZLIB -s 50000 <persistent://cpaas/email/mq>

Consumer

cluster1/broker1/bin/pulsar-perf consume -u <http://10.160.0.8:8080>,10.160.0.9:8080,10.160.0.10:8080 <persistent://cpaas/email/mq> -r 10000

On above Test case getting below error

2023-02-09T16:38:21,042+0530 [pulsar-perf-producer-exec-1-3] INFO  org.apache.pulsar.testclient.PerformanceProducer - Created 1 producers
2023-02-09T16:38:30,591+0530 [main] INFO  org.apache.pulsar.testclient.PerformanceProducer - Throughput produced:     920 msg ---     92.0 msg/s ---     35.1 Mbit/s  --- failure      0.0 msg/s --- Latency: mean: 5701.607 ms - med: 6281.375 - 95pct: 8017.151 - 99pct: 8879.295 - 99.9pct: 8879.807 - 99.99pct: 8907.007 - Max: 8907.007
[18.897s][warning][gc,alloc] pulsar-perf-producer-exec-1-2: Retried waiting for GCLocker too often allocating 524290 words
[19.107s][warning][gc,alloc] pulsar-perf-producer-exec-1-8: Retried waiting for GCLocker too often allocating 524290 words
[19.309s][warning][gc,alloc] pulsar-perf-producer-exec-1-9: Retried waiting for GCLocker too often allocating 524290 words

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.

@Igor Morozov When a producer publishes to a partitioned topic, it internally creates a producer on every single partition topic (under the covers). When a message is published, the partition it is routed to is determined by the messages key. All messages with the same key are batched together on the producer and sent to the broker where they are stored. This ensures per-key message order on the producer side.