Aerospike.Client.AerospikeException: (Error Code 4: Parameter error) when I call AerospikeClient.Add


#1

Hi,

I have recently upgraded our aerospike server to 3.10.1 version, but since the upgrade time i sometimes got an aerospike exception (Error Code 4: Parameter error) when I call AerospikeClient.Add method while in the last version i didn’t got this exception at all

can anyone tell me why this is happening?


#2

Can you share some code snippet? (“Sometimes” makes me wonder if you are calling Add() on a bin that for some records is not holding an integer value.)


#3

You should look in the error log of the server to get some additional information.


#4

below is a code snippet:

Aerospike.Client.AerospikeClient client = new Aerospike.Client.AerospikeClient({myAeroSpikeServerIP}, 3000);

Aerospike.Client.WritePolicy writePolicy = new Aerospike.Client.WritePolicy(); writePolicy.expiration = 1296000; writePolicy.recordExistsAction = Aerospike.Client.RecordExistsAction.UPDATE; client.Add(writePolicy, myAerospikeKey, new Aerospike.Client.Bin(string.Empty, 1));

and i have below strange warning in my server logs at the time of the exception:

WARNING (rw): (write.c:795) write_master: invalid ttl 4075209733

Note: below is my namespace configuration:

namespace myNamespace { replication-factor 2 high-water-memory-pct 75 high-water-disk-pct 75 memory-size 2G single-bin true data-in-index true default-ttl 0

    storage-engine device {
            file /opt/aerospike/myNamespace.data
            filesize 64G
            data-in-memory true
    }

}


#5

Are you using Community Edition?


#6

Yes am using Community Edition. Again I was not facing this issue in the last Aerospike version, this happened just with the new edition (3.10.1)


#7

Please check out this: http://www.aerospike.com/docs/reference/configuration#max-ttl

You cannot set ttl more than 10 years now.


#8

@Tony, from the code snippet, the default ttl is live forever, then being updated to 15days on Add(). @akramayasrah I have tried to reproduce your problem on CE ver 3.10.1.1. My test code can be cloned at: git clone https://github.com/pygupta/aerospike-dicuss.git
Look in subdir topic3697. (You can use this solution and point to your Aerospike server and see if you get the error.)

I have tested with your namespace configuration. I am unable to reproduce your problem on one node CE cluster. If you are using a multi-node cluster, please make sure your configuration is consistent across all nodes. The ttl value of 4075209733 in your error message is not making sense.

namespace test { replication-factor 2 single-bin true data-in-index true memory-size 2G default-ttl 0 # live forever

storage-engine device { file /opt/aerospike/data/test.data filesize 4G data-in-memory true } }


#9

After further investigation in my code I found the issue, the passed ttl was -219932127 which is logical to be incorrect! but what made my code writing this incorrect ttl was the strange read record expiration which is 0!! and per my understanding this is supposed to be an expired object!! so now my question is:

What does it mean when you read a record from Aerospike with expiration = 0?


#10

Well, glad you found your problem. When default-ttl is defined 0 in namespace, it means live forever. When wPolicy.expiration = 0 on write, you are asking to use the default-ttl of the namespace. This is the write policy expiration default if you dont specify it. When wPolicy.expiration = -1 on write, you are asking to use ttl = live forever overriding the default-ttl of the namespace. When wPolicy.expiration = greater than 0 seconds, use that overriding the default ttl of the namespace. When not “live forever”, TTL cannot be set greater than 10 years either in namespace default-ttl or via write policy expiration value. Records that are TTL live forever are never “evicted”. This takes away your safeguard before you hit stop writes should you start filling up your storage space. Removing records by reducing their namespace default-ttl is a bad strategy. Use the default-ttl of the namespace so that you don’t have to typically mess with write policy expiration value to remove the record. for example in your case why put namespace defualt-ttl to 0 then change to 15 days via wpolicy? Make namespace default-ttl 15d?? BTW, doing any namespace wide default changes on a live cluster in production is not trivial and you may have other unintended consequences. So understand and think through the impact on existing data and future updates to your data before you do any of that.