On second thought, for such scenarios as below, the throttling or rate-limiting is better realized beyond ODL boundary and not to exercise/depend upon DS level Txn rate-limiter. So, in a sane deployment model, the rate-limiting for cases like below must even eliminate the possibilities of requests landing into ODL and must be contained within the originator (Neutron NB Client for example)
Any thoughts ? Regards Muthu From: controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org> [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Muthukumaran K Sent: Monday, February 12, 2018 11:59 AM To: controller-dev Subject: [controller-dev] Rate limiting during Txn Creation and impact on external systems Hi, As we know, the txn rate-limiter *blocks* creation of new transaction(s) if the permits are not granted by rate-limiter. So, in context of the direct broker clients within ODL , this creates a level of backpressure which is understandable. But if the broker clients are invoked from the edge modules (eg. Neutron NB), the external client(s) could typically block. But the external client (eg. Neutron agent outside ODL process) may have a timeout and can fail the request as consequence. Are such external systems, expected to implement retry based on the timeout (of course with some backoff mechanism) ? What I am trying to understand is - if the external clients do not implement any backoff, can this result in thundering-herd problems ? I do not have a real running usecase on hand to prove/verify this. Would like to hear recommendations if anybody had experienced similar scenario(s). Regards Muthu
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
