Hello @mark.ringrose,

For EMA this is a valid request, so there will be no warning. EMA will establish two streams on behalf of the consumer, each with it's own streamId. The consumer will process every update twice, once on each stream ID, so if one is printing the updates, each update will be seen twice.

For example:

UpdateMsg
    streamId="5"
    domain="MarketPrice Domain"
    updateTypeNum="0"
    name="JPY="
    serviceId="300"
    serviceName="ELEKTRON_EDGE"
    Payload dataType="FieldList"
        FieldList
            FieldEntry fid="114" name="BID_NET_CH" dataType="Real" value="0.47"
            FieldEntry fid="372" name="IRGPRC" dataType="Real" value="0.44"
        FieldListEnd
    PayloadEnd
UpdateMsgEnd

EmaRdm.INSTRUMENT_UPDATE_UNSPECIFIED
UpdateMsg
    streamId="6"
    domain="MarketPrice Domain"
    updateTypeNum="0"
    name="JPY="
    serviceId="300"
    serviceName="ELEKTRON_EDGE"
    Payload dataType="FieldList"
        FieldList
            FieldEntry fid="114" name="BID_NET_CH" dataType="Real" value="0.47"
            FieldEntry fid="372" name="IRGPRC" dataType="Real" value="0.44"
        FieldListEnd
    PayloadEnd
UpdateMsgEnd

If you would prefer for this not to happen, at the point of registerClient, would check if the subscription is unique.

Does this address the question?

Zoya,

Thank you very much for your prompt reply. It does address the question. One further question on your reply: In your final sentence you say: "If you would prefer for this not to happen, at the point of registerClient, would check if the subscription is unique."

Does the registerClient method respond with a flag or indicator to tell me if the subscription is unique? So, do I just have to check this flag or do I need to do something special to find out if the subscription is unique?

Thank you.

@mark.ringrose,

Each subscription returns a handle. Please look up registerClient() and handle(), in Reference.

Each event carries the handle, i.e. event.handle, so one can match the two, the registration and the event, this way. The intention of the handle:

• is to match the event seen in a callback with subscription
• to unregister
• to reissue
• not to determine if it is unique in terms of item

In order not to register for the same item twice, the consumer keeps track of and controls what it passes into registerClient

Please note that one may also require register for two of the same item with different Domain Model, i.e. L1 and L2, which is also a legit use, and will result in two different handles with two different streamIds.

Please note, that one can pass parameter closure into registerClient that may help keeping track of uniqueness, among other things. If we generate a closure in a way that uniquely defines every item registration, and store and keep the closures that have been used prior, we can always check if the registration is unique.