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.
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)
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.