Introduce stream_ttl #222
Introduce stream_ttl #222
Conversation
TusharR-google
changed the title
I agree. Can we just make this |
Thanks! The same concept can be applied to PULL streams too, let me reword this as simply stream_tll. |
|
|
||
| > OPTIONAL. The lifetime of a PUSH stream in seconds, after which the Transmitter MAY either pause or disable the stream if it has not received any Receiver-initiated communication in that duration. | ||
| If the Transmitter decides to update the stream, it MUST send a Stream Updated Event to the Receiver as described in {{status}}. | ||
| If the Receiver calls any endpoint in the Event Stream Management API ({{management}}), the Transmitter must refresh the TTL of that particular stream. |
There was a problem hiding this comment.
We might want to be explicit that contact from the receiver does not automatically move the stream out of a paused/disabled state caused by a TTL timeout.
| @@ -601,6 +618,13 @@ default_subjects | |||
| to be transmitted. The Receiver MAY remove subjects added this way via the | |||
| `remove_subject_endpoint`. | |||
|
|
|||
| stream_ttl | |||
|
|
|||
| > OPTIONAL. The lifetime of a stream in seconds, after which the Transmitter MAY either pause or disable the stream if it has not received any Receiver-initiated communication in that duration. | |||
There was a problem hiding this comment.
"Receiver initiated" needs to be clarified, IMO. Does it differ for poll and push streams? Is the appropriate response code from the receiver to a push from a Tx sufficient?
#211