Re: Gradle build broken?

2019-01-23 Thread Galen O'Sullivan 
I tried cleaning as well. It turns out that the directory I needed to
remove was `~/.m2`. I guess the package cache was corrupted. Transient
failure?

On Tue, Jan 22, 2019 at 5:49 PM Galen O'Sullivan 
wrote:

> 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: Gradle build broken?

2019-01-23 Thread Kirk Lund 
I saw the same problem a few weeks ago. I ended up deleting the directories
in my .m2 repository and rebuilding. That seemed to fix it.

The cause seems to have something to do with that log4j core tests jar, but
I'm not sure why our build would be looking for the corresponding sources
jar. If anyone knows what would cause this, let me know!

On Tue, Jan 22, 2019 at 5:49 PM Galen O'Sullivan 
wrote:

> 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://urldefense.proofpoint.com/v2/url?u=https-3A__help.gradle.org&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=oz-4MoNONnm7XFd0NWMb3g&m=xgO6NyJSiftex8QXD5QJ4pgduD0C7W-ovrychCh4GmU&s=ajS6jzRPUeYjdT-R2p1HDX_9A_660FRZjsJ4cRMD-_Y&e=
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.gradle.org_5.0_userguide_command-5Fline-5Finterface.html-23sec-3Acommand-5Fline-5Fwarnings&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=oz-4MoNONnm7XFd0NWMb3g&m=xgO6NyJSiftex8QXD5QJ4pgduD0C7W-ovrychCh4GmU&s=ZeKKsj9s-7D4ccqAPBX7hJddwZPlMHkGll8cCJayDbQ&e=
>
> BUILD FAILED in 24s
>

Re: Gradle build broken?

2019-01-23 Thread Jared Stewart 
You might also try ./gradlew build --refresh-dependencies if this happens
again.

On Wed, Jan 23, 2019 at 9:38 AM Kirk Lund  wrote:

> I saw the same problem a few weeks ago. I ended up deleting the directories
> in my .m2 repository and rebuilding. That seemed to fix it.
>
> The cause seems to have something to do with that log4j core tests jar, but
> I'm not sure why our build would be looking for the corresponding sources
> jar. If anyone knows what would cause this, let me know!
>
> On Tue, Jan 22, 2019 at 5:49 PM Galen O'Sullivan 
> wrote:
>
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__help.gradle.org&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=oz-4MoNONnm7XFd0NWMb3g&m=xgO6NyJSiftex8QXD5QJ4pgduD0C7W-ovrychCh4GmU&s=ajS6jzRPUeYjdT-R2p1HDX_9A_660FRZjsJ4cRMD-_Y&e=
> >
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.gradle.org_5.0_userguide_command-5Fline-5Finterface.html-23sec-3Acommand-5Fline-5Fwarnings&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=oz-4MoNONnm7XFd0NWMb3g&m=xgO6NyJSiftex8QXD5QJ4pgduD0C7W-ovrychCh4GmU&s=ZeKKsj9s-7D4ccqAPBX7hJddwZPlMHkGll8cCJayDbQ&e=
> >
> > BUILD FAILED in 24s
> >
>

dunit hang in ClusterConfigLocatorRestartDUnitTest

2019-01-23 Thread Kirk Lund 
I hit a dunit hang in one of my precheckin runs.

The only test mentioned in callstacks/dunit-hangs.txt is
ClusterConfigLocatorRestartDUnitTest.

I see some Pooled Message Processor threads that might be hung waiting for
the same
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject on
OverflowQueueWithDMStat.

ClusterConfigurationLoader and FunctionStreamingResultCollector might be
involved.

Here's the link if someone working on cluster config wants to download the
tgz and look through the callstacks:
https://concourse.apachegeode-ci.info/builds/31696

"RMI TCP Connection(1)-172.17.0.14" #34 daemon prio=5 os_prio=0
cpu=1485.20ms elapsed=4864.19s tid=0x7f6950001800 nid=0x213 waiting on
condition  [0x7f696b5f3000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.1/Native Method)
- parking to wait for  <0xed7bf538> (a
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.1
/LockSupport.java:234)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(java.base@11.0.1
/AbstractQueuedSynchronizer.java:1079)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@11.0.1
/AbstractQueuedSynchronizer.java:1369)
at java.util.concurrent.CountDownLatch.await(java.base@11.0.1
/CountDownLatch.java:278)
at
org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:61)
at
org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:714)
at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:785)
at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:762)
at
org.apache.geode.internal.cache.execute.FunctionStreamingResultCollector.getResult(FunctionStreamingResultCollector.java:142)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromOneLocator(ClusterConfigurationLoader.java:313)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:282)
at
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1074)
at
org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:859)
- locked <0xed7bf7f8> (a java.lang.Class for
org.apache.geode.internal.cache.GemFireCacheImpl)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:796)
- locked <0xed7bf7f8> (a java.lang.Class for
org.apache.geode.internal.cache.GemFireCacheImpl)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:785)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:176)
- locked <0xed6005b0> (a java.lang.Class for
org.apache.geode.cache.CacheFactory)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:223)
- locked <0xed6005b0> (a java.lang.Class for
org.apache.geode.cache.CacheFactory)
at
org.apache.geode.test.junit.rules.ServerStarterRule.startServer(ServerStarterRule.java:174)
at
org.apache.geode.test.junit.rules.ServerStarterRule.before(ServerStarterRule.java:80)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startServerVM$729766c4$1(ClusterStartupRule.java:248)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$$Lambda$131/0x0008401c0840.call(Unknown
Source)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.1/Method.java:566)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:69)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.1/Method.java:566)
at sun.rmi.server.UnicastServerRef.dispatch(java.rmi@11.0.1
/UnicastServerRef.java:359)
at sun.rmi.transport.Transport$1.run(java.rmi@11.0.1
/Transport.java:200)
at sun.rmi.transport.Transport$1.ru

Re: dunit hang in ClusterConfigLocatorRestartDUnitTest

2019-01-23 Thread Kirk Lund 
Looks like there's a Test worker thread that keeps running and changing.
Maybe the dunit test is pushing the dunit job over its time limit:

"Test worker" #27 prio=5 os_prio=0 cpu=1332.79ms elapsed=4871.91s
tid=0x7f67c4a78800 nid=0x1c runnable  [0x7f675fbf3000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(java.base@11.0.1/Native
Method)
at java.net.SocketInputStream.socketRead(java.base@11.0.1
/SocketInputStream.java:115)
at java.net.SocketInputStream.read(java.base@11.0.1
/SocketInputStream.java:168)
at java.net.SocketInputStream.read(java.base@11.0.1
/SocketInputStream.java:140)
at java.io.BufferedInputStream.fill(java.base@11.0.1
/BufferedInputStream.java:252)
at java.io.BufferedInputStream.read(java.base@11.0.1
/BufferedInputStream.java:271)
- locked <0xd131b270> (a java.io.BufferedInputStream)
at java.io.DataInputStream.readByte(java.base@11.0.1
/DataInputStream.java:270)
at sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.1
/StreamRemoteCall.java:222)
at sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.1
/UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.1
/RemoteObjectInvocationHandler.java:209)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.1
/RemoteObjectInvocationHandler.java:161)
at com.sun.proxy.$Proxy32.executeMethodOnObject(Unknown Source)
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:530)
at org.apache.geode.test.dunit.VM.invoke(VM.java:390)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:239)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:232)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:218)
at
org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterOneLocatorDies(ClusterConfigLocatorRestartDUnitTest.java:98)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.1/Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
at
org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.1/Method.java:566)
at
org.gradle.internal.dispatch.Reflection

Re: dunit hang in ClusterConfigLocatorRestartDUnitTest

2019-01-23 Thread Dan Smith 
Thanks Kirk - this is GEODE-5676. I'm glad the callstacks are finally
working again, that should help us track this down! I'll update that ticket
with anything I can figure out from this failure.

-Dan

On Wed, Jan 23, 2019 at 10:05 AM Kirk Lund  wrote:

> Looks like there's a Test worker thread that keeps running and changing.
> Maybe the dunit test is pushing the dunit job over its time limit:
>
> "Test worker" #27 prio=5 os_prio=0 cpu=1332.79ms elapsed=4871.91s
> tid=0x7f67c4a78800 nid=0x1c runnable  [0x7f675fbf3000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(java.base@11.0.1/Native
> Method)
> at java.net.SocketInputStream.socketRead(java.base@11.0.1
> /SocketInputStream.java:115)
> at java.net.SocketInputStream.read(java.base@11.0.1
> /SocketInputStream.java:168)
> at java.net.SocketInputStream.read(java.base@11.0.1
> /SocketInputStream.java:140)
> at java.io.BufferedInputStream.fill(java.base@11.0.1
> /BufferedInputStream.java:252)
> at java.io.BufferedInputStream.read(java.base@11.0.1
> /BufferedInputStream.java:271)
> - locked <0xd131b270> (a java.io.BufferedInputStream)
> at java.io.DataInputStream.readByte(java.base@11.0.1
> /DataInputStream.java:270)
> at sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.1
> /StreamRemoteCall.java:222)
> at sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.1
> /UnicastRef.java:161)
> at
>
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.1
> /RemoteObjectInvocationHandler.java:209)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.1
> /RemoteObjectInvocationHandler.java:161)
> at com.sun.proxy.$Proxy32.executeMethodOnObject(Unknown Source)
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:530)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:390)
> at
>
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:239)
> at
>
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:232)
> at
>
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:218)
> at
>
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterOneLocatorDies(ClusterConfigLocatorRestartDUnitTest.java:98)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1
> /Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
> /NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
> /DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11.0.1
> /Method.java:566)
> at
>
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
>
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
>
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
>
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
>
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
>
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
>
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
>
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
>
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
>
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
>
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
>
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.jav

