You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up of #2069:
If a large number of AMQP/MQTT devices get disconnected by an adapter shutdown, the subsequent reconnects to another adapter instance will produce many "registerCommandConsumer" requests to the Command Router (potentially leading to "no credits" errors), which could probably better be done as batch requests.
(Implementation of batch requests had been already started in the abandoned PR #3386.)
It could also be considered creating batch requests for "unregisterCommandConsumer" requests, although the question is whether this is really needed.
The text was updated successfully, but these errors were encountered:
The discussed batch feature has benefit in respect of (API call) optimization but has drawback of client delay.
The batch requests will impose delay on the client requests. See #2069 (comment)
The batch requests would be triggered in a configurable interval or if the batch size is reached (the first come)
Thus the client delay depends on the configurable interval. The interval could be in the range of hundred of milliseconds up to a second. The only case where delay is not required is when doing the unregister as part of a AMQP/MQTT connection disconnect.
I think the batch requests have main value during adapter start up when all devices connects and do command subscription.
At that case the delay on the clients would be less as the blocking wait interval would be applied only on the last batch.
Follow-up of #2069:
If a large number of AMQP/MQTT devices get disconnected by an adapter shutdown, the subsequent reconnects to another adapter instance will produce many "registerCommandConsumer" requests to the Command Router (potentially leading to "no credits" errors), which could probably better be done as batch requests.
(Implementation of batch requests had been already started in the abandoned PR #3386.)
It could also be considered creating batch requests for "unregisterCommandConsumer" requests, although the question is whether this is really needed.
The text was updated successfully, but these errors were encountered: