Bus error: 10 using as_query. about aerospike-client-c

[mullanaphy]

Edit: I should mention I updated to 3.0.72 yesterday (since there seems there was a memory leak that was fixed with as_query) and this is on OS X 10.9.4.

[cstivers78]

We will look into this issue. Sorry for the late response.

To clarify, when you say limit, you are really just attempting to limit using the predicate for the as_query_where(), correct?

We have had success (both ourselves and customers) in running queries which returns very large result sets. But I believe these were run on Linux environments, not Mac. So, we will try to reproduce with similar environment. The more details you provide, the easier it will be for us to reproduce the issue.

We will run some tests to see if we can reproduce the issue on a Mac using the 3.0.72 client. Do you know which version of the database server you are using? Also, how are you running the database server, via our vagrant box, a VM or bare metal?

Thanks,
Chris

[mullanaphy]

Thanks for getting back to me.

The limit referenced was just doing the as_query_where(query, key, integer_range(start, end)); (limit being start - end = 1000).

The database itself is on a CentOS 6 machine, it was a patched version 3.3.8-39-gf1663d0 (the patch that fixed reading from disk on a node crash). Which has now been upgraded to 3.3.13 although we dumped all the data and are currently reimporting so I cannot test it yet. If it works on CentOS 6 then that'll be fine since this task will actually be a cron that runs on a few CentOS 6 machines.

So:
Client: version 3.0.72 on OS X 10.9.4
Database: version 3.3.8-39-gf1663d0 on an 8 node CentOS release 6.5 (Final).
Query: 2 int64 numbers for start/end, data coming back is just a hash of numbers (1 is int64).

[mullanaphy]

Okay, going to close this issue. Upgraded to the latest C client as well as upgraded our Aerospike nodes, deleted all of our data and started a new. Doing batches of 50000 now and it looks to be doing what I'd expect so guessing it was an older version issue. Once all of the data is in (~300m records) then I'll be able to really know for sure but so far with ~10% of the data no issues knock on wood.