I see messages as "Output threshold breached for user" in the ADH log. Does that mean that the TR...

vishal.anand

...EP Feed Handler is slow in consuming data from ADH or is this between ADS and ADH or the client that is requesting data?

I see messages as "Output threshold breached for user" in the ADH log. Does that mean that the TREP Feed Handler is slow in consuming data from ADH or is this between ADS and ADH or the client that is requesting data?

zoya faberov

Hello @vishal.anand,

I try to share some info on this, am a developer, so my viewpoint is limited.

I believe you are correct, one of the connections to ADH, most likely a publisher/feed handler, is not processing the buffer quickly, is being a slow processor/consumer.

It looks like ADH detects

"outputThresholdBreach -

Output threshold high water limit; i.e., the percentage of outgoing buffers in use which indicates a

burdened level. This corresponds to the outputThresholdBreach parameter" condition on it's output buffer.

Do not think this is related to clients/consumer directly, as they share no buffer with ADH. This may be related, to several clients making multiple heavy requests (such as full dictionary download), simultaneously.

I would try increasing guaranteedOutputBuffers and maxOutputBuffers, if you are running with the defaults, to see if this would alleviate the issue.

Also would look into parameters that deal with dictionary downloads.

enableMultipartDictionary : False by default, but if all of your consumers and providers support multi-part dictionary processing, you can try with True, to see if this would alleviate the issue, as it is more efficient and avoids the issue when a heavy full dictionaries contributing to the output threshold breach.

If these do not help, the next step should be to look into the publisher that is triggering the breach on AHD to clear ADH's output buffer (publisher's input) quicker.