Github user srdo commented on the issue:
https://github.com/apache/storm/pull/2790
@uddhavarote I wasn't sure if anyone needed the ability to emit new tuples
after writing to Kafka, because you can still do further processing by adding
another topology (or a new spout to your current topology) that reads from your
target topic. There are some minor drawbacks to doing more processing after
writing to Kafka the way your snippet does it. Either you emit the new tuple
unanchored and you won't get at-least-once processing for the part of the
topology after the KafkaBolt, or you anchor it to the input tuple like you do
in your snippet, and risk adding the same tuples to Kafka multiple times. If
the bolt after the KafkaBolt fails the tuple, the entire topology is repeated,
including the KafkaBolt.
I'm not opposed to adding the collector to `prepare` as well as giving you
access to the input tuple in the callback, but I think you should be aware of
the drawbacks of laying out your topology like this.
Just for illustration, what I'm proposing is this
```
Data Source -> Your topology here -> KafkaBolt -> Topic A -> KafkaSpout ->
Bolt handling metadata timestamp
```
rather than
```
Data Source -> Your topology here -> KafkaBolt -> Topic A
-> Bolt handling metadata
timestamp
```
---
