@mjschmidt so one of the design choices we made for the streamlet API was to move away from the concept of spouts/bolts towards the concepts of sources and sinks to better support state and effectively once processing provided chandy/lamport style state snapshotting. Acking was more natural spout and bolt APIs where managed state by heron isn't available while not so much for the functional style APIs used in Streamlets Acking also doesn't gel well with the state implementation since state snapshotting is provided by chandy/lamport global snapshotting. Perhaps @srkukarni can also chime in.

@jerrypeng So lets say I as a Heron analytic developer want to guarantee that all of the data sent from one container is received in the next? In the topology model this was done through ack and fail. It is a capability that will be required for us to move to the Streamlet API/Heron. If we put a pull request in and have it as a feature that is turned off by default would you guys be open to a merge request? If not how can we get similar functionality from Streamlet?

@jerrypeng @maosongfu @nwangtw - can you respond?

@mjschmidt - this is due to the underlying bolt implementation that streamlet maps into. Currently these bolts do not ack or fail when the topology is set to ATLEAST_ONCE. We need to fix this.

@mjschmidt so just to be clear. The streamlet API currently does not have a way for users to explicitly fail a tuple but it will automatically ack tuples for you but there is no call back to ack at the source. If you want, I am open to the idea of having a source that have ack and fail callbacks

Cool. Knowing that we can get this pulled back into the master branch means we can work on implementing it. We will stay connected in the heronstreaming channel as we move forward. Thanks!