Hi @Kam.Anjorin

What you are seeing is the correct behaviour.

As I explained above, the ADS will break down the batch request into individual item requests.

I am not sure what you mean by 'rsslVAProvider does not go thru ADS and ADH'. If you connect the rsslVAProvider to the ADH then it will go through the ADH.

If, however, you connect your consumer directly to a rsslVAProvider example, then off course the ADH and ADS are bypassed, and the rsslVAProvider receives the batch request directly from your consumer. The rsslVAProvider then iterates through each item in the batch element list and sends an individual response for each item in the list.

Therefore, when you connect your consumer directly to the ADS, it is doing a similar thing in its role as the direct and immediate provider to your consumer.

The Consumer to Provider direct connect mechanism is normally used for testing purposes - e.g. when you don't have a TREP system available at that point in time.

In QA and production scenarios, Consumers and Provider applications do not connect directly - they communicate via TREP system components ie. ADH and ADS.

@Kam.Anjorin

You can use rmdstestclient to verify if ADS support batch request.

SupportBatchRequests in the output will show if the ADS support batch request.

To send batch request, you need to use -br parameter.

If you have any further questions, please share the command and output of rmdstestclient.

Hi @Kam.Anjorin

Can you explain what you mean by 'send batch request of 400 symbols is not working due to ADH and ADS breaking the symbol request individually'? What exactly is the sequence of events you were expecting and that you would consider as 'working'?

When you send a batch request to the ADS, the ADS will always split the request into individual requests - as each instrument updates individually and therefore, each instrument requires its own individual event stream. The ADS will close the Batch request event stream and allocate each valid instrument its own event stream + handle.

When you connect your consumer to an ADS, the ADS is the immediate provider in this scenario. It may pass on your individual instrument requests to one or more ADH, which in turn will pass on each individual instrument request to one or more Provider application instances connected to each ADH. The Provider instance will then publish the instrument to the ADH, which will pass it downstream to one an ADS which will then provide that data to your consumer.

The TREP system consisting of ADH and ADS has advanced enterprise features such as resiliency, redundancy, failover, load distribution, standby and so on. So, it does not make sense for an ADS to send a batch request which could potentially consist of thousands of instruments to a single ADH and onward to an single Provider application.

In terms of Batch Close, since each item will have its own event stream, you will need to close each item individually. Alternatively, you could close the Login stream which will close all streams and log you off the server too.

NOTICE: Based on TREP interactive rsslVAProvider and rsslVAConsumer sample UPA C code, I've written my interactive provider to handle RSSL_RQMF_HAS_BATCH requests and RSSL_CLMF_HAS_BATCH close requests. However, when I tested using rmdstestclient with options "br" or "bru", the ADS and ADH broke the batch requests from rmdstestclient to individual item requests. The individual item request is what ADH sent to my interactive provider. Since I have code to walk through the element list of a batch requests I did not get a batch requests from ADH consisting of element list, rather I got each item request.

The UPA example in ValueAdd/Examples/rsslVAProvider/ does not go thru ADS and ADH because I captured the XML TRACE log from ADH and ADS to see if the rsslVAConsumer is sending batch requests thru ADS and ADH. All the XML TRACE logs output for rsslVAConsumer and rsslVAProvider using batch requests are available. None of the data went thru ADS and ADH, except, of course, LOGIN and DIRECTORY SOURCE requests and responses.