What is the meaning of some failure warnings in server log?

1

I’m seeing the following warnings in the server log periodically (couldn’t summarize it in the title - “Title seems unclear, is it a complete sentence?” pops up no matter what):

Mar 02 2018 09:16:07 GMT: WARNING (particle): (particle_map.c:6703) cdt_process_state_packed_map_modify_optype() ADD failed
Mar 02 2018 09:16:07 GMT: WARNING (rw): (write.c:1707) {...} write_master: failed as_bin_cdt_stack_modify_from_client() <Digest>:...

What does it mean? Does it require any actions? Could this code (using golang client) cause that?:

mpol := as.NewMapPolicy(as.MapOrder.UNORDERED, as.MapWriteMode.CREATE_ONLY) //imitate a set
_, err = client.Operate(..., k, as.MapPutOp(mpol, "v", someId, 0))

If so, and if this is normal then why is that a warning? In what situations shouldn’t I ignore it?

Server version: C-3.15.1.4

2

It means the ADD op failed, and the most likely cause is what you showed: using CREATE_ONLY when an entry with that key already exist. You can confirm by checking the error code returned. If it is a CREATE_ONLY policy violation, it should have returned FAIL_ELEMENT_EXISTS (24).

The database core always issue a warning when an op fail. There are also implied consequences. If your failed op is part of a list of ops submitted in a single transaction, any op failing will cause the whole transaction to fail and be rolled back. If you always submit transactions with a single op, you can probably ignore that particular warning.

Going forward, we have thought of a NOFAIL usage model (i.e. CREATE_ONLY_NOFAIL), where policy violations would quietly no-op rather than fail, but it has not been implemented yet. We’ll probably get to it when there is enough customer demand, or time permitted.

3

Thanks for a comprehensive answer!

Yep, I do check for FAIL_ELEMENT_EXISTS indeed and use a single op here for emulation of adding an item to a set structure (similar to redis).

NOFAIL mode would be a nice solution. Though I don’t see why the existing CREATE_ONLY policy should trigger a warning for an expected failure, because such failure is a part of policy semantics and is… expected, not requiring attention. Mixing such warnings with real warnings only complicates log reading.

4

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.