WARNING (particle): (particle_float.c:112) increment with non float type 1WARNING (particle): (particle_integer.c:147) increment with non integer type 2
Could this explain why we are seeing some failures in our TPS stats?
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.
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?
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
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.