Hi @Lars-at-Addicticks

When the maximum number of outstanding requests on the ADS from a user exceeds the OpenWindow value for a service (as reported in the Source Directory response) ,then you would expect to see that ADS log entry.

According to the ADS manual, the item is then added to the overflow queue and should be recovered later once the client has caught up.

With regards the 'Batching provides no extra value for RSSL' comment, I think this whole repeated sentence could be a typo / cut & paste error - I can only see that comment in the RFA Java Config guides.

The older RFA C++ config guides only state 'Batching provides no extra value for SSL connections' - which makes more sense as only RSSL type connections support the Batch Request feature. The RFA_Developer guide states '....The Batching capability works together with RFA’s request throttling. If throttling is enabled, RFA may split a batch request into multiple smaller requests....' in section 6.2.9 Batching Items - where it talks about batching RDM non-admin domain item requests.

Thanks Umer.

I missed the point about "the request is added to the overflow queue". So, in essence, the client application will not notice this. Very good.

Still don't understand the comment about 'Batching provides no extra value for RSSL connections' (disregarding the repeat typo) in the context of the 'throttleBatchCount' config parameter, in particular in a scenario where the ADS advertises that it doesn't support batch requests or when the application itself is not using batch requests.

Here's my understanding: The value for throttleBatchCount simply determines at what point the RFA again starts firing requests against the ADS after it has previously hit throttleMaxCount. Right? So if throttleMaxCount=200 and throttleBatchCount=10, then RFA will fire requests until it can it see that it has 200 un-answered requests. Then it will pause. It will wait until is has only 190 un-answered requests. Then it will start firing requests again .. but it will do so in individual requests (in my scenario). It is not really a batch. So the name of the config variable, throttleBatchCount, is a little bit of a misnomer. It is really more of a 'resume level'. In this light, I do not understand the comment.

Have I completely misunderstood the mechanism? (not unlikely, given the time of day :-))

Hi @Lars-at-Addicticks

I will try and get clarification from the development team.

In the meantime, my understanding is this.

Batch requests related parameters only make sense when using RSSL - as SSL connections do not support Batch request. Therefore, I think the line you quoted is a typo and should have read 'SSL connections' or really should not have been mentioned at all in the RSSL connection section.

The throttleBatchCount parameter is a dual purpose parameter - it is used to configure throttling and also used to configure the Batch facility. If you refer to section 13.2 Batch of the RFA Java v8 Dev guide, you will note it talks about throttleBatchCount in terms of Batch facility:

The Batch feature uses the throttleBatchCount configuration parameter, ... The value of throttleBatchCount defines the maximum batch items included into the batch request message that goes on the wire. When an application requests a batch and the number of items exceeds the throttleBatchCount, RFA internally will split the message in several batch request messages, with each request containing no more items then the parameter....

If you then refer to section 14.5.8 Throttling - it describes throttleBatchCount again but this time in terms of Throttling:

The throttleBatchCount configuration parameter specifies the maximum number of requests that are sent out at a time. When the throttleMaxCount is reached, then this number of responses must be received before any more requests are sent.

Yes, this was a typo. As Umer explained, the intended sentence in the RFA Java Config Guide was:

Batching provides no extra value for SSL connections.