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 [email protected] or file a JIRA ticket
with INFRA.
---
