scanAll() yields inconsistent results

Client Libraries Java Client
1

Hi All,

We face a problem with a scanAll results:

We have a set with 10000 records, aql confirms that the count is correct. However when running a scan using scanAll function we get different number of records each run. The number is close to but always is less than 10000 - it can be 9997, 9994, etc. records. The problem is persistent and can be reproduced with a minimal number of code lines below. There are no any other scans, queries or put/get operations during test running. Problem never happens on a set of 1000 records.

We use Aerospike Community Edition build 3.10.1 on 3-node cluster (Ubuntu 14) and I have tried Java client versions 3.1.5 and 3.3.2 – both produce same result. There is no apparent memory or disk problem on the cluster nodes.

Is this an expected behaviour? Is something wrong with the code snippet below (although it is mostly copy-paste from the sample) or probably it is a configuration problem?

I am relatively new with Aerospike and will highly appreciate any suggestion.

Thanks in advance, Lev … try { ScanPolicy scanPolicy = new ScanPolicy(); client.scanAll(scanPolicy, asNamespace, asSet, new ScanCallback() {

            public void scanCallback(Key key, Record record) throws AerospikeException {
                counter++;
            }
        }, new String[] {}) ;
        System.out.println("Total: "+ counter + " records in set " + asSet);
    }
    catch (AerospikeException e) {
        System.out.println("--Error: " + e.getMessage() );
    }

…

2

I haven’t seen that before, but then again I haven’t specifically tested for it. I assume the cluster was stable the entire time (no fd errors or cluster size differences)?

3

No errors and no size differences.

4

Multiple scan threads send data to your callback by default. Either set ScanPolicy.concurrentNodes = false or make counter atomic.

5

Thanks a lot, this is the case. Somehow was under impression that by default nodes accessed sequentially, not concurrently.