DATAREDIS-417 - ScanCursor throw " java.util.NoSuchElementException".

[oudb]

when scan big key with "match" options, redis server continuous return empty result，ScanCursor throw " java.util.NoSuchElementException"

[theWizK]

Any idea when this fix will be in a release build? I am affected by this bug.

[thanosa75]

+1; we're affected also

[christophstrobl]

tried to reproduce the error scanning 100.000, 661.607, 1.000.000, 1.000.001 and 1.299.827 keys in a Redis 3.0.3 instance with jedis 2.7.3 but did not come accross the mentioned exception. Any chance you can point me at a breaking piece of sample code?

[theWizK]

Were you using a connection pool or single connection? The code is pretty simple to get it to break. And it does not happen if you use a connection pool...

[thanosa75]

@christophstrobl we reproduce this using a namespace of 12M keys of HSETs. Using count < 1000 will reproduce it. Jedis 2.7.3, spring-data-redis 1.6.0.RELEASE, commons-pool2 2.4.2

don't know if this helps - you can "DEBUG POPULATE 10000000" to get to 10M keys in the format key:XXX and then do "SCAN 0 COUNT 1000 MATCH key:*3*" to see the cli cursor work. The ScanCursor will probably fail with count of 1000.

[christophstrobl]

@theWizK, @thanosa75 used a pool before - disabling did not change the result. will try different options for count as well. which server versions are you using?

[theWizK]

I think I have 2.8.3... I'll get the versions of client as well for you and a code sample if I can dig them back out.

[christophstrobl]

@theWizK that would be awesome. thanks!

[thanosa75]

@christophstrobl we use 3.0.4 on a simple configuration - no replication

[thanosa75]

@christophstrobl see this gist (https://gist.github.com/thanosa75/a16a011082167496ead8) for the setup and you need to execute the code from this link (mvn spring-boot:run on this project: https://dl.dropboxusercontent.com/u/51551585/dataredis417repro.zip) to get it reproduced.
It reproduces on my MacBook w/ OS X 10.10.5, Redis 3.0.4 (uses database 10)

[christophstrobl]

@thanosa75 thanks - will have a look tomorrow.

[christophstrobl]

@thanosa75 I see now. thanks!

[oudb]

@christophstrobl Hi,this is my sample code that can reproduce error:

    String key = "DATAREDIS-417";

    //generate test data
    stringRedisTemplate.delete(key);
    BoundZSetOperations ops = stringRedisTemplate.boundZSetOps(key);
    for(int i=0;i<1000;++i)
    {
        String value = "test:"+String.valueOf(i) + ":0";
        ops.add(value, i);
    }


    //scan data
    ScanOptions.ScanOptionsBuilder builder = ScanOptions.scanOptions();
    builder.match("*:1");
    Cursor<ZSetOperations.TypedTuple<String>> cursor = ops.scan(builder.build());
    while(cursor.hasNext()){
            ZSetOperations.TypedTuple<String> typedTuple = cursor.next();
            System.out.println(typedTuple.getValue());
    }

[christophstrobl]

@oudb thanks! would you (if you haven't done so yet) please sign the Spring ICLA form and add your CLA Number and name as a comment either here or to DATAREDIS-417. I can then take it from here - failing tests that get fixed by this PR are in place already.

[oudb]

@christophstrobl I posted CLA Number to https://jira.spring.io/browse/DATAREDIS-417?focusedCommentId=120594&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-120594

[christophstrobl]

thanks - merged to master and back ported to 1.5.x and 1.6.x

[FS1360472174]

still met with this problem in 1.6.1