If this is set to true, this means that a bolt will ack a tuple as soon as it is received and processing begins; otherwise, the tuple will be acked when the bolt completes.
If true, the topology will anchor tuples in all flatMap bolts and ack in the final sink bolt.
When a bolt is prepared, these metrics will be use by being called with the TopologyContext for the storm bolt.
Maximum number of elements to execute in a given second per task
This signals that the storm bolts should use localOrShuffleGrouping, which means that if the downstream bolt has a task on the same local worker, the output will only go to those tasks.
This signals that the storm bolts should use localOrShuffleGrouping, which means that if the downstream bolt has a task on the same local worker, the output will only go to those tasks. Otherwise, shuffling happens normally. This is important to understand as this can create hot spots in the topology.
This workaround is necessary because val parameters can't be call-by-name.
This workaround is necessary because val parameters can't be call-by-name. We pass a function so that the metrics aren't serialized. Beyond the storm IMetric not being serializable, passing a value also causes problems with the instance registered in the bolt being different from the one used in the summingbird job.
See FlatMapOptions.scala for an explanation.
If this is set to true, this means that a bolt will ack a tuple as soon as it is received and processing begins; otherwise, the tuple will be acked when the bolt completes. Acking signals to storm that a tuple has been fully processed, so if a tuple is acked on entry and then there is a failure it will not be replayed per storm's normal replay mechanisms.