Numerous write_master failures in cluster


#1

Hi.

We are currently receiving a lot of the following errors in our set up, and I was wondering if this could be related to our redundant records issue:

WARNING (rw): (write.c:1724) {adspruce} write_master: failed as_bin_particle_stack_modify_from_client() <Digest>:0x2dcf8da11f3ae4c186c3ff6b2ba36cb65ca4768e

and also these:

WARNING (particle): (particle_float.c:112) increment with non float type 1 WARNING (particle): (particle_integer.c:147) increment with non integer type 2

Could this explain why we are seeing some failures in our TPS stats?

Many thanks


#2

I’m assuming the initial values were set by the PHP client. If the first write is an integer, it’s expected that any increment operation will be an integer as well, and similarly for float.

I wonder if it’s a type casting problem on the client side. When I have a bit of time I’ll try to reproduce it. I’d hope that if the value is explicitly type set ( (float) vs (int) ) it still occurs.

If you have a short bit of PHP to reproduce it (before I do), please post it here. It will also need to be an issue with the client.


#3

Yeah i figured that was probably the case, but running through the code, I can’t see anywhere where it should be incrementing a float at this point as I removed that logic previously. This should be simple increments of single integers (with a default value of 1)

I’ll see if I can get it to fail - if I can recreate will this be an update?


#4

Okay, so using version 3.4.12 of the client and version 3.10.0 of the server, the following code will yield the error:

        echo 'Incrementing records...';

        $floatValue = 0.01;
        $intValue = 1;

        // getDb() returns an instance of Aerospike
        $key = $this->getDb()->initKey('test', 'test', 'inc_test');

        $status = $this->getDb()->increment($key, 'data', $intValue);

        echo $status;

        $status = $this->getDb()->increment($key, 'data', $floatValue);

        echo $status;

        if ($status != Aerospike::OK) {
            echo "Error [{$this->getDb()->errorno()}]: " . $this->getDb()->error();
        }

        return true;

depending upon whichever one is written first the second attempt will yield error code 12 - so if the int goes first, the float increment will fail, and vice versa. If I type cast the values, then the process passes - so if I write the float value first, then cast the int value to a float when incrementing then it increments fine.

Not sure if this is intended behaviour or not, or whether there needs to be something updated in it

thoughts?..


#5

That’s the intended behavior. There’s no schema in Aerospike, so the type of the bin is set by the most recent write operation. At this point the record has the bin’s type and value, which means that subsequent atomic operations such as increment need to be correctly typed.

I agree that the documentation in the dynamic language clients should clarify this issue.


#6

Okay, no problem, thanks for the reply @rbotzer. I guess I’ll just have to evaluate types before incrementing or something. Cheers