[
https://issues.apache.org/jira/browse/STORM-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262122#comment-14262122
]
ASF GitHub Bot commented on STORM-609:
--------------------------------------
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.
> add storm-redis to storm external
> ---------------------------------
>
> Key: STORM-609
> URL: https://issues.apache.org/jira/browse/STORM-609
> Project: Apache Storm
> Issue Type: New Feature
> Affects Versions: 0.10.0
> Reporter: DashengJu
> Assignee: DashengJu
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
