[
https://issues.apache.org/jira/browse/STORM-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379491#comment-14379491
]
Jungtaek Lim commented on STORM-723:
------------------------------------
[~dashengju]
There's one difference, with 'expire on key' key (string, hash, list, sorted
set, and so on) itself will be expired which means all elements are expired,
too.
In other word, we can't control each element's expiration on data types.
Btw, with your scenario, if you don't need to store user information it's
better to use 'incr' and 'get' instead of using Set operation.
We can add new CountUpdater / CountQuerier to accomplish this, but we can let
user implement it.
What do you think?
> [storm-redis] RedisStateSetUpdater writes state into String but calls Set
> operation
> -----------------------------------------------------------------------------------
>
> Key: STORM-723
> URL: https://issues.apache.org/jira/browse/STORM-723
> Project: Apache Storm
> Issue Type: Bug
> Affects Versions: 0.10.0
> Reporter: Jungtaek Lim
> Assignee: Jungtaek Lim
>
> RedisStateSetUpdater writes value into String type, but it tries to retrieve
> Set's element count from String type which will throw JedisDataException.
> {code}
> if (this.expireIntervalSec > 0) {
> jedis.setex(redisKey, expireIntervalSec, value);
> } else {
> jedis.set(redisKey, value);
> }
> Long count = jedis.scard(redisKey);
> {code}
> Btw, Redis expire only applies to key, so above implementation seems to be
> invalid.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
