[
https://issues.apache.org/jira/browse/STORM-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404427#comment-15404427
]
ASF GitHub Bot commented on STORM-2014:
---------------------------------------
GitHub user srdo opened a pull request:
https://github.com/apache/storm/pull/1605
STORM-2014: Put logic around dropping messages into RetryService, rem…
…ove maxRetry setting from new KafkaSpout
https://issues.apache.org/jira/browse/STORM-2014
This PR removes maxRetry from the KafkaSpout and changes the RetryService
interface slightly so the schedule method can communicate back to the spout
that the message should be dropped. Retry logic belongs to the RetryService
interface, and it's nice for users if they can easily plug in their own
handling of messages that will be dropped (custom logging for example).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/srdo/storm STORM-2014
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/storm/pull/1605.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1605
----
commit 432f932a70b0bd21f06cd6f36386404eab194e0a
Author: Stig Rohde Døssing <[email protected]>
Date: 2016-08-02T17:17:02Z
STORM-2014: Put logic around dropping messages into RetryService, remove
maxRetry setting from new KafkaSpout
----
> New Kafka spout duplicates checking if failed messages have reached max
> retries
> -------------------------------------------------------------------------------
>
> Key: STORM-2014
> URL: https://issues.apache.org/jira/browse/STORM-2014
> Project: Apache Storm
> Issue Type: Improvement
> Components: storm-kafka
> Reporter: Stig Rohde Døssing
> Assignee: Stig Rohde Døssing
> Priority: Minor
>
> The new Kafka spout has a RetryService interface that should make logic
> around retrying tuples pluggable. The RetryServiceExponentialBackoff class
> has code for setting a max retry count, and dropping messages once they reach
> the retry limit. This functionality is duplicated by the spout in the fail
> method, which means that the user must set different maxRetries for the
> RetryService and the spout in order for the RetryService code to be hit when
> dropping messages.
> I think the retry logic belongs in the RetryService interface, and should be
> removed from the spout. It would also be good if the RetryService could
> indicate if a message will be retried or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