Re: dunit hang in ClusterConfigLocatorRestartDUnitTest

2019-01-23 Thread Bruce Schuchardt 
Dan, 5676 is for the other test in the same class.  I'm working on that 
other test as part of fixing GEODE-6309.


On 1/23/19 10:43 AM, Dan Smith wrote:

Thanks Kirk - this is GEODE-5676. I'm glad the callstacks are finally
working again, that should help us track this down! I'll update that ticket
with anything I can figure out from this failure.

-Dan

On Wed, Jan 23, 2019 at 10:05 AM Kirk Lund  wrote:


Looks like there's a Test worker thread that keeps running and changing.
Maybe the dunit test is pushing the dunit job over its time limit:

"Test worker" #27 prio=5 os_prio=0 cpu=1332.79ms elapsed=4871.91s
tid=0x7f67c4a78800 nid=0x1c runnable  [0x7f675fbf3000]
java.lang.Thread.State: RUNNABLE
 at java.net.SocketInputStream.socketRead0(java.base@11.0.1/Native
Method)
 at java.net.SocketInputStream.socketRead(java.base@11.0.1
/SocketInputStream.java:115)
 at java.net.SocketInputStream.read(java.base@11.0.1
/SocketInputStream.java:168)
 at java.net.SocketInputStream.read(java.base@11.0.1
/SocketInputStream.java:140)
 at java.io.BufferedInputStream.fill(java.base@11.0.1
/BufferedInputStream.java:252)
 at java.io.BufferedInputStream.read(java.base@11.0.1
/BufferedInputStream.java:271)
 - locked <0xd131b270> (a java.io.BufferedInputStream)
 at java.io.DataInputStream.readByte(java.base@11.0.1
/DataInputStream.java:270)
 at sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.1
/StreamRemoteCall.java:222)
 at sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.1
/UnicastRef.java:161)
 at

java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.1
/RemoteObjectInvocationHandler.java:209)
 at
java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.1
/RemoteObjectInvocationHandler.java:161)
 at com.sun.proxy.$Proxy32.executeMethodOnObject(Unknown Source)
 at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:530)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:390)
 at

org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:239)
 at

org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:232)
 at

org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:218)
 at

org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterOneLocatorDies(ClusterConfigLocatorRestartDUnitTest.java:98)
 at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1
/Native
Method)
 at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
 at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
/DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(java.base@11.0.1
/Method.java:566)
 at

org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
 at

org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
 at

org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
 at

org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
 at

org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
 at
org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
 at org.junit.rules.RunRules.evaluate(RunRules.java:20)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
 at

org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
 at

org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
 at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
 at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
 at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
 at

org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
 at

org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
 at

org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcesso

Re: dunit hang in ClusterConfigLocatorRestartDUnitTest

2019-01-23 Thread Bruce Schuchardt 
There is a ticket open for a hang in the other test method in that same 
class.


On 1/23/19 10:04 AM, Kirk Lund wrote:

Looks like there's a Test worker thread that keeps running and changing.
Maybe the dunit test is pushing the dunit job over its time limit:

"Test worker" #27 prio=5 os_prio=0 cpu=1332.79ms elapsed=4871.91s
tid=0x7f67c4a78800 nid=0x1c runnable  [0x7f675fbf3000]
java.lang.Thread.State: RUNNABLE
 at java.net.SocketInputStream.socketRead0(java.base@11.0.1/Native
Method)
 at java.net.SocketInputStream.socketRead(java.base@11.0.1
/SocketInputStream.java:115)
 at java.net.SocketInputStream.read(java.base@11.0.1
/SocketInputStream.java:168)
 at java.net.SocketInputStream.read(java.base@11.0.1
/SocketInputStream.java:140)
 at java.io.BufferedInputStream.fill(java.base@11.0.1
/BufferedInputStream.java:252)
 at java.io.BufferedInputStream.read(java.base@11.0.1
/BufferedInputStream.java:271)
 - locked <0xd131b270> (a java.io.BufferedInputStream)
 at java.io.DataInputStream.readByte(java.base@11.0.1
/DataInputStream.java:270)
 at sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.1
