Service does not provide a matching QoS

Mark Yip

Hi, I had a reported issue from one of our application Dev team, where some price was in a "stuck" state. This appears to be the result of migrating from BON to RTO. We noticed that the QoS from BON has a QoS of Real:Tick, but when switching to RTO, the QoS is now Real:JustTime.

We restarted the ADS, but believe the application has already transition to state where it doesn't know how to re-initialized the subscription.

The State message is state="Open / Suspect / None / 'Service does not provide a matching QoS'".

The application is using ETA 3.9.1.3. Also we have another application the is using RFA.8.2 and the last event in the log was a Ready State and was unable to receive any updates until the application was restarted.

Jirapongse

@Mark Yip

Thank you for reaching out to us.

This is an expected behavior.

The application can specify the required QoS (RealTime or TickByTick) in the subscription request. However, if the service cannot support the requested QoS, it may reject the request by closing the stream.

Therefore, the application should first verify the QoS levels supported by the service and then request only those supported QoS levels when subscribing to items.

The ELEKTRON_DD service supported on RTO is Real:JustTime. Therefore, the qosRate and qosTimeliness values in the request message should be like this:

<requestMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="4" containerType="RSSL_DT_NO_DATA" flags="0x44 (RSSL_RQMF_STREAMING|RSSL_RQMF_HAS_QOS)" qosDynamic="0" qosRate="2" qosTimeliness="1" dataSize="0">
<key flags="0x3 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME)" serviceId="5005" name="PTT.BK"/>
<dataBody>
</dataBody>
</requestMsg>