Production and Consumption

Modo Foco

Tamanho da Fonte

Última atualização: 2025-12-24 15:07:56

﻿
Why Does the Message Trace Show a Production Record for a Specific Message but No Record of It Being Pushed to the Client?
This issue is typically caused by the following scenarios:
1. The consumer offset for this topic subscription was modified or reset (using the console or client), causing the current consumer offset to skip past this message. In this case, the message is effectively acknowledged.
2. The current topic has a message backlog, preventing produced messages from being immediately pushed to users. Additionally, the time-to-live (TTL) configured for the namespace where this topic resides is too short, causing messages to be automatically acknowledged before they can be pushed to users. In this scenario, it is necessary to analyze whether the message backlog meets expectations. If not, it is recommended to increase the consumption speed or increase the TTL value to ensure that messages can be promptly pushed to users.
3. The message is a delayed message, but the TTL configured for the current topic is shorter than the delay time. As a result, the message was automatically acknowledged before it could be pushed, resulting in the failure to push it to the client.
4. The subscription is configured with tag information. Due to the mismatch between the message's tag and the subscription, the current message is filtered out.
5. The current subscription mode is Key-Shared mode. However, the message preceding this one has not been acknowledged by the corresponding client. Due to the requirement to maintain message sequentiality for the same key, the current message cannot be pushed.
Why Is the Push Latency for Some Partitions of a Topic High in the Message Trace?
It is necessary to determine whether the current message is a delayed message and observe whether a message backlog exists in the partition. If the above metrics show no exceptions and the partition has a large number of subscriptions, check whether the current partition has reached the consumption TPS limit. Since the default consumption TPS limit for pro clusters is 10,000, the threshold is not reached in most cases. Only topics with exceptionally high traffic may encounter this issue. In such scenarios, increase the number of topic partitions and observe whether the issue is alleviated.
Why Do Producers Frequently Disconnect and Reconnect in a Short Period, and Why Do Some of the Produced Messages Have Many Duplicates?
The most common cause of this issue is that some produced delayed messages have a delay time exceeding 10 days. Earlier versions of SDKs do not adequately handle errors for production delays exceeding 10 days, causing subsequent messages after the delayed message to be repeatedly produced. It is recommended to check the logs for errors containing DELAY TIME IS TOO LONG. If such errors are found, review the configuration related to delayed messages in the code.
Why Do Redelivery Records Appear in the Console Message Traces When I Use Java SDK Version 2.x Without negativeAcknowledge() or ackTimeout() Configuration?
In the Java SDK of Pulsar 2.x, if a dead letter queue (DLQ) policy is configured, an automatic message redelivery mechanism with a default 30-second ackTimeout is enabled. When client code handles offline operations or compute-optimized tasks that require extended processing time before acknowledging messages, it may exceed this 30-second ackTimeout threshold, triggering message redelivery. For users who are sensitive to message redelivery and require DLQ functionality, it is recommended to upgrade the Java client to version 3.x.
Why Does the Pulsar Server Suddenly Stop Pushing Messages to Clients, with Partial or All Partitions Showing Zero Consumption Speed?
To balance performance across different topics and clients, Pulsar sets a default upper limit of unacknowledged messages (number of unack messages) per partition subscription for a topic. The default value is 5,000, as specified in the Use Limits. To check if a subscription has reached this upper limit, observe whether the number of unacknowledged messages for the subscription has hit the quota limit.
When the total number of unacknowledged messages for a subscription on a partition exceeds 5,000, the server will stop pushing messages to consumers of the partition's subscription. Unacknowledged messages refer to messages that have been pushed but not acknowledged by the client through ack(), negativeAcknowledge(), or reconsumeLater(). Common solutions include:
1. First, determine whether the messages are unacknowledged due to inherently long business processing times, or whether logical exceptions exist in the business code where messages are not promptly acknowledged, causing message gaps. To do so, obtain the msgId of gap messages from the topic partition subscription and then query the message content and push records in the message trace. For detailed information, see Gap Messages.
2. If the messages involve long processing times, gap messages are normal. As the upper limit of unacknowledged messages has been reached, horizontal scaling of consumers is required to enhance consumption capacity. In this case, it is recommended to reduce the ReceiverQueueSize configuration for individual clients, with a suggested value of 2,500 divided by the number of consumers.
3. If analysis of gap messages reveals that the business code of consumers failed to acknowledge messages in certain scenarios, you need to restart the consumer clients corresponding to the unacknowledged messages after you fix the acknowledgment-related logic in the consumer code and deploy a new version. After restarting, the server will automatically push the unacknowledged messages again.
Why Are Only a Few Consumers Receiving Messages While Dozens of Consumers Deployed Under the Same Subscription Remain Inactive?
This typically occurs due to excessively large default ReceiverQueueSize configurations on the consumers. While default ReceiverQueueSize values vary across client implementations, some are set as high as 1,000. Given that the default upper limit of unacknowledged messages per partition subscription is 5,000, if five clients (ReceiverQueueSize is set to 1,000 for each) simultaneously pull messages without performing acknowledgment operations, the upper limit is reached. Consequently, the server becomes unable to push messages to the remaining consumers.
Why Was a 1-Second Delayed Message Immediately Pushed to the Consumer Client Instead of Being Delayed by the Server?
For performance considerations, the current time precision configured in TDMQ for Apache Pulsar is 1 second. Therefore, the minimum delay time for a delayed message is 1 second. If a delay time shorter than 1 second is set, the message will be treated as a non-delayed message and pushed to the consumer immediately. For more information, see Usage Instructions and Limitations for Delayed Messages.
Why Has the Message Storage Size for a Topic Increased Significantly Despite No Notable Rise in Production Traffic?
If the user has not recently modified the TTL/retention policy of the namespace corresponding to this topic, the issue is typically caused by gap messages in certain subscriptions of the topic. Due to the mechanism of Pulsar, messages can only be deleted sequentially from oldest to newest. If a gap message occurs, the message and all earlier messages cannot be deleted, resulting in increased message storage size. For troubleshooting methods, see Gap Messages.
Why Does the Number of Retries of Existing Messages Reset to Zero After a Client Restart When negativeAcknowledge() for Redelivery Is Used?
When only one consumer exists under this subscription (more common in test scenarios), if this consumer restarts, the server will reset the redelivery count (RedeliveryCount) of all unacknowledged messages that have not entered the dead letter queue to zero. For more information, see Message Retry and Dead Letter Mechanisms.
Why Does the Error Unauthorized to validateTopicOperation for operation [xxx] on topic Occur When I Create a Producer or Consumer?
The current client token lacks the relevant permissions. You need to grant the corresponding role the production and consumption permissions for the specific namespace on the Namespace page. For more information, see Configuring Namespace Permissions. Note that if the user has configured retry queue or dead letter queue settings, since the consumer will acknowledge the original message and send new messages to the retry queue or dead letter queue, the corresponding role must have both the production and consumption permissions for the namespace.
Why Is the Client Unable to Connect to the Access Point of a Pro Cluster?
Pro Edition offers three types of access points:
1. Supporting environment access point (the domain name of the access point contains internal)
2. VPC environment access point (the domain name of the access point contains qcloud)
3. Public network environment access point (the domain name of the access point contains public)
VPC access points do not support cross-region access, while support environment access points and public network access points both support cross-region access. To enable cross-region access for VPC access points, you need to manually configure policies related to Cloud Connect Network (CCN). For more information, see Configuring DC/Cross-Region Access.
Why Does the Tag Filter of a New Consumer Override the Tag Filter of an Existing Consumer?
Message filtering is implemented at the subscription level. All consumers under the same subscription use the same tag filter criteria. If two consumers are created under the same subscription with different tag configurations, the tag of the later-created consumer will override the tag of the earlier one. To enable two consumers to use different tag filters, you need to create two separate subscriptions for this topic and configure different tags for these two subscriptions. For more information, see Tag Filtering.
﻿

