Problem with expiring records in memory-only namespace - "n_bytes_memory went negative"

Hi, We have a namespace configured to store data in memory only with couple of minutes default ttl. After starting putting some data into it, when expiration kicks in, we’re getting these messages in the log (a lot, for ~30% of expired records):

WARNING (namespace): (namespace.c::762) set_id 1 - n_bytes_memory went negative!

Any advice what might be the reason?

Update: I’ve prepared simple setup for reproducing this: GitHub - akkomar/aerospike-test - it contains server configuration with instructions on running it in Docker container + small client app for loading some random data.

Update2: It seems that it’s happening only if I update records via UDF. The simplest one that reproduces this:

local VAL_KEY = "v"

function add_data(rec, val_to_add, ttl_to_set)
    if aerospike:exists(rec) then
        rec[VAL_KEY] = val_to_add

        aerospike:update(rec)
    else
        rec[VAL_KEY] = val_to_add

        aerospike:create(rec)
    end

end

Also, when I execute the same operation via Java API - everything seems to work fine (example github repo mentioned earlier is updated with Java API example) /cc @wchu

Thanks. Will take a look. What version of the server did you try this with?

3.6.4 and 3.7.0.1 - the latter in Docker setup from Github (btw. I’ve just fixed readme there with commands for starting everything)

Can you do a quick try with 3.7.4 (latest) and see if the issue is there?

Still there on 3.7.4 (tested by modifying your docker image from: GitHub - aerospike/aerospike-server.docker: Dockerfile for Aerospike Server Community Edition)

@akkomar Thank you for the helpful information! The problem was that for UDFs we were not properly accounting for key storage when adjusting the memory usage total on record creation. We’ve fixed this and the fix will be part of an upcoming release.

@brad Is this fixed in 3.7.4.1 under “[AER-4812] - (UDF) Update does not correctly account for stats.”?

Yes, the 3.7.4.1 release contains the fix. Thanks again.