TREP stripping AttribInfo from UPDATE_RESP messages using custom model
We have noticed an issue with a provider we have written with the JAVA RFA API 7.2.1. We are using a custom domain model (128) and when we send UPDATE_RESP messages through our TREP the AttribInfo is being stripped off. REFRESH_RESP messages traverse the TREP without modification.
Successful REFRESH_RESP
Provider sends
MESSAGE Msg Type: MsgType.REFRESH_RESP Msg Model Type: Unknown Msg Model Type: 128 Indication Flags: REFRESH_COMPLETE | CLEAR_CACHE Hint Flags: HAS_ATTRIB_INFO | HAS_ITEM_GROUP | HAS_QOS | HAS_RESP_TYPE_NUM | HAS_STATE State: OPEN, OK, NONE, "OK" Qos: (RT, TbT) Group: 0001 RespTypeNum: 0(REFRESH_SOLICITED) AttribInfo ServiceId: 417 Name: EXCH_STATUS NameType: 1 Payload: 11 bytes FIELD_LIST FIELD_ENTRY 20002: 01
Client receives
MESSAGE Msg Type: MsgType.REFRESH_RESP Msg Model Type: Unknown Msg Model Type: 128 Indication Flags: REFRESH_COMPLETE | CLEAR_CACHE Hint Flags: HAS_ATTRIB_INFO | HAS_ITEM_GROUP | HAS_QOS | HAS_RESP_TYPE_NUM | HAS_STATE State: OPEN, OK, NONE, "OK" Qos: (RT, TbT) Group: 0001 RespTypeNum: 0(REFRESH_SOLICITED) AttribInfo ServiceId: 417 Name: EXCH_STATUS NameType: 1 Payload: 11 bytes FIELD_LIST FIELD_ENTRY 20002: 01
Unsuccessful UPDATE_RESP
Provider sends
MESSAGE
Msg Type: MsgType.UPDATE_RESP
Msg Model Type: Unknown Msg Model Type: 128
Indication Flags:
Hint Flags: HAS_ATTRIB_INFO | HAS_RESP_TYPE_NUM
RespTypeNum: 0 AttribInfo
ServiceId: 1
Name: EXCH_STATUS
NameType: 1
Payload: 11 bytes
FIELD_LIST
FIELD_ENTRY 20002: 02
Client receives
MESSAGE Msg Type: MsgType.UPDATE_RESP Msg Model Type: Unknown Msg Model Type: 128 Indication Flags: Hint Flags: HAS_RESP_TYPE_NUM RespTypeNum: 0 Payload: 11 bytes FIELD_LIST FIELD_ENTRY 20002: 02
As you can see the AttribInfo has disappeared.
Does anyone have an idea as to what is going on?
If the subscriber hasn't requested attrib-info-in-updates when he made the subscription, then AttribInfo will be left out from all UPDATE messages. So, this is by design. TREP will remove it because the subscriber didn't ask for it.
A subscriber shouldn't really have a need for the information in AttribInfo on messages of type UPDATE, only on messages of type REFRESH, hence the feature exists to include it or not, and the default is that the subscriber must explicitly ask for it if he wants it.
Hi @david.heggie,
You can set OMMMsg.Indication.ATTRIB_INFO_IN_UPDATES in your Consumer ReqMsg if you really want AttribInfo in your updates, but the generally this is avoided to minimise TREP bandwidth etc.
See section 6.2.5 Indication Flags of the RFA Java Developers guide for more detail.
Perfect, thanks for the help.