+1 for Jake’s approach.
Jake’s approach seems to address the only concern that I know of which is
backward compatibility.
Thanks,
Mark
> On Jun 10, 2019, at 11:20 AM, Robert Houghton wrote:
>
> +1 to @Udo Kohlmeyer comment. If the memory has
> been used, might as well allow us to query the
+1 to @Udo Kohlmeyer comment. If the memory has
been used, might as well allow us to query the values
On Fri, Jun 7, 2019 at 2:18 PM Udo Kohlmeyer wrote:
> +1, if the LongAdders have already added and the additional memory usage
> has already been dealt with, then adding the accessors does not
+1, if the LongAdders have already added and the additional memory usage
has already been dealt with, then adding the accessors does not really
make a difference anymore.
On 6/7/19 13:47, Jacob Barrett wrote:
I like this!
I’d go ahead and change all the usage of the int methods to the long me
+1 - this sounds like a good change to me.
-Dan
On Fri, Jun 7, 2019 at 1:47 PM Jacob Barrett wrote:
> I like this!
>
> I’d go ahead and change all the usage of the int methods to the long
> methods. I’d deprecate the int methods to make it very clear.
>
> If some consumer is using the int metho
I like this!
I’d go ahead and change all the usage of the int methods to the long methods.
I’d deprecate the int methods to make it very clear.
If some consumer is using the int methods they will still work with the same
rollover issues but perhaps with the deprecated warning they will update
We have had a couple of tickets that have problems with 32-bit counters
changing too fast and causing them to be hard to understand when they wrap
around (see GEODE-6425 and GEODE-6834). We have also had problems with some
stats being broken because they were changing the 32-bit one when they
shoul
