-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[improve][pip] PIP-372: Allow consumers to terminally NACK a message, bypassing retries and routing directly to the DLQ #23133
base: master
Are you sure you want to change the base?
Conversation
@jcass8695 Please add the following content to your PR description and select a checkbox:
|
@jcass8695 This is a great feature. I have added the relevant methods for Java. BTW, the PIP number is conflicting with #23061. |
pip/pip-367.md
Outdated
### Metrics | ||
|
||
If the client would like to track the number of calls to the `Term` method, we could add a new metric | ||
`pulsar_client_consumer_terms`. This metric should in theory track exactly with the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pulsar_client_consumer_message_terms
It is recommended to keep the naming conventions consistent.
pulsar/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConsumerImpl.java
Lines 429 to 430 in d4bbf10
consumerDlqMessagesCounter = ip.newCounter("pulsar.client.consumer.message.dlq", Unit.Messages, | |
"The number of messages sent to DLQ", topic, attrs); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are all defined with underscores in the Go client library.
https://github.com/apache/pulsar-client-go/blob/master/pulsar/internal/metrics.go#L266-L270
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Java client is currently using OpenTelemetry's naming conventions. I suggest aligning it with the existing naming style.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that moving the Go client to be OTel compliant is outside the scope of this change. I think I would rather the Go client be consistent with itself. Changing all of the metrics to be OTel compliant can be done in a single non-backwards compatible change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I meant that the Java client should follow the current naming conventions. It would be best to also add a description for Java metrics.
|
I didn't see the related discussion on the mailing list. Please double-check if the email has been sent.
|
I've resent my email now, with the updated PIP number. |
@crossoverJie still no thread on the mailing list 😞 |
Below is the email that I've sent. Am I doing something wrong? This feels like it should be the easy step... |
@jcass8695 However, I did not see the email you send on the mailing list🤔. |
``` | ||
|
||
```java | ||
public interface Consumer<T> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please move the definition of the new API into the section Public API
|
||
# Links | ||
|
||
* Mailing List discussion thread: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please send an email for a discussion of this PIP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My email is not making it to the mailing lists. Please see above comments.
PIP: 372
Motivation
If a consumer consumes a message and fails during the processing of that message in a terminal way, we as the client in
certain scenarios may not want to retry that message later, we may want to send it directly to the DLQ. Currently, if
the client wanted a persistent record of the message, they would have to do one of:
I propose adding an interface that allows a consumer to terminally NACK a message, sending it directly to the DLQ instead of retrying.
Modifications
No modification yet.
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
Documentation
doc
doc-required
doc-not-needed
doc-complete
Matching PR in forked repository
PR in forked repository: