Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RedisAtomicLong throws a null pointer if key is removed [DATAREDIS-469] #1048

spring-projects-issues opened this issue Feb 26, 2016 · 1 comment
in: core type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Feb 26, 2016

Walt Davidson opened DATAREDIS-469 and commented

RedisAtomicLong throws a null pointer on get, if the key has been removed/expired from the underlying Redis store. It looks like an autoboxing issue, when jedis returns null as the value for the key.

The code is quite clear. operations.get(key); returns null, and java unboxing to an int throws a NullPointer .

// In RedisAtomicLong:152
public long get() {
	return operations.get(key);



Can be reproduced with a simple test

class RedisAtomicLongNullPointerTest extends GroovyTestCase {
    void testNewAtomicLong() {
        JedisConnectionFactory jedisConnectionFactory = new JedisConnectionFactory(port: 6379, hostName: "",usePool: false);
        // setup long
        def test = new RedisAtomicLong("test",jedisConnectionFactory, 1)
        assertThat(test.get(), equalTo(1L))  // this passes

        // delete key
        new StringRedisTemplate(jedisConnectionFactory).delete("test")

        try {
            assertThat(test.get(), equalTo(0L))    
        } catch (NullPointerException npe) {
            fail("Unexpected Null Pointer");  // fails here

Affects: 1.6.2 (Gosling SR2)

Referenced from: pull request #182

Backported to: 1.7.2 (Hopper SR2), 1.6.5 (Gosling SR5)

Copy link

@spring-projects-issues spring-projects-issues commented Mar 24, 2016

Mark Paluch commented

We need to take also other operations into account. Incrementing absent keys leads in Redis to 1> del key
(integer) 0> incr key
(integer) 1

which seems ok to me to return 1. Decrementing works similar. The only operation which is not guarded is getAndSet. At this time the new value is already set and the command returns null

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core type: bug
None yet

No branches or pull requests

2 participants