Ajuda e Suporte

Esta página foi útil?

Você também pode entrar em contato com a Equipe de vendas ou Enviar um tíquete em caso de ajuda.

comentários

tencent cloud

TDMQ for Apache Pulsar

Production and Consumption

Why Does the Message Trace Show a Production Record for a Specific Message but No Record of It Being Pushed to the Client?

Why Is the Push Latency for Some Partitions of a Topic High in the Message Trace?

Why Do Producers Frequently Disconnect and Reconnect in a Short Period, and Why Do Some of the Produced Messages Have Many Duplicates?

Why Do Redelivery Records Appear in the Console Message Traces When I Use Java SDK Version 2.x Without negativeAcknowledge() or ackTimeout() Configuration?

Why Does the Pulsar Server Suddenly Stop Pushing Messages to Clients, with Partial or All Partitions Showing Zero Consumption Speed?

Why Are Only a Few Consumers Receiving Messages While Dozens of Consumers Deployed Under the Same Subscription Remain Inactive?

Why Was a 1-Second Delayed Message Immediately Pushed to the Consumer Client Instead of Being Delayed by the Server?

Why Has the Message Storage Size for a Topic Increased Significantly Despite No Notable Rise in Production Traffic?

Why Does the Number of Retries of Existing Messages Reset to Zero After a Client Restart When negativeAcknowledge() for Redelivery Is Used?

Why Does the Error `Unauthorized to validateTopicOperation for operation [xxx] on topic` Occur When I Create a Producer or Consumer?

Why Is the Client Unable to Connect to the Access Point of a Pro Cluster?

Why Does the Tag Filter of a New Consumer Override the Tag Filter of an Existing Consumer?

Ajuda e Suporte

tencent cloud

TDMQ for Apache Pulsar

Production and Consumption

﻿

Why Does the Message Trace Show a Production Record for a Specific Message but No Record of It Being Pushed to the Client?

Why Is the Push Latency for Some Partitions of a Topic High in the Message Trace?

Why Do Producers Frequently Disconnect and Reconnect in a Short Period, and Why Do Some of the Produced Messages Have Many Duplicates?

Why Do Redelivery Records Appear in the Console Message Traces When I Use Java SDK Version 2.x Without negativeAcknowledge() or ackTimeout() Configuration?

Why Does the Pulsar Server Suddenly Stop Pushing Messages to Clients, with Partial or All Partitions Showing Zero Consumption Speed?

Why Are Only a Few Consumers Receiving Messages While Dozens of Consumers Deployed Under the Same Subscription Remain Inactive?

Why Was a 1-Second Delayed Message Immediately Pushed to the Consumer Client Instead of Being Delayed by the Server?

Why Has the Message Storage Size for a Topic Increased Significantly Despite No Notable Rise in Production Traffic?

Why Does the Number of Retries of Existing Messages Reset to Zero After a Client Restart When negativeAcknowledge() for Redelivery Is Used?

Why Does the Error Unauthorized to validateTopicOperation for operation [xxx] on topic Occur When I Create a Producer or Consumer?

Why Is the Client Unable to Connect to the Access Point of a Pro Cluster?

Why Does the Tag Filter of a New Consumer Override the Tag Filter of an Existing Consumer?

Ajuda e Suporte

Why Does the Error `Unauthorized to validateTopicOperation for operation [xxx] on topic` Occur When I Create a Producer or Consumer?