Memcached 1.6.6 Expiration Semantics: 32‑bit Overflow and 64‑bit Support

Question

Goal
To determine a reliable strategy for storing items that must live beyond 30 days in memcached 1.6.6 while avoiding the pitfalls of 32‑bit expiration overflow.
Context and Constraints
Memcached 1.6.6 explicitly documents that expiration values ≤30 days are treated as relative TTLs, whereas values >30 days are interpreted as absolute Unix timestamps. The server stores the expiration as a 32‑bit unsigned integer, which can overflow on 32‑bit builds when the timestamp approaches 2³²‑1. Client libraries that do not perform the TTL/absolute distinction can inadvertently set items that expire immediately or never.
Unresolved Decision
The documentation notes a potential future 64‑bit expiration support, but it is unclear whether and how such a feature will be introduced and how backward compatibility will be maintained.
Questions

Will memcached ever accept a 64‑bit expiration value, and if so, what syntax or protocol changes will be required?
How will backward‑compatible clients be affected if the server starts interpreting 64‑bit values?
What is the safest client‑side approach for setting long‑lived items in the current 32‑bit environment?

Tasadduq Burney · Answer

Direct Answer
Memcached 1.6.6 does not accept 64-bit expiration values. The protocol field is a 32-bit unsigned integer, and the server interprets values of 30 days or less as relative TTLs and values greater than 30 days as absolute Unix timestamps. No official protocol change for 64-bit expirations is documented in 1.6.6, so any such feature remains speculative.

Confirmed Facts

Expiration is stored as a 32-bit unsigned integer.
Values ≤ 30 days are relative offsets from the current time.
Values > 30 days are treated as absolute Unix timestamps.
No 64-bit expiration support exists in the 1.6.6 release.

Likely Explanation and Forward Compatibility
If a future release were to add 64-bit expirations, it would most likely require an extended binary-protocol field or a new command variant. Existing clients that send 32-bit values would continue to work unchanged; they would simply be unable to request expirations beyond the 32-bit limit. Until such a change is published in an official protocol specification, treat 64-bit support as unconfirmed.

Safest Current Strategy

Use absolute timestamps within the 32-bit range. Pick a target Unix timestamp that is more than 30 days in the future but below 2³²−1 (year 2106). This avoids the relative-TTL interpretation and stays inside the protocol limit.
Refresh before expiry. If the required lifetime is longer than the remaining 32-bit window, re-set the item periodically with a new absolute timestamp.
Offload permanent data. For items that must outlive the cache or the 32-bit horizon, store them in a durable backing store and use memcached only as a read-through layer.

Verification
You can confirm the behavior on a local 1.6.6 instance by issuing a set command with an expiration value greater than 30 days and observing whether the item persists until that absolute time. Attempting a value that exceeds 2³²−1 on a 32-bit build should expose overflow behavior (immediate or never-expiring items). Check the binary protocol documentation for any newer 64-bit field before relying on it.

Conservative note: Because the roadmap for 64-bit expirations is not public, verify against the specific memcached version and client library you deploy rather than assuming future protocol extensions.

Memcached 1.6.6 Expiration Semantics: 32‑bit Overflow and 64‑bit Support

Goal

Context and Constraints

Unresolved Decision

Questions

1 answer

Direct Answer

Confirmed Facts

Likely Explanation and Forward Compatibility

Safest Current Strategy

Verification

Your perspective belongs here.

0 question comments