StreamSpotOrderbook blocked when there is no update on the market
Closed this issue · 9 comments
stream, err := exchangeClient.StreamSpotOrderbook(ctx, marketIds)
As the example on api doc, if there is no update on the market during you call the function. It will be blocked, can't have the stream object until there is an update happend on the market.
@powenperng so the call works but you get a response only when there is an update in the market?
Isn't that expected? Stream will return you responses when there's an update.
Yes, the issue is if no update happend. the thread will be block on this line, until there is an update.
@powenperng the stream works that way so it's normal, if there is no update for 1h the exchange will cut the connection and then a re-try on the client-side will establish the connection again.
This is a very odd or blizzard design. Client should at least get a message from that stream to be notified that stream will be closed, if client doesn't response to keep it alive, it will be closed in X mins. This needs to be designed more friendly.
And nobody should close the ticket except the case opener himself/herself.
This is already what happens, you catch the exception on the connection closure, re-try and establish it once again.
All clients should have re-try logic, networking issues that cannot be foreseen either on the client or the server can also cut the connection momentarily.
How exactly should the friendlier design be?
This is called un-gracefully disconnection. The graceful way should prevent that stream from shutting down w/o asking the client if it could be closed. Having client apps keep retrying is sth unheard of from a normal API user standpoint.
The way to do that would be to introduce a keep alive mechanism which we decided not to do for performance issues.
If we just ask users to confirm if they still need to keep it alive for every 24 hours, I don't think it will hurt performance.
We will deprecate this API in next days so the issue is not valid anymore