/StreamRemoteCall.java:222)
 at sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.1
/UnicastRef.java:161)
 at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.1
/RemoteObjectInvocationHandler.java:209)
 at
java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.1
/RemoteObjectInvocationHandler.java:161)
 at com.sun.proxy.$Proxy32.executeMethodOnObject(Unknown Source)
 at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:530)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:390)
 at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:239)
 at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:232)
 at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:218)
 at
org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterOneLocatorDies(ClusterConfigLocatorRestartDUnitTest.java:98)
 at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1/Native
Method)
 at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
 at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.1
/DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(java.base@11.0.1/Method.java:566)
 at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
 at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
 at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
 at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
 at
org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
 at
org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
 at org.junit.rules.RunRules.evaluate(RunRules.java:20)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
 at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
 at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
 at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
 at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
 at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
 at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
 at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
 at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.1/Native
Method)
 at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.1
/NativeMethodAccessorImpl.java:62)
 at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0

Re: Gradle build broken?

2019-01-23 Thread Galen O'Sullivan 
Thanks, Jared. I'll try that next time.

On Wed, Jan 23, 2019 at 9:53 AM Jared Stewart 
wrote:

> You might also try ./gradlew build --refresh-dependencies if this happens
> again.
>
> On Wed, Jan 23, 2019 at 9:38 AM Kirk Lund  wrote:
>
> > I saw the same problem a few weeks ago. I ended up deleting the
> directories
> > in my .m2 repository and rebuilding. That seemed to fix it.
> >
> > The cause seems to have something to do with that log4j core tests jar,
> but
> > I'm not sure why our build would be looking for the corresponding sources
> > jar. If anyone knows what would cause this, let me know!
> >
> > On Tue, Jan 22, 2019 at 5:49 PM Galen O'Sullivan 
> > wrote:
> >
> > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__help.gradle.org&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=oz-4MoNONnm7XFd0NWMb3g&m=xgO6NyJSiftex8QXD5QJ4pgduD0C7W-ovrychCh4GmU&s=ajS6jzRPUeYjdT-R2p1HDX_9A_660FRZjsJ4cRMD-_Y&e=
> > >
> > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.gradle.org_5.0_userguide_command-5Fline-5Finterface.html-23sec-3Acommand-5Fline-5Fwarnings&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=oz-4MoNONnm7XFd0NWMb3g&m=xgO6NyJSiftex8QXD5QJ4pgduD0C7W-ovrychCh4GmU&s=ZeKKsj9s-7D4ccqAPBX7hJddwZPlMHkGll8cCJayDbQ&e=
> > >
> > > BUILD FAILED in 24s
> > >
> >
>

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

2019-01-23 Thread Alexander Murmann 
Ryan, thank you so much for the great explanation of your proposal!

This seems very sound and you and David got me convinced that it's the
right thing to change the default. To me the question now is one of timing.
Is this something we can change in a minor release or do we have to wait
for Geode 2.0? I think we have quite a few defaults we'd like to update.
However, a user might have a system in prod that relies on defaults being a
certain way and upgrading to the next minor shouldn't require any work on
their end to prevent any negative impact on their system.

Thoughts?

On Tue, Jan 22, 2019 at 12:33 PM David Wisler  wrote:

> 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
> <
> http://www.google.com/url?q=http%3A%2F%2Fsupport.pivotal.io%2F&sa=D&sntz=1&usg=AFQjCNGDBr_XSKC18wot5h3OkKoZ84Vn7Q
> >
>   |  Mon-Fri  8:00am to 5:00pm PST  |  1-877-477-2269
> [image: support]
> <
> https://www.google.com/url?q=https%3A%2F%2Fsupport.pivotal.io%2F&sa=D&sntz=1&usg=AFQjCNEvwKLjzu29inKwy4jJjKsboqGMCg
> >
>  [image: twitter]
> <
> https://www.google.com/url?q=https%3A%2F%2Ftwitter.com%2Fpivotal&sa=D&sntz=1&usg=AFQjCNG1FcqkH5ghKsSG6UkdeUzjSuDSHg
> >
>  [image: linkedin]
> <
> https://www.google.com/url?q=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2F3048967&sa=D&sntz=1&usg=AFQjCNHOQGYmDYIQz06S3-vAuqzf8bN8Yw
> >
>  [image: facebook]
> <
> https://www.google.com/url?q=https%3A%