How to detect "stale" items and groups in RSSL.
When migrating logic from SSL to RSSL (using UPA/ETA), there is logic in the SSL application that will detect when either a group or an item has become "STALE". These are delivered when SSL_(ITEM|GROUP)_STATUS_TYPE is set to SSL_ET_(ITEM|GROUP)_STATUS_STATLE.
Looking at the logs in the application and correlating them with the EED, it appears that this event is sent to the application when the EED loses its upstream connection -- possibly indicating that there could be a gap in the data.
I can't find a way to receive similar notifications in ETA (or UPA).
Does such a notification event exist?
If not, how can the downstream application be notified that there may be a possible gap in the data?
Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.
Thanks,
AHS
Hi @Joe.Ferraro
Have not tested any scenarios around GROUP status, however, my understanding is that GROUP status information is delivered via the Source Directory responses.
You would need to set the RDM_DIRECTORY_SERVICE_GROUP_FILTER when encoding your Source Directory Request.
You should be able to find more information in the RMDUsageGuide and the ETAC DevGuide has a section 13.4 on Item Group use
Source Directory Group Filter Entry
For individual items going stale, you would expect to see a streamState of Open and a dataState of the item as Suspect - either in a Status Message (when the item becomes stale) or as part of the Refresh Msg (if the item is stale at the point when your Request is received by the provider)
if (pState->streamState == RSSL_STREAM_OPEN && pState->dataState == RSSL_DATA_SUSPECT)
{
/* Stream State is (1) Open (typically implies that information will be streaming, as information changes updated
* information will be sent on the stream, after final RsslRefreshMsg or RsslStatusMsg)
*
* Data State is (2) Data is Suspect (similar to a stale data state, indicates that the health of some or all data associated with the stream
* is out of date or cannot be confirmed that it is current )
*/
printf("\nLogin stream is suspect\n");
return RSSL_RET_FAILURE;
}
If I remember correctly then the older SSL APIs would do so called 'event fanout' for you automatically, while an API like UPA/ETA will not and you'll have to do it yourself. RFA APIs also do event fan-out for you.
What actually travels the wire is single event message that change the status for a service or for a group of items. An API that automatically does event fan-out will then translate that into what that means for you and 'send' you an event for each item which is affected. If the API doesn't have the event fan-out feature then you'll have to keep track of this yourself.
Of course it may also be a status change for an individual data item that arrives on the wire but in this case there's no need for any fanout.
Here's the good news: You can use the ValueAdd classes (the Reactor) with your UTA application. This will give you automated status fanout so you won't have to do that yourself.