nats-server
nats-server copied to clipboard
Key-value storage, Does the key support TTL?
Feature Request
In the key-value storage.Does the key support TTL? Like Redis, and can listen for expiration events.
Use Case:
Proposed Change:
Who Benefits From The Change(s)?
Alternative Approaches
At the moment only a per-bucket TTL
We do have plans to add in the ability to listen for when a message is removed from a stream by the system.
We do have plans to add in the ability to listen for when a message is removed from a stream by the system.
Which version is planned for this feature?
We may get it in the next release which is 2.9 and was scheduled for this last week but we have extended its beta testing phase so a few more things, including this one may make it in.
@derekcollison Any update on that? Also, Is the plan to support TTL for a key like @hydaizd suggested or just to listen for when a message is removed?
We eventually want both.. However these have not been the highest priority items for 2.9 release, but still seeing what we can do..
Hi, is there any plan for having per-key TTL in the near future?
I would like to be able to both set a different TTL per key and listen for TTL expiration events.
We have been considering Get() refreshing a TTL. No current plans to allow arbitrary TTLs.
And yes we have plans to allow for system removal events to be observed in a watcher at some point.
What is you use case?
For my particular use case I'm using it to store network information in the same bucket. Some keys are ephemeral data that is easy to TTL so that it cleans up stale entries, but others are long lasting and may not be updated from network device streams. Supporting TTL (and other header metadata) at the key or even subject level would be 🔥
Unless a large customer wants this we have no plans atm, but are considering TTL refresh on a get as mentioned above.
Any updates please?
A perfect use case with TTL would be to replace redis as a session storage for ssr web apps.
@aleyrizvi its on the short term road map, so hopefully not too long before we support that.
Perfect Thanks @ripienaar We are replacing whole messaging stack with nats in testing environment. Kafka, Redis and SQS/SNS.