Dynamic sharding implementation

Please could you review the following proposal and tell me what do you think about it ?

Currently, Jedis doesn't support dynamic sharding.

If we want to add / remove a Redis server from the available shards, then the only way to achieve this is to stop the application, change the sharding configuration and then restart it.

This implementation allows various things like :
- to add / remove some servers without downtime for the application
- to externalize the Redis connectivity monitoring and adapt the sharding configuration in pseudo-realtime
- to centralize the sharding configuration for a cluster in a DB or something similar
- etc

This proposal delegates the sharding configuration to a component outside of Jedis and allow to dynamically update the sharding configuration without down time.

JedisDynamicShardsProvider class is doing the bridge between this component and Jedis internals.

The external component manages the sharding configuration the way it wants and when an update is required, it only has to call the relevant method add/removeShard( ) or setShards( ) on JedisDynamicShardsProvider.

Upon such a call, JedisDynamicShardsProvider then notify (when absolutely required) Sharded instances about such a change (inspired from the Observable / Observer pattern)

When Sharded handles such a notification, then all the read access on the shard configuration are blocked until it has finished to change the sharding configuration (ReentrantReadWriteLock usage).
Isn't this leaking resources? Don't you have to close them all rather than just clearing references to them here?