@Gvain,

For an unacked topology, we can either block, drop, or store. before this patch, storm will always store, so there are potential OOM like you described. this patch steps a bit forward, if the downstream machine is down, it will block the upstream from sending thus avoiding OOM. 

But for the case you mentioned, the downsteam is slow, but not down, it is possible that there will be more message pending at the netty client side or server side. If the network is OK, then it will pend on the server side, if the network is overwhelmed, then the message will be pending at the netty client side. 

An example is that the spout crazyly generate really big message, but the bandwidth is not enough, it will lead to OOM on the spout worker JVM, and nothing can stop that.

Bobby's comment mentioned a similar situation https://github.com/apache/incubator-storm/pull/103#issuecomment-43632986, 

We should allow user to config to drop message in this case, thus avoiding OOM,  this bug is filed at followup jira https://issues.apache.org/jira/browse/STORM-329 after discussion with Bobby.