Github user ptgoetz commented on the pull request:
https://github.com/apache/storm/pull/1190#issuecomment-193934901
@arunmahadevan Can you document the behavior of non-stateful bolts in a
topology with stateful bolts?
In a traditional topology (i.e. one that does not include stateful bolts),
for `IBasicBolt` instances input tuples are automatically ack'ed and output
tuples are automatically anchored to the input tuple. For `IRichBolt`
instances, anchoring and ack'ing is left to the implementation.
I feel (and I think @revans2 is alluding to the same) that that contract
must be maintained when adding stateful bolts to a topology. (I believe with
this patch it is, please correct me if I'm wrong).
The seconds question is what are `IStatefulBolt` implementations expected
to do in terms of ack'ing/anchoring? Since the output collector handed to
`IStatefulBolt` is an instance of `OutputCollector` (as opposed to
`BasicOutputCollector`) one would assume that ack'ing/anchoring is the
responsibility of the implementation (the `ack()` and `fail()` methods are
visible in `OutputCollector` but not `BasicOutputCollector`).
If that is not the case (i.e. if stateful bolts are not expected to handle
ack'ing/anchoring) it would be best to give `IStatefulBolt`s an output
collector implementation that does not expose the ack'ing/anchoring API,
similar to the relationship of `IBasicBolt`/`BasicOutputCollector`.
Does that make sense?
---
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.
---
