[
https://issues.apache.org/jira/browse/STORM-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942127#comment-16942127
]
Stig Rohde Døssing commented on STORM-3514:
-------------------------------------------
I think you should reconsider whether you want to use that configuration. When
you disable message timeouts, any unacked tuple will stay in the spout's
pending set forever. Once you hit the max spout pending limit, the spout will
stall permanently. As tuples may fail to be acked due to both coding errors and
runtime network issues (e.g. a lost message from an acker), this will likely
happen at some point during your topology's lifetime. I'm wondering if this is
what you're seeing?
Disabling message timeouts can be useful if you've also disabled acking, as you
then save a bit of processing, but if you have acking enabled you probably
don't want to disable timeouts.
> "topology.enable.message.timeouts: false" has no effect on ackers
> -----------------------------------------------------------------
>
> Key: STORM-3514
> URL: https://issues.apache.org/jira/browse/STORM-3514
> Project: Apache Storm
> Issue Type: Bug
> Affects Versions: 1.2.3
> Reporter: Evgheni Melman
> Priority: Major
>
> "topology.enable.message.timeouts: false" does prevent tuples from being
> failed if not acked in "topology.message.timeout.secs" seconds, but it still
> prevents __ackers from acking anchored tuples to the spout. When used with
> "topology.max.spout.pending" this effectively stalls the spout completely as
> the tuple is neither failed, nor acked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
