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.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
