For a deeper look into our Elektron API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
nick.zincone avatar image
9.7k ●49 ●38 ●60

WebSocket API channel disconnects with batch request

Within the WebSocket API documentation, there are some simple examples of sending batch requests. These work. However, when sending batches of greater than a certain amount, the WebSocket channel disconnects. Through my tests, I seem to be able to request for a batch size of about 145. However, it is not always consistent. Most times it succeeds, sometimes not. When the batch gets beyond 150 items, it consistently causes a disconnect in the channel.

The batch I'm using contains both valid and invalid symbols. When you submit a batch, a status message is returned from the server which acknowledges the receipt of your request. Despite the status message saying:

Processed 175 total items from Batch Request.  175 Ok.

Doesn`t seem to make a difference. The connection will ultimately close. As a further test, I prepared my application to break my requests into smaller batches. For example, if I have 175 items as my total, I tried to submit 7 consecutive batches containing 25 items in each. This didn't make a difference. It is unclear from this behavior whether it is the size of the batch or whether a batch of requests all at once causes the disconnect. The behavior seems to indicate the latter.

The documentation makes no mention of the size limitation of the size of the batch. In addition, if there is a size limitation, I would expect a friendlier response that my channel being disconnected.

elektron-sdktreprdp-apiwebsocketsrrtobatchdisconnection
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

2 Answers

Upvotes
Accepted
jim.carroll avatar image
361 ●1 ●4 ●3

@nick.zincone1

The batch requests you've described should work.

Does the ADS log file indicate the reason for disconnecting the client ?(the configuration file in the EAP package sets the logfile to ads_pop.log and *ads*logMountRequests to True -- it should give a reason)

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

nick.zincone avatar image nick.zincone

Thanks Jim. I don't have direct access to the ADS logs, but I'm looking into it. In the meantime, I've tried another example node.js, and it doesn't disconnect. The testing application I'm using is one that I've ported over from an existing EMA C++ example. As such, I'm using a 3rd party websocket toolkit so it could be entirely an issue in there. Let me dig deeper.

Upvotes
nick.zincone avatar image
9.7k ●49 ●38 ●60

Hi @jim.carroll,

I just received access to the ADS log. When I tried my batch, this is what I received:

User u8007876 at position  on host  using application 256 on channel 20 has been disconnected due to an overflow condition.

WS disconnect from "u8007876" at position "" on host "" using application "256" on channel 20.
Reason: User u8007876 at position  on host  using application 256 on channel 20 has been disconnected due to an overflow condition.

I don't see this condition when testing either via node.js nor Java examples. The message seems to imply that my client is not reading fast enough. Although it is 3rd party software built around boost C++, and virtually doing zero processing when I receive the message, seems somewhat surprising to me if it is the case that I'm not processing fast enough. I will look deeper into what is happening.

Nick

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

jim.carroll avatar image jim.carroll

Strange indeed, but yes, you are correct, that log message means the ADS was unable to send a message because the socket and its buffer pool have no more room. This usually occurs because the client is reading slowly or the connection is slow.

Keep us posted on what you find. It's also possible that the volume of the response messages may be enough to fill the socket and buffer pool. If so, configuring the ADS to have a larger buffer pool may help alleviate the problem.

nick.zincone avatar image nick.zincone jim.carroll

Thanks Jim. I would consider configuring the ADS except this issue never seems to happen with the other examples I tried (node and Java). I initially thought this issue could be a result of my build or runtime environment, however, I had a colleague try as well and they too encountered this issue. In addition, I have also tried changing the default buffer and TCP buffer sizes without any difference. Still investigating.

Click below to post an Idea Post Idea