pulsar.consumer.ackReceiptEnabled |
false |
Boolean |
Acknowledgement will return a receipt but this does not mean that the message will not be resent after getting the receipt. |
pulsar.consumer.ackTimeoutMillis |
0 |
Long |
The timeout (in ms) for unacknowledged messages, truncated to the nearest millisecond. The timeout needs to be greater than 1 second. By default, the acknowledge timeout is disabled and that means that messages delivered to a consumer will not be re-delivered unless the consumer crashes. When acknowledgement timeout being enabled, if a message is not acknowledged within the specified timeout it will be re-delivered to the consumer. |
pulsar.consumer.acknowledgementsGroupTimeMicros |
100000 |
Long |
Group a consumer acknowledgment for a specified time (in μs). By default, a consumer uses 100μs grouping time to send out acknowledgments to a broker. If the group time is set to 0 , acknowledgments are sent out immediately. A longer ack group time is more efficient at the expense of a slight increase in message re-deliveries after a failure. |
pulsar.consumer.autoAckOldestChunkedMessageOnQueueFull |
false |
Boolean |
Buffering a large number of outstanding uncompleted chunked messages can bring memory pressure and it can be guarded by providing this pulsar.consumer.maxPendingChunkedMessage threshold. Once a consumer reaches this threshold, it drops the outstanding unchunked-messages by silently acknowledging if pulsar.consumer.autoAckOldestChunkedMessageOnQueueFull is true. Otherwise, it marks them for redelivery. |
pulsar.consumer.autoScaledReceiverQueueSizeEnabled |
true |
Boolean |
This option is enabled by default. The consumer receiver queue size is initialized with 1, and will double itself until it reaches the value set by pulsar.consumer.receiverQueueSize . The feature should be able to reduce client memory usage. |
pulsar.consumer.consumerName |
(none) |
String |
The consumer name is informative and it can be used to identify a particular consumer instance from the topic stats. |
pulsar.consumer.cryptoFailureAction |
FAIL |
Enum |
The consumer should take action when it receives a message that can not be decrypted.FAIL : this is the default option to fail messages until crypto succeeds.DISCARD : silently acknowledge but do not deliver messages to an application.CONSUME : deliver encrypted messages to applications. It is the application's responsibility to decrypt the message.
Fail to decompress the messages. If messages contain batch messages, a client is not be able to retrieve individual messages in batch. The delivered encrypted message contains EncryptionContext which contains encryption and compression information in. You can use an application to decrypt the consumed message payload.
Possible values: |
pulsar.consumer.deadLetterPolicy.deadLetterTopic |
(none) |
String |
Name of the dead topic where the failed messages are sent. |
pulsar.consumer.deadLetterPolicy.maxRedeliverCount |
(none) |
Integer |
The maximum number of times that a message are redelivered before being sent to the dead letter queue. |
pulsar.consumer.deadLetterPolicy.retryLetterTopic |
(none) |
String |
Name of the retry topic where the failed messages are sent. |
pulsar.consumer.expireTimeOfIncompleteChunkedMessageMillis |
60000 |
Long |
If a producer fails to publish all the chunks of a message, the consumer can expire incomplete chunks if the consumer cannot receive all chunks in expire times (default 1 hour, in ms). |
pulsar.consumer.maxPendingChunkedMessage |
10 |
Integer |
The consumer buffers chunk messages into memory until it receives all the chunks of the original message. While consuming chunk-messages, chunks from the same message might not be contiguous in the stream and they might be mixed with other messages' chunks. So, consumer has to maintain multiple buffers to manage chunks coming from different messages. This mainly happens when multiple publishers are publishing messages on the topic concurrently or publishers failed to publish all chunks of the messages. For example, there are M1-C1, M2-C1, M1-C2, M2-C2 messages.Messages M1-C1 and M1-C2 belong to the M1 original message while M2-C1 and M2-C2 belong to the M2 message. Buffering a large number of outstanding uncompleted chunked messages can bring memory pressure and it can be guarded by providing this pulsar.consumer.maxPendingChunkedMessage threshold. Once, a consumer reaches this threshold, it drops the outstanding unchunked messages by silently acknowledging or asking the broker to redeliver messages later by marking it unacknowledged. This behavior can be controlled by the pulsar.consumer.autoAckOldestChunkedMessageOnQueueFull option. |
pulsar.consumer.maxTotalReceiverQueueSizeAcrossPartitions |
50000 |
Integer |
The maximum total receiver queue size across partitions. This setting reduces the receiver queue size for individual partitions if the total receiver queue size exceeds this value. |
pulsar.consumer.negativeAckRedeliveryDelayMicros |
60000000 |
Long |
Delay (in μs) to wait before redelivering messages that failed to be processed. When an application uses Consumer.negativeAcknowledge(Message) , failed messages are redelivered after a fixed timeout. |
pulsar.consumer.poolMessages |
false |
Boolean |
Enable pooling of messages and the underlying data buffers. |
pulsar.consumer.priorityLevel |
0 |
Integer |
Priority level for a consumer to which a broker gives more priorities while dispatching messages in the subscription. The broker follows descending priorities. For example, 0=max-priority, 1, 2,...
Example 1 If a subscription has consumer A with priorityLevel 0 and consumer B with priorityLevel 1, then the broker only dispatches messages to consumer A until it runs out permits and then starts dispatching messages to consumer B. Example 2 Consumer Priority, Level, Permits
C1, 0, 2
C2, 0, 1
C3, 0, 1
C4, 1, 2
C5, 1, 1
The order in which a broker dispatches messages to consumers is: C1, C2, C3, C1, C4, C5, C4. |
pulsar.consumer.properties |
|
Map |
A name or value property of this consumer. properties is application defined metadata attached to a consumer. When getting a topic stats, associate this metadata with the consumer stats for easier identification. |
pulsar.consumer.readCompacted |
false |
Boolean |
If enabling readCompacted , a consumer reads messages from a compacted topic rather than reading a full message backlog of a topic. A consumer only sees the latest value for each key in the compacted topic, up until reaching the point in the topic message when compacting backlog. Beyond that point, send messages as normal. Only enabling readCompacted on subscriptions to persistent topics, which have a single active consumer (like failure or exclusive subscriptions). Attempting to enable it on subscriptions to non-persistent topics leads to a subscription call throwing a PulsarClientException . |
pulsar.consumer.receiverQueueSize |
1000 |
Integer |
Size of a consumer's receiver queue. For example, the number of messages accumulated by a consumer before an application calls Receive . A value higher than the default value increases consumer throughput, though at the expense of more memory utilization. |
pulsar.consumer.replicateSubscriptionState |
false |
Boolean |
If replicateSubscriptionState is enabled, a subscription state is replicated to geo-replicated clusters. |
pulsar.consumer.retryEnable |
false |
Boolean |
If enabled, the consumer will automatically retry messages. |
pulsar.consumer.subscriptionMode |
Durable |
Enum |
Select the subscription mode to be used when subscribing to the topic.Durable : Make the subscription to be backed by a durable cursor that will retain messages and persist the current position.NonDurable : Lightweight subscription mode that doesn't have a durable cursor associated
Possible values: |
pulsar.consumer.subscriptionName |
(none) |
String |
Specify the subscription name for this consumer. This argument is required when constructing the consumer. |
pulsar.consumer.subscriptionProperties |
(none) |
Map |
Subscription properties is an optional attribute, which can be set when subscribing to topic. These properties cannot be modified. We can only delete the subscription and create it again. |
pulsar.consumer.tickDurationMillis |
1000 |
Long |
Granularity (in ms) of the ack-timeout redelivery. A greater (for example, 1 hour) tickDurationMillis reduces the memory overhead to track messages. |