[
https://issues.apache.org/jira/browse/STORM-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822391#comment-15822391
]
Roshan Naik commented on STORM-2282:
------------------------------------
That does look like a nice way to setup the retry policy and DLQ.
Unclear about the second piece of code there at "stream api level' .. which
kind of errors would streams[1] contain ?
> Streams api - provide options for handling errors
> -------------------------------------------------
>
> Key: STORM-2282
> URL: https://issues.apache.org/jira/browse/STORM-2282
> Project: Apache Storm
> Issue Type: Sub-task
> Reporter: Arun Mahadevan
>
> Adding relevant discussions from PR 1693 below.
> Allow users to be explicit about how to handle errors. I don't know if any
> API out there does it... so this would be unique to Storm.
> In short:
> Broadly speaking there are two kinds of tuple process errors that the users
> need to be concerned about:
> 1- Retry worthy Errors - For instance, failure to deliver to destination
> service due to connection issues.
> 2- Not worth retrying - For instance, Parsing errors due to bad data in the
> tuple. These problems can jam up the pipeline if they are retried repeatedly.
> Such tuples can be sent to a configurable Dead-Letter-Queue.
> ---
> >1- Retry worthy Errors
> Right now theres no explicit `fail` api. When a stage in the stream completes
> processing (and possibly emits results), the underlying tuples are acked
> automatically. The only way spout will re-emit is after the message timeout.
> It may be good to have a fail fast api, but I am not sure how it would help.
> The replayed tuple could fail again in processing. Instead the processing
> logic itself can have some retry logic (say retry 3 times) and forward to an
> error stream and ack the tuple.
> > 2- Not worth retrying
> This can be handled via branch logic. E.g. send valid values to stream1 and
> bad values to stream2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
