up-spec
up-spec copied to clipboard
eclipse-uprotocol
uSubscription subscription timeouts - nanoseconds?
Hi all, I'm looking through the remaining functional gaps I have to fill in my uSubscription implementation; one of them is the subscription expiry feature.
The SubscriptionRequest expire field is of type protobuf.google.Timestamp, which includes seconds and nanoseconds.
My question: do we really need nanosecond resolution in this usecase, in the expected deployments? Seems a bit overkill to me, because that precision implies a lot of questions that are essentially unimplementable on that kind of timescale (like: when exactly should the expiration counter begin - when the request is first received? After the subscription has been set up? After it has been persisted? After the state change notification has gone out? ...)
Proposal: change this attribute type, do the same as we did for UMessage ttl attribute, which simply is a uint32 in millisecond resolution. This would give us ~50 days of max subscription time if I'm not mistaken - and if that's not sufficient, I'd actually wager that second-resolution would be absolutely good enough for this usecase...
IMHO changing this to a time period also has the advantage of not requiring synced clocks. Using a uint32 representing milliseconds seems fair enough to me. I am actually wondering what the use case is for having a subscriber indicating the expiry time of the subscription?
@stevenhartley any insights?
milliseconds are sufficient. Temporal subscriptions was an optimization thought to be used to free up resources of the service for clients that are temporal (ex. they are unexpectedly terminated, live for a finite period in time, etc..). Also an optimization to avoid the client having to call unsubscribe explicitly.
So, milliseconds as
- duration between subscription and subscription-cancellation
- or as point-on-calendar (since 1970, etc etc)
?
It is a point on the calendar and hence why I originally had it as google.protobuf.Timestamp. Why can't we keep it as-is? Even if though we don't need nanosecond precision, we can just set the nano field to 0. Changing the proto would mean going to v4 of uSubscription and affect changes to all the language libraries that already implemented the L3 client API.
I'll implement the first version off the current definition anyways, as to not have to wait for future up-spec releases.
If it's really going to be calendar point, then maybe keeping Timestamp makes sense. Otoh, we might get rid of a confusing property (the nanos) and have one less point where we're using external types by moving this to a simple millisecond integer, aligning with what we're doing with UMessage ttl... we would need a big number though, Rust uses an u128 for millis-since-1970. But that's what I would prefer, because for storing this to persistency, calendar-point representation is much more straightforward.,
Uh, another one @stevenhartley: for remote subscriptions, when does the expiration counter start running? When remote sub is first received by the local usubscription instance, or when the remote usubscription service has confirmed the subscription (state first changes to SUBSCRIBED)?
Alright - I've now implemented this in usubscription-rust (https://github.com/eclipse-uprotocol/up-subscription-rust/pull/18), and this leads to some conclusions. Mainly: timestamps as in calendar-time are the best way to deal with subscription expiry by far - not least because we're persisting subscriptions across runtime sessions, and absolute timestamps make that so much easier. This also provides the answer to my previous question: doesn't matter, as we're sticking to absolute timestamps :)
The one remaining thing for future consideration is the datatype question - do we want to maybe get rid of the external Google Timestamp type, simply replace by absolute millis since 1970? But not hugely urgent atm.
In project meeting 12th June 2025, it was decided to stick with the Google datatype - so this can be closed.