[
https://issues.apache.org/jira/browse/STORM-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17107309#comment-17107309
]
Simon Cooper commented on STORM-3637:
-------------------------------------
I've got a workaround that adds an option to make the input queue unbounded, so
avoids backpressure turning on -
https://github.com/thecoop/storm/commit/61bac97e8fc6103254478417585a9dbaa5b14887.
Thoughts on this appreciated (I was going to re-use the
`topology.backpressure.enabled` option, but that's deprecated and does a
slightly different thing)
This does require some other way to limit the processing speed - we're using
the `topology.max.spout.pending` option to limit the total number of tuples in
the topology at once, and so putting a bound on the queue sizes required.
> Looping topology structure can cause backpressure to deadlock
> -------------------------------------------------------------
>
> Key: STORM-3637
> URL: https://issues.apache.org/jira/browse/STORM-3637
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-core
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Simon Cooper
> Priority: Major
>
> When you have a topology structure with loops in it (BoltA and BoltB send
> tuples to each other), it can cause backpressure to deadlock.
> The scenario is that BoltA suddenly takes a long time to process a tuple (in
> our situation, it's doing a database operation). This causes the task input
> queue to fill up, setting the backpressure flag.
> BoltB, which is sending a tuple to BoltA, then cannot send, and the tuple is
> held in the emit queue. This blocks any tuples behind it, and also stops
> BoltB from executing. This means the input queue to BoltB will build up,
> until that backpressure flag is also set - and then when BoltA next wants to
> send a tuple to BoltB, it will irrevocably deadlock.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
