Extent of TREP platform support for REDIRECT status messages

Please can you confirm the extent
of ADS/ADH support (2.6 & 3.0) for REDIRECT status messages:

- Are REDIRECT status msgs just
passed through the infra or are they cached so that a late joiner to the redirected
item gets the REDIRECT status also.

- Are there any restrictions on
publishing REDIRECT status?

- Can symbollists be
redirected?

- Can a NIP publish REDIRECT statuses?

Find more posts tagged with

trep

elektron

refinitiv-realtime

Accepted answers

Jirapongse

I have tested it with TREP 3.0.1.E1 and found
that TREP doesn’t cache the REDIRECTED status. It forwards the status to the
consumer. If the consumer requests the same item again, the request will be
forwarded to the provider. Therefore, the provider needs to send the REDIRECTED
status again
The REDIRECTED message indicates the stream is closed
and it must contain the new identifying information in the message key.
Otherwise, the consumer will get this status text: “F18: Received redirect without new item name.”
REDIRECTED is a stream state so it can be used
with any stream
Yes, NIP can publish REDIRECTED status and the subscribing
consumers will get the REDIRECTED status with the new identifier. However, if the consumer requests the
same item again after the REDIRECTED status is published, it will get “F10: Not In
Cache” because the stream of that item between NIP and ADH has been closed

All comments

Steven McCoy

RSSL/Redirect is supposed to be equivalent to an SSL/Rename message.

TREP is designed to support RSSL/Redirect and is explicitly supported by ADS multicast as added in UPA 7.6. This covers warm-standby situations when a consumer requested symbol X and is redirected to symbol Y and then has failed over to another ADS and the item stream for symbol X must continue being valid.

RSSL/Redirects operate on any item streams and can be used to bounce subscriptions to or from private streams.

Both interactive and non-interactive providers can send RSSL/Redirect messages, although for the case of private streams this would not be very useful for broadcast-only.

All the RFA and UPA examples and ValueAdd libraries only cover bouncing between public and private streams. This highlights that almost zero clients will understand RSSL/Redirect messages when received directly.

The outstanding question is whether or rather how to implement the RSSL/Redirect so that TREP can do this on a clients behalf, basic testing with a modified RsslProvider can close the stream id but does not open a new one.

Gordon Hunn

Thanks Steven, but I'm not familiar with SSL/Rename so none the wiser I'm afraid ...

Jirapongse

I have tested it with TREP 3.0.1.E1 and found
that TREP doesn’t cache the REDIRECTED status. It forwards the status to the
consumer. If the consumer requests the same item again, the request will be
forwarded to the provider. Therefore, the provider needs to send the REDIRECTED
status again
The REDIRECTED message indicates the stream is closed
and it must contain the new identifying information in the message key.
Otherwise, the consumer will get this status text: “F18: Received redirect without new item name.”
REDIRECTED is a stream state so it can be used
with any stream
Yes, NIP can publish REDIRECTED status and the subscribing
consumers will get the REDIRECTED status with the new identifier. However, if the consumer requests the
same item again after the REDIRECTED status is published, it will get “F10: Not In
Cache” because the stream of that item between NIP and ADH has been closed

EXPLORE OUR SITES