Receive watch events for TTL'd KV objects

[segfaultdoc]

Feature Request

Use Case:

We currently use JetStream KV to build different in memory cache views of the objects stored. We'd like to leverage the KV stores TTL mechanism to delete stale objects in our derived views.

Proposed Change:

Emit watch events from the server signaling when a KV object has been TTL'd.

Who Benefits From The Change(s)?

Jito Labs and others

Alternative Approaches

Build cleanup logic in app code.

[derekcollison]

This has been requested and we are looking into the best way to provide this.

[esemeniuc]

Would love to see this too

[derekcollison]

Yes on our list for 2.10..

[gedw99]

This would be quite useful for building large distributed caching system with nats as the origin store.

the secondary caches could be cdn style servers that speak http downstream and nats upstream.

Use case then is:

where an external cache line can be invalidated when the nats kv or Object item TTL expires..

[alexandreLamarre]

Any updates on this making it into v2.10?

[derekcollison]

Will not make it in 2.10.0. Still on our list.

[stpnov]

it's much needed, we're waiting

[derekcollison]

It will be coming..

[alexj212]

@derekcollison Any eta on a target version/date?

[derekcollison]

2.11 April timeframe is target.

[mxcoppell]

If the key expiration events could have an option to be distributed to a stream that would be great. This would be great for a multi-client environment to use different stream policy to consume the expiration events.

[derekcollison]

They will be on the stream that caused the expiration. As system delete markers.

[mxcoppell]

Is there any limitation for the underlying stream for the KV store? One issue we have with Redis is that all pods need to listen to the key space for expiration events and it requires dedup for the duplicate events. If the underlying stream could be WorkQueuePolicy and a number of queue subscribers can listen to the stream that would be perfect.

[derekcollison]

@mxcoppell I am not following. Could you provide a bit more information?

[mxcoppell]

Sure, using the following example from https://shijuvar.medium.com/using-nats-jetstream-key-value-store-in-go-85f88b0848ce:

url := os.Getenv("NATS_URL")
 if url == "" {
  url = nats.DefaultURL
 }

 nc, _ := nats.Connect(url)
 defer nc.Drain()

 js, _ := nc.JetStream()
if stream, _ := js.StreamInfo("KV_discovery"); stream == nil {
  // A key-value (KV) bucket is created by specifying a bucket name.
  kv, _ = js.CreateKeyValue(&nats.KeyValueConfig{
   Bucket: "discovery",
  })
 } else {
  kv, _ = js.KeyValue("discovery")
 }

The KV bucket "discovery" is in the stream "KV_discovery".

My understanding to the key expiration events (could be totally wrong) is that the event will be distributed to the stream consumers of "KV_discovery". My last question about this if user could set the retention policy like "WorkGroupQueue" for "KV_discovery" so a group of queue subscribers could listen to stream "KV_discover" for the expiration events - and each expiration event will be distributed to one subscriber at a time, not broadcasting to all the listeners.

Thanks!

[derekcollison]

Yes system level expiration or removal will be distributed to the watchers of that KV in 2.11.

[mxcoppell]

Derek, could you use an example to illustrate how this expiration event subscription work? And if the events are broadcasts to all watchers or there could be more options like queue subscriber?

[derekcollison]

They will be for all watchers. This is similar to what happens today if you use the KV library to delete a key.