Github user srdo commented on a diff in the pull request:
    --- Diff: 
    @@ -330,11 +328,9 @@ public void ack(Object messageId) {
         public void fail(Object messageId) {
             final KafkaSpoutMessageId msgId = (KafkaSpoutMessageId) messageId;
    -        if (msgId.numFails() < maxRetries) {
    -            msgId.incrementNumFails();
    -            retryService.schedule(msgId);
    -        } else { // limit to max number of retries
    -            LOG.debug("Reached maximum number of retries. Message [{}] 
being marked as acked.", msgId);
    +        msgId.incrementNumFails();
    +        if (!retryService.schedule(msgId)) {
    +            LOG.debug("Retry service indicated message should not be 
retried. Message [{}] being marked as acked.", msgId);
    --- End diff --
    @hmcl I was referring to RetryService being an interface users can 
override, which doesn't mention max retries in the schedule javadoc, and this 
part of the code technically not "knowing about" max retries, because users may 
supply a retry service that doesn't schedule tuples for some other reason. I 
think you're right though, it was probably clearer before.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

Reply via email to