Storm's ACK and fail

In order to ensure that the data can be correctly processed, for each tuple generated by spout, Storm will be tracked, which involves ack/fail processing, if a tuple processing succeeds, will call spout Ack method, if failed, will call the Fail method. Every bolt that deals with a tuple will tell storm through Outputcollector that the current bolt processing is successful. To understand the relationship between the ack/fail of Outputcollector and the ack/fail of spout, I debugged and traced the storm code.

Ibasicbolt implementation class does not care about Ack/fail, spout Ack/fail is entirely determined by the ack/fail of the rear bolts. The Basicoutputcollector parameter of its Execute method also does not provide a Ack/fail method for you to invoke. The equivalent of ignoring the ack/fail behavior of the bolt. So Ibasicbolt used to do filter or simple calculation is more appropriate.

You can refer to the implementation in the Basicboltexecutor code to understand:
Java code public void execute (Tuple input) {_collector.setcontext (input);           try {_bolt.execute (input, _collector);       _collector.getoutputter (). ACK (input);           } catch (Failedexception e) {Log.warn ("Failed to process tuple", e);       _collector.getoutputter (). fail (input); }   }

In the Irichbolt implementation class, if Outputcollector.emit (Oldtuple, newtuple) is used to emit a tuple (called Anchoring in Storm), then the ack/of the rear bolt Fail affects spout's ack/fail, if Collector.emit (newtuple) launches a tuple (called unanchoring in Storm), it is equivalent to disconnecting the ack/of the back bolt The effect of fail on spout. Spout will immediately decide to invoke spout Ack/fail based on the ack/fail in front of the current bolt. So the success of bolts behind a bolt doesn't concern you, and you can ignore it in this way.

One of the bolts in the middle is fail, which does not affect the subsequent bolt execution, but immediately triggers the spout fail. The equivalent of a short-circuit, the back bolt although also carried out, but ack/fail to spout has no meaning. That is, if any of the bolt sets fail, the spout fail method is immediately triggered. The Ack method requires that all bolt calls be ack to be triggered.

Another point, Storm just through the ack/fail mechanism to tell the application of the middle of the bolt processing, the success/failure of how to deal with, must be determined by the application itself, because there is no data inside storm to save the failure, but there is a way to know the failure record, Because the Ack/fail method of spout is accompanied by a MsgId object, we can set the MsgId to tuple when the tuple is initially launched, and then process the tuple in Ack/fail.

Here is a problem, that is, each bolt after execution to explicitly call Ack/fail, otherwise the tuple does not release cause oom. Don't know when Storm was originally designed, why not set the ACK of the bolt to the default call