I'm using ETA API version 1.0.8 in Linux. The response message (RsslMsg) has three Rssl states (RsslStreamStates, RsslDataStates and RsslStateCodes). These three states different set of possible values as defined in rsslState.h
I understand that these will have the following values as printed by example application in string format.
- Closed/Suspect/None for INVALID symol
- Open/Ok/None for VALID symbol requested part of batch
- Non-streaming/Ok/None for SNAPSHOT request.
It looks to me that different error scenarios need to be simulated in the server side to understand the combination of the states that can be sent to client.As there could be a large number of combinations possible with these 3 states, I would like to know if there is any recommended mapping matrix to identify different use case (example: valid symbol, invalid symbol, suspect data, etc,..)
Rather than a matrix or list of combinations, an understanding of the RsslState structure members should help you determine how best to respond based on your requirements and application implementation.
Firstly you have streamState - which represent the state of the event Stream your application has established with the server. The actual enum values for RsslStreamState are all listed in the rsslState.h file but a few key ones:
Next you have dataState which represents the state of the actual data itself. The enum values for RsslDataStates are as follows:
The RsslState.code member contains RsslStateCodes - which actually provide aadditional information to try and explain the current streamState or dataState - a few possible values:
So, the key members to act on are streamState and dataState - the code member along with the text member provides additional information to try and explain why the streamState or dataState are in a particular state. For example if you have Stream OK and Data Suspect, you would warn the user the data is suspect and not to be trusted. Once the Data State changes to OK again , you could update the user that the data is no longer suspect. Or if you get a Stream Closed / Data Suspect / Code Not Found - you could advise the user that the item they requested does not exist.
The RsslState.text member should only be used for alerting or logging purposes and not for decision making.
In addition to the nice write up from Umer, I would strongly suggest looking at the documentation, particularly the ETA Developers Guide. The Appendix A chapter has a decision table that shows the various Item or Group state combinations that are valid, along with a description of what that means and what, if any, actions an application should take as a result.