[
https://issues.apache.org/jira/browse/STORM-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185652#comment-15185652
]
ASF GitHub Bot commented on STORM-1608:
---------------------------------------
Github user revans2 commented on the pull request:
https://github.com/apache/storm/pull/1190#issuecomment-193941111
@arunmahadevan I agree mostly with @ptgoetz I wanted to understand the
contract (thanks for the link), and that the new contract is consistent with
our current contract. On the acking side it feels like it now is consistent,
but not on the anchoring side. AnchoringOutputCollector in
CheckpointTupleForwarder will anchor non-anchored tuples to the last
inputTuple. I can see lots of situations where this is neither expected nor
correct for an IRichBolt. A shell bolt for example would totally get this wrong
because it does ansync processing. If we really want to disallow tuples that
are not tracked I would prefer to have an exception thrown rather than "fix"
the issue on the fly and possibly get it wrong.
Part of my confusion came from me assuming that we supported state
checkpointing without requiring at least once processing. It feels like we
should be able to support that with some kind of a best effort state
checkpointing, but now I understand the current limitations and that it would
be a separate feature.
> Fix stateful topology acking behavior
> -------------------------------------
>
> Key: STORM-1608
> URL: https://issues.apache.org/jira/browse/STORM-1608
> Project: Apache Storm
> Issue Type: Bug
> Affects Versions: 1.0.0, 2.0.0
> Reporter: Arun Mahadevan
> Assignee: Arun Mahadevan
>
> Right now the acking is automatically taken care of for the non-stateful
> bolts in a stateful topology. This leads to double acking if BaseRichBolts
> are part of the topology. For the non-stateful bolts, its better to let the
> bolt do the acking rather than automatically acking.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
