The only reasons we keep those factors as ints rather than floats are:
1. We can't change the struct fields in 2.4.x
2. The rationale that int based operations will "always"
be faster than floating point
2.5.0 doesn't suffer from #1. We can break API/ABI if there's
a good reason. And #2
On Tue, Oct 24, 2017 at 11:58 PM, Jim Jagielski wrote:
> As you said, the external representation as a float is syntactic sugar.
> But the patch breaks that. Someone enters in, for example, 2.50
> and what's displayed in 250, instead of 2.50.
>
> Since all this is normalized by how ldfactor is USE
> On Oct 24, 2017, at 4:16 PM, Yann Ylavic wrote:
>
>
> Meaning that we now have a granularity of 10KB (instead of previous
> 100B, max) before a balancer member can take over the previous one (I
> wondered why several successive small requests were always reaching
> the same backend...).
>
l
As you said, the external representation as a float is syntactic sugar.
But the patch breaks that. Someone enters in, for example, 2.50
and what's displayed in 250, instead of 2.50.
Since all this is normalized by how ldfactor is USED, the algos
still work, but are now more granular, which is what
On Tue, Oct 24, 2017 at 3:28 PM, Jim Jagielski wrote:
> I don't understand this patch. It looks like we are no lingering externally
> representing ldfactor as a float (e.g.: 2.50). Is that right? If so,
> I'm not sure why...
It seems to me that ldfactor expressed as "float" is just syntactic
suga
I don't understand this patch. It looks like we are no lingering externally
representing ldfactor as a float (e.g.: 2.50). Is that right? If so,
I'm not sure why...
> On Oct 24, 2017, at 6:50 AM, yla...@apache.org wrote:
>
> Author: ylavic
> Date: Tue Oct 24 10:50:34 2017
> New Revision: 1813167