FYI: Both clang and GCC support both __sync and __atomic which support 64bit 
ints. We could add that functionality to APR... 

> On Sep 17, 2018, at 8:57 AM, Jim Jagielski <> wrote:
> In principle, I agree w/ making these counters atomic... up to now, some 
> minor discrepancies from "real" has been accepted noise, but the more 
> sophisticated we get, the less we can accept such potential drift.
> +1 to both.
>> On Sep 17, 2018, at 8:44 AM, Rainer Jung <> wrote:
>> I am thinking about making the proxy worker busy count atomic. Currently we 
>> use an apr_size_t in shared memory and increment/decrement simply using the 
>> C ++/-- operators. My (somewhat outdated) experience from mod_jk is, that 
>> this is not necessarily atomic and might lead to missing updates, letting 
>> the proxy worker busy count drift in any direction.
>> Since I am also thinking about implementing a busy limit (per proxy worker), 
>> the correctness of the proxy worker busy count would get much more 
>> important. I think such a configurable limit would be really useful, because 
>> it allows some (limited) form of resource management in a reverse proxy, 
>> allowing to define the maximum number of concurrency that is allowed for 
>> each worker. This will prevent the reverse proxy from getting disfunctional 
>> when some slow worker backend starts to consume more and more reverse proxy 
>> slots. Not in all cases can you counter such a scenario with ambigous 
>> response timeouts, which will also kill sporadic slow requests.
>> Note that apr atomics are 32 bit counters and current proxy worker busy 
>> counts might be 64 bit depending on platform. But real busy (concurrency) 
>> counters will hardly ever exceeed 32 bit limits.
>> Any comments on
>> - making proxy worker busy count atomic (using APR atomics)
>> - adding a feature to restrict the maximum busyness per proxy worker
>> Thanks and regards,
>> Rainer

Reply via email to