MAX number of streamId exists?

noboru.maruyama4

Hello

My customer is experiencing unexpected disconnection with RTO.

When I checked the log, I noticed the customer repeating request/close for each item to get the data in snapshot. It seems this creates huge number of streamId.

<REQUEST domainType="MARKET_PRICE" streamId="3354698" containerType="NO_DATA" flags="0x46 (HAS_PRIORITY|STREAMING|HAS_QOS)" Qos: Realtime/JustInTimeConflated/Static - timeInfo: 0 - rateInfo: 0 priorityClass="1" priorityCount="1" dataSize="0">

<key flags="0x03 (HAS_SERVICE_ID|HAS_NAME)" serviceId="257" name="/GOOGf042119600.U"/>

Found that StreamId allows a range from -2,147,483,648 to 2,147,483,647 in ETA developers guide.

Wonder in case of such lots of streamID consumed. how the buffers to be kept for each streamId. I am wondering if buffers might be consumed improperly and may causing disconnection.

Please advise how the buffer can be released for closed streamID?

Appreciated to have your advise

Thank you

zoya faberov

Hello @noboru.maruyama4,

On request to registerClient, whether it's a streaming request or a snapshot, EMA assigns a unique, increasing streamId.

If the request is for snapshot, interestAfterRefresh(false), the resources of the stream itself will be released once the stream is fully closed.

The streamId increases perpetually during the run of a consumer, with every registration, but does not take up much resources at all, and is allowed a giant range (as you indicate) so the consumer will not run out of streamIds.

If these are snapshot requests, the disconnect that you experience should not be caused by streamId of 3354698+.

With ETA, optionally, you have control over streamId being assigned to the snapshot requests, and can choose to reuse the number, once the first request is fully closed. But I do not think they are related to the cause of the issue at hand that causes the disconnects from RRTO.