How about mod MAX_INT? It would wrap back to 0 and make it more consistent with
at least SNMP counters that roll over to 0 when maxed. A monitoring and
graphing system can account for this by recognizing the current value is less
than the previous and typically uses the previous and current
Sorry that should read “and if the value exceeds MAX_INT”
On Wed, Feb 13, 2019 at 8:21 PM Ryan McMahon wrote:
> +1 to introducing a new method which returns the stat as long per Jake’s
> suggestion. I vote for getInt() to downcast as an int, and the value
> exceeds MAX_INT, return MAX_INT and
+1 to introducing a new method which returns the stat as long per Jake’s
suggestion. I vote for getInt() to downcast as an int, and the value
exceeds MAX_INT, return MAX_INT and possibly add a warning message which
points users to the new long version of the method. I think throwing an
exception
If there are no other takers, I can act as release manager for 1.9 and will
cut a release branch this week.
On Tue, Jan 29, 2019 at 1:50 PM Alexander Murmann
wrote:
> Hi everyone!
>
> February 1st is approaching rapidly which means it's almost time to cut
> the 1.9 release. Who is interested
Is it possible for the underlying counter to be maintained as a long, and
change the getInt method to return as normal when the value is within MAX_INT,
otherwise throw an exception and/or return MAX_INT when the long value would
overflow an int?
For the MX Bean, should we keep (but deprecate)
+1 to what Jake said about MemberMXBean - that is definitely a public API
class, so we need to deprecate the old method and introduce a new one.
I'm also not clear about the stats. Technically, they are discoverable
through the public API, so maybe? It seems like they are mix of things
users
I don’t consider the stats API a public API. I think it is a leaked internal
API. Do we document the interactions with this API? Do we document the stat
names? I consider documentation the API. I can discover all sorts of exposed
methods in a library but shouldn’t consider them contracted API.
Despite our attempts to make precheckin free of flaky failures, I'm still
seeing at least one flaky failure (that does not reproduce and does not
correlate to my PR changes) in every single precheckin launched for my PRs.
For example, the latest one (
Quite a few Geode stats are currently defined as IntCounters which very
easily wrap past Integer.MAX_VALUE. Some users wanted these stats to not
wrap to negative MAX_VALUE, so my team defined the following two tickets
and changed them to LongCounters on the develop branch:
GEODE-6345:
+1 - Thanks for the mention of the native client!
On Wed, Feb 13, 2019 at 9:05 AM Dave Barnes wrote:
> I've incorporated Anthony's additions and an addition of my own (Karen
> succeeded Mark as PMC chair).
> Any other suggestions? Review closes at noon PST.
>
> On Wed, Feb 13, 2019 at 7:22 AM
On Wed, Feb 13, 2019 at 9:03 AM Dan Smith wrote:
…
> I can switch them to @MakeReferentImmutable if that makes more sense.
>
> -Dan
I think you understand my concerns. I trust you to decide what's best.
I've incorporated Anthony's additions and an addition of my own (Karen
succeeded Mark as PMC chair).
Any other suggestions? Review closes at noon PST.
On Wed, Feb 13, 2019 at 7:22 AM Anthony Baker wrote:
> Under activity I would add:
>
> - Added benchmarks to baseline performance
> - Explored
Regarding @Immutable - yes it's intentionally a field annotation as well as
a class annotation. The reason to make it a field annotation is that the
static analysis tools aren't quite cool enough to figure out if a field is
really immutable so we have to manually tell the tool that the field is
+1 - Looks good to me.
-Dan
On Tue, Feb 12, 2019 at 3:34 PM Dave Barnes wrote:
> Please respond by noon tomorrow.
> Pretty complete, as far as I know, except for public events and
> presentations.
> Thanks,
> Dave
>
> Description:
>
> Apache Geode provides a database-like consistency model,
Under activity I would add:
- Added benchmarks to baseline performance
- Explored the use of micrometer for exposing metrics of cache operations
Anthony
> On Feb 12, 2019, at 3:34 PM, Dave Barnes wrote:
>
> Please respond by noon tomorrow.
> Pretty complete, as far as I know, except for
15 matches
Mail list logo
