Gradle build broken?

[Galen O'Sullivan]

I'm getting the following failure building Geode on the latest develop.
I've tried `rm -r .gradle ~/.gradle`, to no avail. Any ideas?

Thanks,
Galen

---

./gradlew dev
> Task :geode-core:compileIntegrationTestJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-core:compileIntegrationTestJava'.
> Could not resolve all files for configuration
':geode-core:integrationTestCompileClasspath'.
   > Could not find log4j-core-tests.jar
(org.apache.logging.log4j:log4j-core:2.11.1).
 Searched in the following locations:

file:/Users/gosullivan/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-tests.jar
   > Could not find log4j-core-test-sources.jar
(org.apache.logging.log4j:log4j-core:2.11.1).
 Searched in the following locations:

file:/Users/gosullivan/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-test-sources.jar

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible
with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See
https://docs.gradle.org/5.0/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 24s

Re: [Proposal] Change default gemfire.memoryEventTolerance from 1 to 0

[David Wisler]

I would add that, by changing the default to 0, we can then skip all of the
"special" logic that almost no customers use.With a default of 1, we go
into this logic every time unnecessarily, even when customers have not
explicitly told us to "tolerate" an eviction or critical state change.I
am in favor of this default change to 0, and also add that there are no
customers who would even realize such a change in behavior has occurred.
I would also suggest that tolerating 1 critical reading, delaying the
subsequent behaviors in GemFire when above critical, could make us more
vulnerable to OOME's than would be the case by immediately transitioning
state.

My 2 cents.  Thanks for the email Ryan.



On Tue, Jan 22, 2019 at 10:22 AM Ryan McMahon  wrote:

> Hi all,
>
> I am currently fixing a bug
>  with the
> HeapMemoryMonitor event tolerance feature, and came across a decision that
> I thought would be more appropriate for the Geode dev list.
>
> For those familiar with the feature, we are proposing that the default
> gemfire.memoryEventTolerance config parameter value is changed from 1 to 0
> so state transitions from normal to eviction or critical occur immediately
> after reading a single heap-used-bytes event above threshold.  If you are
> unfamiliar with the feature, read on.
>
> The memory event tolerance feature addresses issues with some JVM distros
> that result in sporadic, erroneously high heap-bytes-used readings.  The
> feature was introduced to address this issue in the JRockit JVM, but it has
> been found that other JVM distros are susceptible to this problem as well.
>
> The feature prevents an "unexpected" state transition from a normal state
> to an eviction or critical state by requiring N (configurable) consecutive
> heap-used-byte events above threshold before changing states.  The current
> default configuration is N = 5 for JRockit and N = 1 for all other JVMs.
> In a non-JRockit JVM, this configuration permits a single event above
> threshold WITHOUT causing a state transition.  In other words, by default,
> we allow for a single bad outlier heap-used-bytes reading without going
> into an eviction or critical state.
>
> As part of this bug fix (which involves a failure to reset the tolerance
> counter under some conditions), we opted to remove the special handling for
> JRockit because JRockit is no longer supported.  After removing the JRockit
> handling, we started re-evaluating if a default value of 1 is appropriate
> for all other JVMs.  We are considering changing the default to 0, so state
> transitions would occur immediately if an event above the threshold is
> received.  If a user is facing one of these problematic JVMs, they can then
> change the gemfire.memoryEventTolerance config parameter to increase the
> tolerance.  Our concern is that the default today is potentially masking
> bad heap readings without the user ever knowing.
>
> To summarize, if we change the default from 1 to 0 it would potentially be
> a change in behavior in that we would no longer be masking a single bad
> heap-used-bytes reading i.e. no longer permitting a single outlier without
> changing states.  The user can then decide whether to configure a non-zero
> tolerance to address the situation.  Any thoughts on this change in
> behavior?
>
> Thanks,
> Ryan
>
>
>
>
>
>
>
>

-- 

David Wisler  |  GemFire Support Product Manager  |  503-810-7840 cell
Support.Pivotal.io

  |  Mon-Fri  8:00am to 5:00pm PST  |  1-877-477-2269
[image: support]

 [image: twitter]

 [image: linkedin]

 [image: facebook]

 [image: google plus]  [image: youtube]

[Proposal] Change default gemfire.memoryEventTolerance from 1 to 0

[Ryan McMahon]

Hi all,

I am currently fixing a bug
 with the
HeapMemoryMonitor event tolerance feature, and came across a decision that
I thought would be more appropriate for the Geode dev list.

For those familiar with the feature, we are proposing that the default
gemfire.memoryEventTolerance config parameter value is changed from 1 to 0
so state transitions from normal to eviction or critical occur immediately
after reading a single heap-used-bytes event above threshold.  If you are
unfamiliar with the feature, read on.

The memory event tolerance feature addresses issues with some JVM distros
that result in sporadic, erroneously high heap-bytes-used readings.  The
feature was introduced to address this issue in the JRockit JVM, but it has
been found that other JVM distros are susceptible to this problem as well.

The feature prevents an "unexpected" state transition from a normal state
to an eviction or critical state by requiring N (configurable) consecutive
heap-used-byte events above threshold before changing states.  The current
default configuration is N = 5 for JRockit and N = 1 for all other JVMs.
In a non-JRockit JVM, this configuration permits a single event above
threshold WITHOUT causing a state transition.  In other words, by default,
we allow for a single bad outlier heap-used-bytes reading without going
into an eviction or critical state.

As part of this bug fix (which involves a failure to reset the tolerance
counter under some conditions), we opted to remove the special handling for
JRockit because JRockit is no longer supported.  After removing the JRockit
handling, we started re-evaluating if a default value of 1 is appropriate
for all other JVMs.  We are considering changing the default to 0, so state
transitions would occur immediately if an event above the threshold is
received.  If a user is facing one of these problematic JVMs, they can then
change the gemfire.memoryEventTolerance config parameter to increase the
tolerance.  Our concern is that the default today is potentially masking
bad heap readings without the user ever knowing.

To summarize, if we change the default from 1 to 0 it would potentially be
a change in behavior in that we would no longer be masking a single bad
heap-used-bytes reading i.e. no longer permitting a single outlier without
changing states.  The user can then decide whether to configure a non-zero
tolerance to address the situation.  Any thoughts on this change in
behavior?

Thanks,
Ryan