search

nats-io / nats-server

High-Performance server for NATS.io, the cloud and edge native messaging system.
https://nats.io
Apache License 2.0
15.12k stars 1.37k forks source link

Key-value storage, Does the key support TTL? #3251

Open hydaizd opened 1 year ago

hydaizd commented 1 year ago

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

ripienaar commented 1 year ago

At the moment only a per-bucket TTL

derekcollison commented 1 year ago

We do have plans to add in the ability to listen for when a message is removed from a stream by the system.

hydaizd commented 1 year ago

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?

derekcollison commented 1 year ago

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.

herzaso commented 1 year ago

@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?

derekcollison commented 1 year ago

We eventually want both.. However these have not been the highest priority items for 2.9 release, but still seeing what we can do..

pcsegal commented 1 year ago

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.

derekcollison commented 1 year ago

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?

jarrodb commented 1 year ago

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 🔥

derekcollison commented 1 year ago

Unless a large customer wants this we have no plans atm, but are considering TTL refresh on a get as mentioned above.

aleyrizvi commented 3 months ago

Any updates please?

aleyrizvi commented 3 months ago

A perfect use case with TTL would be to replace redis as a session storage for ssr web apps.

ripienaar commented 3 months ago

@aleyrizvi its on the short term road map, so hopefully not too long before we support that.

aleyrizvi commented 3 months ago

Perfect Thanks @ripienaar We are replacing whole messaging stack with nats in testing environment. Kafka, Redis and SQS/SNS.

n9 commented 2 months ago

What is the current ETA for this feature?

derekcollison commented 2 months ago

Hoping to land in Preview3 in a few weeks.

stebet commented 3 weeks ago

@derekcollison Has any work on this started? Would love to have the .NET Client ready for this when it's released so if there is a branch that has started this work where I can see the protocol changes then I can keep the .NET Client in sync as well :)

Very much looking forward to this feature!

Jarema commented 3 weeks ago

@stebet we will have ADR (and issues in client repos) ready as soon as this lands, so all clients have guidance on implementing it.