> On Mon, Jun 24, 2019 at 7:28 PM Sudheer Vinukonda > <sudheervinuko...@yahoo.com.invalid> wrote:
> > @Weixi Li, > > > > The more I read about your use case, it seems like you could probably > > directly leverage the rate limiting that ATS core already supports (unless > > you’ve other custom requirements). You can configure the below settings per > > origin service in your remap config, and you should get the behavior your > > use case described. > > > > > > proxy.config.http.per_server.connection.max Sudheer, thank you for the advice. The rate-limit in our use case is frequency-based. For example, if the limit is 10 requests / second for google; then we would be violating a contract if google's server admin were to find more than 10 requests / second in their server log. Even with the proxy.config.http.per_server.connection.max set to 1, we could still be sending more than 10 requests per second on that one connection (since the goal of ATS is to be as fast as possible). So we have to stall. Dk, although there is no CDN between clients and ATS in our case, your experience does have me concerned. Honestly I don't understand why stalling one transaction would affect another transaction coming from the same connection (is it not possible to "stall" it in a manner to avoid this?) Leif, with our use-case it's hard to see the TokenBucket + small delay working out, because the timing would not be accurate and the order of the requests would be hard to maintain. I'm still thinking about a possible solution using a global queue and a global timer (and the timer just resuming queued transactions at pre-defined internal), but to implement that: 1. Is it ok to put/store a transaction in an external queue? 2. Is it safe to not call transaction.resume() in a plugin? (What is the API I should call to stall the state machine while not tie up the invoking thread?) 3. What kind of thread/group is safe to be used to call transaction.continue() asynchronously?
