* This implies a ceiling of 31 retries for storm.messaging.netty.max_retries.

* According to [this](https://github.com/brndnmtthws/storm/blob/88d23962f5f5f10505cefe2ef300a8f19b353bba/storm-netty/src/jvm/backtype/storm/messaging/netty/Client.java#L77), we can retry at most storm.messaging.netty.max_retries - 1 times, since we increment on the first re-try.  So the config is a bit of a misnomer.

* Newer versions of curator (starting with 1.0.15 I think) have a BoundedExponentialBackoffRetry.  Since we are using an older curator, we sub-classed ExponentialBackoffRetry to add the bounds [here](https://github.com/nathanmarz/storm/blob/master/storm-core/src/jvm/backtype/storm/utils/Utils.java#L313).  This was originally added so that workers coming up after a ZK failure would not overwhelm the ZK cluster. I wonder if we could re-use the `Util.BoundedExponentialBackoffRetry` here, since it is tested, or possibly just look at the implementation in the curator code?