On 9/6/23 18:40, Yann Ylavic wrote:
On Wed, Sep 6, 2023 at 6:29 PM Yann Ylavic wrote:
As for the memory orders on success/failure, they have nothing to do
with the likeliness of success/failure
Well the memory orderings specified can certainly influence the
likeliness of success/failure
On Wed, Sep 6, 2023 at 6:29 PM Yann Ylavic wrote:
>
> As for the memory orders on success/failure, they have nothing to do
> with the likeliness of success/failure
Well the memory orderings specified can certainly influence the
likeliness of success/failure since a weaker ordering implies less
On Wed, Sep 6, 2023 at 1:17 PM jean-frederic clere wrote:
>
> On 8/31/23 18:20, Jim Jagielski wrote:
> > Isn't the call to find the best balancer mutex protected?
>
> Look to apr_atomic_cas32() and the APR code (1.7.x) I noted that we
> don't test the return value of __atomic_compare_exchange_n()
On 8/31/23 18:20, Jim Jagielski wrote:
Isn't the call to find the best balancer mutex protected?
Look to apr_atomic_cas32() and the APR code (1.7.x) I noted that we
don't test the return value of __atomic_compare_exchange_n()
+++
PR_DECLARE(apr_uint32_t) apr_atomic_cas32(volatile
On 8/31/23 18:23, Jim Jagielski wrote:
IIRC, the goal of having an "aging" function was to handle this exact kind of
thing, where values could be normalized over a long period of time so that old entries
that may skew results are not weighted as heavily as new ones.
So the reset() and age()
On 8/31/23 18:46, Rainer Jung wrote:
Hi there,
mod_jk for example uses such aging, but only for the non busyness case.
busyness is meant to show the number of currently in-flight requests, so
aging isn't a good fit there. Old load numbers are never part of
busyness. But busyness is the mode
Hi there,
mod_jk for example uses such aging, but only for the non busyness case.
busyness is meant to show the number of currently in-flight requests, so
aging isn't a good fit there. Old load numbers are never part of
busyness. But busyness is the mode that is most sensitive to the numer
IIRC, the goal of having an "aging" function was to handle this exact kind of
thing, where values could be normalized over a long period of time so that old
entries that may skew results are not weighted as heavily as new ones.
> On Aug 30, 2023, at 11:19 AM, jean-frederic clere wrote:
>
>
Isn't the call to find the best balancer mutex protected?
> On Aug 31, 2023, at 7:44 AM, jean-frederic clere wrote:
>
> On 8/30/23 17:33, Rainer Jung wrote:
>> Hi JFC,
>> I have not checked ur current code, but the topic reminds me of our history
>> in mod_jk land. There we switched the
On 8/30/23 17:33, Rainer Jung wrote:
Hi JFC,
I have not checked ur current code, but the topic reminds me of our
history in mod_jk land. There we switched the counters to atomics were
available. The other problematic part could be how to handle process
local counters versus global counters.
Hi JFC,
I have not checked ur current code, but the topic reminds me of our
history in mod_jk land. There we switched the counters to atomics were
available. The other problematic part could be how to handle process
local counters versus global counters.
Busyness was especially problematic
Hi,
All the balancers have thread/process safe issues, but with bybusyness
the effect is worse, basically a worker may stay with a busy count
greater than zero even no request is being processed.
busy is displayed in the balancer_handler() so users/customers will
notice the value doesn't
12 matches
Mail list logo
