Max Cache Duration per Subscription #450
Conversation
A variant of #446 that is on a Subscription granularity, instead of Object duration.
|
Per my read of the room, i would prefer #446 as it is gives better flexibility for the application than enforcing it per subscription ( as it applies the same value to all the objects) . Also not sure if there are cases where this can change between the subscriptions either |
+1, Cache Duration per object is more flexible. |
| @@ -1414,11 +1415,19 @@ longer valid. A value of 0 indicates that the subscription does not expire | |||
| or expires at an unknown time. Expires is advisory and a subscription can | |||
| end prior to the expiry time or last longer. | |||
|
|
|||
| * Max Cache Duration: The maximum length of time in milliseconds a caching | |||
| relay MAY cache the subscription for. A value of 0 indicates there is no limit. | |||
There was a problem hiding this comment.
Does this have value for non-relays (eg: subscriber side caches?)
| @@ -1519,6 +1519,7 @@ SUBSCRIBE_OK | |||
| { | |||
| Subscribe ID (i), | |||
| Expires (i), | |||
| Max Cache Duration (i), | |||
There was a problem hiding this comment.
I think this might be slightly better as an optional parameter but clearly not a big deal either way
| @@ -1533,6 +1534,13 @@ longer valid. A value of 0 indicates that the subscription does not expire | |||
| or expires at an unknown time. Expires is advisory and a subscription can | |||
| end prior to the expiry time or last longer. | |||
|
|
|||
| * Max Cache Duration: The maximum length of time in milliseconds a caching | |||
| relay MAY cache the subscription for. A value of 0 indicates there is no limit. | |||
There was a problem hiding this comment.
It is the objects that are cached not the subscription so I think this needs to say "MAY cache the object for"
| * Max Cache Duration: The maximum length of time in milliseconds a caching | ||
| relay MAY cache the subscription for. A value of 0 indicates there is no limit. | ||
| The relay MUST NOT begin sending Objects for a new subscription from cache if | ||
| it's older than Max Cache Duration. When a relay responds with SUBSCRIBE_OK, |
There was a problem hiding this comment.
Need to be clear the time starts at when the relay started to receive the object.
| The relay MUST NOT begin sending Objects for a new subscription from cache if | ||
| it's older than Max Cache Duration. When a relay responds with SUBSCRIBE_OK, | ||
| the amount of time since the corresponding upstream subscription was made is | ||
| subtracted when sending the Max Cache Duration. |
There was a problem hiding this comment.
This sentence does not make sense if we are caching objects not subscriptions. Would just remove it.
|
Closing this in favor of #469 |
A tweaked version of #448 Fixes #440 Fixes #249 Closes #450 Closes #448 I'll note that we might want to add params to TRACK_STATUS and allow this to be returned from that as well, which would allow a relay to keep it in its cache. Attempts to write down where we ended up at the end of the June 12th interim.
A variant of #446 that is on a Subscription granularity, instead of Object.
Fixes #440