Github user HeartSaVioR commented on the pull request: https://github.com/apache/storm/pull/365#issuecomment-68437760 @dashengju If we cannot tolerate single key operations restriction, there're some ways to settle. 1. check type and convert, from usage of Jedis We can check type (as you did) and convert JedisCommands to Jedis if available. pros. It's simplest way cons. Both handling Jedis and original (ex. Trident State) logic got mixed. 2. introduce CommandExecutor We can introduce CommandExecutor, and passes Jedis/JedisCluster into it. CommandExecutor implements and exposes available operations, such as get / set / mget / mset / hset / hget / etc. (ex. If Jedis is passed, CommandExecutor.mget() calls actual mget(), but if JedisCluster is passed, CommandExecutor.mget() runs loop and calls get() for each key. ) pros. We can separate "handling Jedis" and "original logic". cons. We have to implement additional component, which adds complexity. 3. Drop support for ShardedJedis, JedisCluster We can drop support for ShardedJedis and JedisCluster, and postpone this issue. pros. There're no limit to use Jedis directly. We can use Pipeline if we need higher speed and requests could be batched. cons. State repository is restricted to one instance of Redis. Please add any alternative approaches or let me hear your opinions. :D Surely anyone can participate this discussion.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---