Quote taken:
"When a record hits its expiration time the Namespace Supervisor will expire it, meaning it is removed from the cluster. An update or a touch from a client will reset the expiration time as if it were a new write. Reads will not affect expiration time. The namespace supervisor (NSUP) thread manages both evictions and expirations.
NSUP does not run all the time, instead it runs periodically. The time interval at which NSUP wakes up is the nsup-period"
Say a data expires, but NSUP hasn’t had the time to remove the data before the client issues an atomic increment to the data, and sets a special TTL value of -2 for not refreshing TTL. Will an atomic increment on the expired data refresh the object’s TTL and set the incremented value to 1?
It will behave as if the record didn’t exist.
I.E. If the write policy allowed record creation, a record would be created and the namespace’s default TTL would be used.
If you wanted to prevent a record creation then you would need to set the write’s policy to not allow record creation. For java the policy is RecordExistsAction = UPDATE_ONLY.
Just to add more color to “it will behave as the record didn’t exist” - the TTL of a record is a future timestamp stored within the Primary Index of a record. The first thing the server does when you ask for an operation on a record, whether read or write, is, it looks up its primary index to find pointers to the data. At that time it also looks at the expiration timestamp in the primary index. If the record is past its life compared to the system clock, it is treated as non-existent.