[jira] [Updated] (GEODE-2582) Prototype Protobuf Protocol: Client can send Put Request
[ https://issues.apache.org/jira/browse/GEODE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2582: Description: Using protobuf as the IDL for the [client-server protocol|https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol], GIVEN I'm a community developer writing a new client AND I was given some protofiles AND I have established a connection to the Gemfire server WHEN the client sends over a put message and some data THEN I should be able to see my data in the cache as *JSON* Out of scope: * Stats * PDX * Retry was:A client should be able to send a connection request so that it can start interacting with server and the developer knows things are working. > Prototype Protobuf Protocol: Client can send Put Request > > > Key: GEODE-2582 > URL: https://issues.apache.org/jira/browse/GEODE-2582 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Addison > > Using protobuf as the IDL for the [client-server > protocol|https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol], > GIVEN I'm a community developer writing a new client > AND I was given some protofiles > AND I have established a connection to the Gemfire server > WHEN the client sends over a put message and some data > THEN I should be able to see my data in the cache as *JSON* > Out of scope: > * Stats > * PDX > * Retry -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2582) Prototype Protobuf Protocol: Client can send Put Request
[ https://issues.apache.org/jira/browse/GEODE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-2582: --- Assignee: Galen O'Sullivan > Prototype Protobuf Protocol: Client can send Put Request > > > Key: GEODE-2582 > URL: https://issues.apache.org/jira/browse/GEODE-2582 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Addison >Assignee: Galen O'Sullivan > > Using protobuf as the IDL for the [client-server > protocol|https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol], > GIVEN I'm a community developer writing a new client > AND I was given some protofiles > AND I have established a connection to the Gemfire server > WHEN the client sends over a put message and some data > THEN I should be able to see my data in the cache as *JSON* > Out of scope: > * Stats > * PDX > * Retry -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2582) Prototype Protobuf Protocol: Client can send Put Request
[ https://issues.apache.org/jira/browse/GEODE-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2582: Summary: Prototype Protobuf Protocol: Client can send Put Request (was: Client can connect to a Geode Server) > Prototype Protobuf Protocol: Client can send Put Request > > > Key: GEODE-2582 > URL: https://issues.apache.org/jira/browse/GEODE-2582 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Addison > > A client should be able to send a connection request so that it can start > interacting with server and the developer knows things are working. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
[
https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2859:
Fix Version/s: (was: 1.2.0)
> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
>
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
> Issue Type: Test
> Components: gfsh, membership, messaging, tests
>Reporter: Galen O'Sullivan
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header).
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
> {code}
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.
[jira] [Assigned] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
[
https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan reassigned GEODE-2859:
---
Assignee: (was: Galen O'Sullivan)
> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
>
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
> Issue Type: Test
> Components: gfsh, membership, messaging, tests
>Reporter: Galen O'Sullivan
> Fix For: 1.2.0
>
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header).
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
> {code}
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invok
[jira] [Updated] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
[
https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2859:
Description:
https://builds.apache.org/job/Geode-nightly/821/
This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was
recently updated (https://reviews.apache.org/r/58541/diff/1#index_header).
Probably it needs the same fix or related.
ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
{code}
Error Message
java.lang.AssertionError
Stacktrace
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at
java
[jira] [Updated] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
[ https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2859: Component/s: gfsh > ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI. > > > Key: GEODE-2859 > URL: https://issues.apache.org/jira/browse/GEODE-2859 > Project: Geode > Issue Type: Test > Components: gfsh, membership, messaging, tests >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan > Fix For: 1.2.0 > > > https://builds.apache.org/job/Geode-nightly/821/ > This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was > recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). > Probably it needs the same fix or related. > ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
[ https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2859: Description: https://builds.apache.org/job/Geode-nightly/821/ This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). Probably it needs the same fix or related. ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run. was: https://builds.apache.org/job/Geode-nightly/821/ This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). Probably it needs the same fix or related. > ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI. > > > Key: GEODE-2859 > URL: https://issues.apache.org/jira/browse/GEODE-2859 > Project: Geode > Issue Type: Test > Components: membership, messaging, tests >Reporter: Galen O'Sullivan > Fix For: 1.2.0 > > > https://builds.apache.org/job/Geode-nightly/821/ > This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was > recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). > Probably it needs the same fix or related. > ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
[ https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-2859: --- Assignee: Galen O'Sullivan > ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI. > > > Key: GEODE-2859 > URL: https://issues.apache.org/jira/browse/GEODE-2859 > Project: Geode > Issue Type: Test > Components: membership, messaging, tests >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan > Fix For: 1.2.0 > > > https://builds.apache.org/job/Geode-nightly/821/ > This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was > recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). > Probably it needs the same fix or related. > ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
[ https://issues.apache.org/jira/browse/GEODE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15993411#comment-15993411 ] Galen O'Sullivan commented on GEODE-2859: - related failing tests. > ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI. > > > Key: GEODE-2859 > URL: https://issues.apache.org/jira/browse/GEODE-2859 > Project: Geode > Issue Type: Test > Components: membership, messaging, tests >Reporter: Galen O'Sullivan > Fix For: 1.2.0 > > > https://builds.apache.org/job/Geode-nightly/821/ > This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was > recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). > Probably it needs the same fix or related. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
Galen O'Sullivan created GEODE-2859: --- Summary: ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI. Key: GEODE-2859 URL: https://issues.apache.org/jira/browse/GEODE-2859 Project: Geode Issue Type: Test Components: membership, messaging, tests Reporter: Galen O'Sullivan Fix For: 1.2.0 https://builds.apache.org/job/Geode-nightly/821/ This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). Probably it needs the same fix or related. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2381) Make enums not get so mangled by Spotless
[
https://issues.apache.org/jira/browse/GEODE-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2381.
-
Resolution: Fixed
Assignee: Galen O'Sullivan
Fix Version/s: 1.2.0
> Make enums not get so mangled by Spotless
> -
>
> Key: GEODE-2381
> URL: https://issues.apache.org/jira/browse/GEODE-2381
> Project: Geode
> Issue Type: Bug
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
> Fix For: 1.2.0
>
>
> Perhaps the worst example is in {{CacheXMLVersion}}:
> {code}
> GEMFIRE_3_0(CacheXml.VERSION_3_0, CacheXml.PUBLIC_ID_3_0,
> CacheXml.SYSTEM_ID_3_0, null,
> null), GEMFIRE_4_0(CacheXml.VERSION_4_0, CacheXml.PUBLIC_ID_4_0,
> CacheXml.SYSTEM_ID_4_0, null,
> null), GEMFIRE_4_1(CacheXml.VERSION_4_1, CacheXml.PUBLIC_ID_4_1,
> CacheXml.SYSTEM_ID_4_1,
> null, null), GEMFIRE_5_0(CacheXml.VERSION_5_0,
> CacheXml.PUBLIC_ID_5_0,
> CacheXml.SYSTEM_ID_5_0, null, null),
> GEMFIRE_5_1(CacheXml.VERSION_5_1,
> CacheXml.PUBLIC_ID_5_1, CacheXml.SYSTEM_ID_5_1, null,
> null), GEMFIRE_5_5(
> CacheXml.VERSION_5_5, CacheXml.PUBLIC_ID_5_5,
> CacheXml.SYSTEM_ID_5_5,
> null, null), GEMFIRE_5_7(CacheXml.VERSION_5_7,
> CacheXml.PUBLIC_ID_5_7,
> CacheXml.SYSTEM_ID_5_7, null, null),
> GEMFIRE_5_8(CacheXml.VERSION_5_8,
> CacheXml.PUBLIC_ID_5_8,
> CacheXml.SYSTEM_ID_5_8, null,
> null), GEMFIRE_6_0(CacheXml.VERSION_6_0,
> CacheXml.PUBLIC_ID_6_0,
> CacheXml.SYSTEM_ID_6_0, null, null),
> GEMFIRE_6_1(
> CacheXml.VERSION_6_1,
> CacheXml.PUBLIC_ID_6_1,
> CacheXml.SYSTEM_ID_6_1, null, null),
> GEMFIRE_6_5(
> CacheXml.VERSION_6_5,
> CacheXml.PUBLIC_ID_6_5,
> CacheXml.SYSTEM_ID_6_5, null,
> null), GEMFIRE_6_6(
> CacheXml.VERSION_6_6,
> CacheXml.PUBLIC_ID_6_6,
> CacheXml.SYSTEM_ID_6_6, null,
> null), GEMFIRE_7_0(
> CacheXml.VERSION_7_0,
> CacheXml.PUBLIC_ID_7_0,
> CacheXml.SYSTEM_ID_7_0,
> null,
> null),
> GEMFIRE_8_0(CacheXml.VERSION_8_0,
>
> CacheXml.PUBLIC_ID_8_0,
>
> CacheXml.SYSTEM_ID_8_0, null,
> null),
> GEMFIRE_8_1(CacheXml.VERSION_8_1,
> null, null,
>
> CacheXml.SCHEMA_8_1_LOCATION,
>
> CacheXml.GEMFIRE_NAMESPACE),
> {code}
> I'd love to just format these one per line. This can be done by changing a
> single line in the Spotless eclipse formatter xml file (I'll put up a PR in
> just a minute).
> I'm not sure how attached we are to using {{eclipse-java-google-style.xml}}
> in the same format as upstream (where did it come from exactly?). I also
> noticed that Google has [their own
> tool|https://github.com/google/google-java-format] for formatting text.
> Probably what we have is fine for now, and this modification will make it
> better.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.
[ https://issues.apache.org/jira/browse/GEODE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979039#comment-15979039 ] Galen O'Sullivan commented on GEODE-2746: - https://cwiki.apache.org/confluence/display/GEODE/RPC+framework+evaluation > Investigate and Evaluate Existing RPC frameworks. > - > > Key: GEODE-2746 > URL: https://issues.apache.org/jira/browse/GEODE-2746 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan > > There are several existing RPC frameworks for which you can define the > structure of your protocol and the tool will generate code for talking over > the wire, generally down to serialization of objects. > If one of those RPC frameworks does not fit all our requirements, we'll > design our own binary protocol. This protocol would define both what kind of > messages can be sent and how they are encoded on the wire. How we encode the > objects that we are sending in requests, however, could still be pluggable. > A few contenders: > * [BERT|http://bert-rpc.org] > * [thrift|https://thrift.apache.org/] > * [gRPC|http://www.grpc.io/] > * [Avro|https://avro.apache.org/] > These are two not-entirely-common features we will need to have: > * support for SSL/TLS, ability to connect to a server with IP & port. > * support for push messages from the server without polling (this is needed > for CQs). > This is one half of GEODE-2734. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.
[ https://issues.apache.org/jira/browse/GEODE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-2746: --- Assignee: Galen O'Sullivan > Investigate and Evaluate Existing RPC frameworks. > - > > Key: GEODE-2746 > URL: https://issues.apache.org/jira/browse/GEODE-2746 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan > > There are several existing RPC frameworks for which you can define the > structure of your protocol and the tool will generate code for talking over > the wire, generally down to serialization of objects. > If one of those RPC frameworks does not fit all our requirements, we'll > design our own binary protocol. This protocol would define both what kind of > messages can be sent and how they are encoded on the wire. How we encode the > objects that we are sending in requests, however, could still be pluggable. > A few contenders: > * [BERT|http://bert-rpc.org] > * [thrift|https://thrift.apache.org/] > * [gRPC|http://www.grpc.io/] > * [Avro|https://avro.apache.org/] > These are two not-entirely-common features we will need to have: > * support for SSL/TLS, ability to connect to a server with IP & port. > * support for push messages from the server without polling (this is needed > for CQs). > This is one half of GEODE-2734. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.
[ https://issues.apache.org/jira/browse/GEODE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967884#comment-15967884 ] Galen O'Sullivan commented on GEODE-2746: - gRPC has some issues if we send a whole lot of messages in a stream back to the client, where Netty gets OOM due to a lack of backpressure. It's not quite out but it would take work to make it work. > Investigate and Evaluate Existing RPC frameworks. > - > > Key: GEODE-2746 > URL: https://issues.apache.org/jira/browse/GEODE-2746 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Galen O'Sullivan > > There are several existing RPC frameworks for which you can define the > structure of your protocol and the tool will generate code for talking over > the wire, generally down to serialization of objects. > If one of those RPC frameworks does not fit all our requirements, we'll > design our own binary protocol. This protocol would define both what kind of > messages can be sent and how they are encoded on the wire. How we encode the > objects that we are sending in requests, however, could still be pluggable. > A few contenders: > * [BERT|http://bert-rpc.org] > * [thrift|https://thrift.apache.org/] > * [gRPC|http://www.grpc.io/] > These are two not-entirely-common features we will need to have: > * support for SSL/TLS, ability to connect to a server with IP & port. > * support for push messages from the server without polling (this is needed > for CQs). > This is one half of GEODE-2734. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.
[ https://issues.apache.org/jira/browse/GEODE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2746: Description: There are several existing RPC frameworks for which you can define the structure of your protocol and the tool will generate code for talking over the wire, generally down to serialization of objects. If one of those RPC frameworks does not fit all our requirements, we'll design our own binary protocol. This protocol would define both what kind of messages can be sent and how they are encoded on the wire. How we encode the objects that we are sending in requests, however, could still be pluggable. A few contenders: * [BERT|http://bert-rpc.org] * [thrift|https://thrift.apache.org/] * [gRPC|http://www.grpc.io/] * [Avro|https://avro.apache.org/] These are two not-entirely-common features we will need to have: * support for SSL/TLS, ability to connect to a server with IP & port. * support for push messages from the server without polling (this is needed for CQs). This is one half of GEODE-2734. was: There are several existing RPC frameworks for which you can define the structure of your protocol and the tool will generate code for talking over the wire, generally down to serialization of objects. If one of those RPC frameworks does not fit all our requirements, we'll design our own binary protocol. This protocol would define both what kind of messages can be sent and how they are encoded on the wire. How we encode the objects that we are sending in requests, however, could still be pluggable. A few contenders: * [BERT|http://bert-rpc.org] * [thrift|https://thrift.apache.org/] * [gRPC|http://www.grpc.io/] These are two not-entirely-common features we will need to have: * support for SSL/TLS, ability to connect to a server with IP & port. * support for push messages from the server without polling (this is needed for CQs). This is one half of GEODE-2734. > Investigate and Evaluate Existing RPC frameworks. > - > > Key: GEODE-2746 > URL: https://issues.apache.org/jira/browse/GEODE-2746 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Galen O'Sullivan > > There are several existing RPC frameworks for which you can define the > structure of your protocol and the tool will generate code for talking over > the wire, generally down to serialization of objects. > If one of those RPC frameworks does not fit all our requirements, we'll > design our own binary protocol. This protocol would define both what kind of > messages can be sent and how they are encoded on the wire. How we encode the > objects that we are sending in requests, however, could still be pluggable. > A few contenders: > * [BERT|http://bert-rpc.org] > * [thrift|https://thrift.apache.org/] > * [gRPC|http://www.grpc.io/] > * [Avro|https://avro.apache.org/] > These are two not-entirely-common features we will need to have: > * support for SSL/TLS, ability to connect to a server with IP & port. > * support for push messages from the server without polling (this is needed > for CQs). > This is one half of GEODE-2734. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.
[ https://issues.apache.org/jira/browse/GEODE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963667#comment-15963667 ] Galen O'Sullivan commented on GEODE-2746: - Because Thrift doesn't support server push, I think it is out. There is this hack, but it is too much of a hack for me: http://joelpm.com/2009/04/03/thrift-bidirectional-async-rpc.html > Investigate and Evaluate Existing RPC frameworks. > - > > Key: GEODE-2746 > URL: https://issues.apache.org/jira/browse/GEODE-2746 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Galen O'Sullivan > > There are several existing RPC frameworks for which you can define the > structure of your protocol and the tool will generate code for talking over > the wire, generally down to serialization of objects. > If one of those RPC frameworks does not fit all our requirements, we'll > design our own binary protocol. This protocol would define both what kind of > messages can be sent and how they are encoded on the wire. How we encode the > objects that we are sending in requests, however, could still be pluggable. > A few contenders: > * [BERT|http://bert-rpc.org] > * [thrift|https://thrift.apache.org/] > * [gRPC|http://www.grpc.io/] > These are two not-entirely-common features we will need to have: > * support for SSL/TLS, ability to connect to a server with IP & port. > * support for push messages from the server without polling (this is needed > for CQs). > This is one half of GEODE-2734. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.
[ https://issues.apache.org/jira/browse/GEODE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2746: Description: There are several existing RPC frameworks for which you can define the structure of your protocol and the tool will generate code for talking over the wire, generally down to serialization of objects. If one of those RPC frameworks does not fit all our requirements, we'll design our own binary protocol. This protocol would define both what kind of messages can be sent and how they are encoded on the wire. How we encode the objects that we are sending in requests, however, could still be pluggable. A few contenders: * [BERT|http://bert-rpc.org] * [thrift|https://thrift.apache.org/] * [gRPC|http://www.grpc.io/] These are two not-entirely-common features we will need to have: * support for SSL/TLS, ability to connect to a server with IP & port. * support for push messages from the server without polling (this is needed for CQs). This is one half of GEODE-2734. was: There are several existing RPC frameworks for which you can define the structure of your protocol and the tool will generate code for talking over the wire, generally down to serialization of objects. If one of those RPC frameworks does not fit all our requirements, we'll design our own binary protocol. This protocol would define both what kind of messages can be sent and how they are encoded on the wire. How we encode the objects that we are sending in requests, however, could still be pluggable. A few contenders: * [BERT|http://bert-rpc.org] * [thrift|https://thrift.apache.org/] * [gRPC|http://www.grpc.io/] This is one half of GEODE-2734. > Investigate and Evaluate Existing RPC frameworks. > - > > Key: GEODE-2746 > URL: https://issues.apache.org/jira/browse/GEODE-2746 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Galen O'Sullivan > > There are several existing RPC frameworks for which you can define the > structure of your protocol and the tool will generate code for talking over > the wire, generally down to serialization of objects. > If one of those RPC frameworks does not fit all our requirements, we'll > design our own binary protocol. This protocol would define both what kind of > messages can be sent and how they are encoded on the wire. How we encode the > objects that we are sending in requests, however, could still be pluggable. > A few contenders: > * [BERT|http://bert-rpc.org] > * [thrift|https://thrift.apache.org/] > * [gRPC|http://www.grpc.io/] > These are two not-entirely-common features we will need to have: > * support for SSL/TLS, ability to connect to a server with IP & port. > * support for push messages from the server without polling (this is needed > for CQs). > This is one half of GEODE-2734. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2747) Investigate Binary Encoding Options
Galen O'Sullivan created GEODE-2747: --- Summary: Investigate Binary Encoding Options Key: GEODE-2747 URL: https://issues.apache.org/jira/browse/GEODE-2747 Project: Geode Issue Type: Sub-task Reporter: Galen O'Sullivan Desigining our own binary protocol doesn't mean that we can't use an existing serialization format to send the objects in requests over the wire. Let's look into the existing protocols. * Could thrift be used as a serialization mechanism alone? * Protobuf * Msgpack * BSON * CBOR etc. https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats This is one half of GEODE-2734. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.
Galen O'Sullivan created GEODE-2746: --- Summary: Investigate and Evaluate Existing RPC frameworks. Key: GEODE-2746 URL: https://issues.apache.org/jira/browse/GEODE-2746 Project: Geode Issue Type: Sub-task Reporter: Galen O'Sullivan There are several existing RPC frameworks for which you can define the structure of your protocol and the tool will generate code for talking over the wire, generally down to serialization of objects. If one of those RPC frameworks does not fit all our requirements, we'll design our own binary protocol. This protocol would define both what kind of messages can be sent and how they are encoded on the wire. How we encode the objects that we are sending in requests, however, could still be pluggable. A few contenders: * [BERT|http://bert-rpc.org] * [thrift|https://thrift.apache.org/] * [gRPC|http://www.grpc.io/] This is one half of GEODE-2734. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2708) Update Gradle Wrapper to Gradle 3
Galen O'Sullivan created GEODE-2708:
---
Summary: Update Gradle Wrapper to Gradle 3
Key: GEODE-2708
URL: https://issues.apache.org/jira/browse/GEODE-2708
Project: Geode
Issue Type: Task
Components: build
Reporter: Galen O'Sullivan
It looks like we're still running on a very old version of Gradle. This may be
related to incremental builds not working properly.
{code}
$ ./gradlew --version
Gradle 2.14.1
Build time: 2016-07-18 06:38:37 UTC
Revision: d9e2113d9fb05a5caabba61798bdb8dfdca83719
Groovy: 2.4.4
Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_111 (Oracle Corporation 25.111-b14)
OS: Mac OS X 10.12.3 x86_64
$ gradle --version
Gradle 3.4.1
Build time: 2017-03-03 19:45:41 UTC
Revision: 9eb76efdd3d034dc506c719dac2955efb5ff9a93
Groovy: 2.4.7
Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_111 (Oracle Corporation 25.111-b14)
OS: Mac OS X 10.12.3 x86_64
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2707) Remove TXLockToken
[
https://issues.apache.org/jira/browse/GEODE-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2707:
Issue Type: Task (was: Bug)
> Remove TXLockToken
> --
>
> Key: GEODE-2707
> URL: https://issues.apache.org/jira/browse/GEODE-2707
> Project: Geode
> Issue Type: Task
> Components: distributed lock service
>Reporter: Galen O'Sullivan
>
> The {{TXLockToken}} class doesn't seem to actually be used anywhere in the
> source. Look into the history and remove it if it's no longer needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2707) Remove TXLockToken
Galen O'Sullivan created GEODE-2707:
---
Summary: Remove TXLockToken
Key: GEODE-2707
URL: https://issues.apache.org/jira/browse/GEODE-2707
Project: Geode
Issue Type: Bug
Components: distributed lock service
Reporter: Galen O'Sullivan
The {{TXLockToken}} class doesn't seem to actually be used anywhere in the
source. Look into the history and remove it if it's no longer needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2707) Remove TXLockToken
[
https://issues.apache.org/jira/browse/GEODE-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2707:
Priority: Trivial (was: Major)
> Remove TXLockToken
> --
>
> Key: GEODE-2707
> URL: https://issues.apache.org/jira/browse/GEODE-2707
> Project: Geode
> Issue Type: Task
> Components: distributed lock service
>Reporter: Galen O'Sullivan
>Priority: Trivial
>
> The {{TXLockToken}} class doesn't seem to actually be used anywhere in the
> source. Look into the history and remove it if it's no longer needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2660) Mark Redis Adapter as Experimental
Galen O'Sullivan created GEODE-2660: --- Summary: Mark Redis Adapter as Experimental Key: GEODE-2660 URL: https://issues.apache.org/jira/browse/GEODE-2660 Project: Geode Issue Type: Bug Reporter: Galen O'Sullivan I put this up for a vote recently. The Redis adapter is really not ready for prime time at this point. We should mark it experimental so people don't mistakenly think it's ready, and so that we can change it more readily on develop. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2473) redis-cli hangs if Geode unable to process command properly
[
https://issues.apache.org/jira/browse/GEODE-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15898056#comment-15898056
]
Galen O'Sullivan commented on GEODE-2473:
-
Can reproduce with this in a test that {{extends RedisTestBase}} (the Jedis
will eventually time out, but if you set loglevel to "fine" you'll see an
exception being logged as the loop I mentioned in my last comment just keeps
going):
{code}
@Test
public void testDoubleUnderscoreRegion() {
try (Jedis jedis = defaultJedisInstance()) {
Long res = jedis.hset("__test_region__", "foo", "bar");
}
}
{code}
> redis-cli hangs if Geode unable to process command properly
> ---
>
> Key: GEODE-2473
> URL: https://issues.apache.org/jira/browse/GEODE-2473
> Project: Geode
> Issue Type: Sub-task
> Components: redis
>Reporter: Hitesh Khamesra
>
> Here is the command "HSET companies:1000 name "John Smith""
> "GeodeRedisServer-WorkerThread-1" #86 prio=5 os_prio=0 tid=0x7f1a20002800
> nid=0x4750 sleeping[0x7f1bf0dd9000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.verifyDistributedRegionMbean(CreateAlterDestroyRegionCommands.java:410)
> at
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.createRegion(CreateAlterDestroyRegionCommands.java:371)
> at
> org.apache.geode.redis.internal.RegionProvider.createRegionGlobally(RegionProvider.java:405)
> at
> org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion0(RegionProvider.java:292)
> at
> org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion(RegionProvider.java:212)
> at
> org.apache.geode.redis.internal.executor.hash.HashExecutor.getOrCreateRegion(HashExecutor.java:31)
> at
> org.apache.geode.redis.internal.executor.hash.HSetExecutor.executeCommand(HSetExecutor.java:48)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithoutTransaction(ExecutionHandlerContext.java:235)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:199)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:139)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (GEODE-2473) redis-cli hangs if Geode unable to process command properly
[
https://issues.apache.org/jira/browse/GEODE-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897895#comment-15897895
]
Galen O'Sullivan edited comment on GEODE-2473 at 3/6/17 8:42 PM:
-
The Redis hash, set commands create regions with the name of the hash/set. We
have constraints on region names which mean that regions with names that aren't
roughly alphanumeric will throw errors. However, the errors are caught by GFSH
(which the Redis adapter uses to create regions), and then the GFSH adapter
returns OK. We loop forever in the {{do/while}} loop in
{{RegionProvider.createRegionGlobally(String key)}}.
Result shouldn't be OK in this case.
was (Author: gosullivan):
The Redis hash, set commands create regions with the name of the hash/set. We
have constraints on region names which mean that regions with names that aren't
roughly alphanumeric will throw errors.
> redis-cli hangs if Geode unable to process command properly
> ---
>
> Key: GEODE-2473
> URL: https://issues.apache.org/jira/browse/GEODE-2473
> Project: Geode
> Issue Type: Sub-task
> Components: redis
>Reporter: Hitesh Khamesra
>
> Here is the command "HSET companies:1000 name "John Smith""
> "GeodeRedisServer-WorkerThread-1" #86 prio=5 os_prio=0 tid=0x7f1a20002800
> nid=0x4750 sleeping[0x7f1bf0dd9000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.verifyDistributedRegionMbean(CreateAlterDestroyRegionCommands.java:410)
> at
> org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.createRegion(CreateAlterDestroyRegionCommands.java:371)
> at
> org.apache.geode.redis.internal.RegionProvider.createRegionGlobally(RegionProvider.java:405)
> at
> org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion0(RegionProvider.java:292)
> at
> org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion(RegionProvider.java:212)
> at
> org.apache.geode.redis.internal.executor.hash.HashExecutor.getOrCreateRegion(HashExecutor.java:31)
> at
> org.apache.geode.redis.internal.executor.hash.HSetExecutor.executeCommand(HSetExecutor.java:48)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithoutTransaction(ExecutionHandlerContext.java:235)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:199)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:139)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2597) Redis adapter doesn't handle UTF-8 properly.
[ https://issues.apache.org/jira/browse/GEODE-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2597. - Resolution: Invalid > Redis adapter doesn't handle UTF-8 properly. > > > Key: GEODE-2597 > URL: https://issues.apache.org/jira/browse/GEODE-2597 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Galen O'Sullivan > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2597) Redis adapter doesn't handle UTF-8 properly.
[
https://issues.apache.org/jira/browse/GEODE-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2597:
Description:
{code}
127.0.0.1:6379> hset foo å å
(integer) 1
(2.09s)
127.0.0.1:6379> hget foo å
"\xc3\xa5"
{code}
I thought this was inconsistent with the way Redis works, but it doesn't seem
to be. Probably worth testing before GA.
> Redis adapter doesn't handle UTF-8 properly.
>
>
> Key: GEODE-2597
> URL: https://issues.apache.org/jira/browse/GEODE-2597
> Project: Geode
> Issue Type: Sub-task
> Components: redis
>Reporter: Galen O'Sullivan
>
> {code}
> 127.0.0.1:6379> hset foo å å
> (integer) 1
> (2.09s)
> 127.0.0.1:6379> hget foo å
> "\xc3\xa5"
> {code}
> I thought this was inconsistent with the way Redis works, but it doesn't seem
> to be. Probably worth testing before GA.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2597) Redis adapter doesn't handle UTF-8 properly.
Galen O'Sullivan created GEODE-2597: --- Summary: Redis adapter doesn't handle UTF-8 properly. Key: GEODE-2597 URL: https://issues.apache.org/jira/browse/GEODE-2597 Project: Geode Issue Type: Sub-task Reporter: Galen O'Sullivan -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2473) redis-cli hangs if Geode unable to process command properly
[ https://issues.apache.org/jira/browse/GEODE-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897895#comment-15897895 ] Galen O'Sullivan commented on GEODE-2473: - The Redis hash, set commands create regions with the name of the hash/set. We have constraints on region names which mean that regions with names that aren't roughly alphanumeric will throw errors. > redis-cli hangs if Geode unable to process command properly > --- > > Key: GEODE-2473 > URL: https://issues.apache.org/jira/browse/GEODE-2473 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Hitesh Khamesra > > Here is the command "HSET companies:1000 name "John Smith"" > "GeodeRedisServer-WorkerThread-1" #86 prio=5 os_prio=0 tid=0x7f1a20002800 > nid=0x4750 sleeping[0x7f1bf0dd9000] >java.lang.Thread.State: TIMED_WAITING (sleeping) > at java.lang.Thread.sleep(Native Method) > at > org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.verifyDistributedRegionMbean(CreateAlterDestroyRegionCommands.java:410) > at > org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.createRegion(CreateAlterDestroyRegionCommands.java:371) > at > org.apache.geode.redis.internal.RegionProvider.createRegionGlobally(RegionProvider.java:405) > at > org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion0(RegionProvider.java:292) > at > org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion(RegionProvider.java:212) > at > org.apache.geode.redis.internal.executor.hash.HashExecutor.getOrCreateRegion(HashExecutor.java:31) > at > org.apache.geode.redis.internal.executor.hash.HSetExecutor.executeCommand(HSetExecutor.java:48) > at > org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithoutTransaction(ExecutionHandlerContext.java:235) > at > org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:199) > at > org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:139) > at > io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368) > at > io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353) > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173) > at > io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368) > at > io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353) > at > io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780) > at > io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100) > at > io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497) > at > io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465) > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359) > at > io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2555) Region Management docs page refers to the wrong field
[
https://issues.apache.org/jira/browse/GEODE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2555:
Priority: Minor (was: Major)
> Region Management docs page refers to the wrong field
> -
>
> Key: GEODE-2555
> URL: https://issues.apache.org/jira/browse/GEODE-2555
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.1.0
>Reporter: Galen O'Sullivan
>Priority: Minor
>
> In
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> {code}
>
> {code}
> should be
> {code}
>
> {code}
> The region tag doesn't support an id attribute, only refid. Copypasting the
> given config gives me an error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2555) Region Management docs page refers to the wrong field
[
https://issues.apache.org/jira/browse/GEODE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2555:
Summary: Region Management docs page refers to the wrong field (was:
Region Management refers to the wrong field)
> Region Management docs page refers to the wrong field
> -
>
> Key: GEODE-2555
> URL: https://issues.apache.org/jira/browse/GEODE-2555
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.1.0
>Reporter: Galen O'Sullivan
>
> In
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> {code}
>
> {code}
> should be
> {code}
>
> {code}
> The region tag doesn't support an id attribute, only refid. Copypasting the
> given config gives me an error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2555) Region Management docs page refers to the wrong field
[
https://issues.apache.org/jira/browse/GEODE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2555:
Affects Version/s: 1.1.0
> Region Management docs page refers to the wrong field
> -
>
> Key: GEODE-2555
> URL: https://issues.apache.org/jira/browse/GEODE-2555
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.1.0
>Reporter: Galen O'Sullivan
>
> In
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> {code}
>
> {code}
> should be
> {code}
>
> {code}
> The region tag doesn't support an id attribute, only refid. Copypasting the
> given config gives me an error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2555) Region Management refers to the wrong field
[
https://issues.apache.org/jira/browse/GEODE-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2555:
Summary: Region Management refers to the wrong field (was: Region
Management refers to a field that doesn't work.)
> Region Management refers to the wrong field
> ---
>
> Key: GEODE-2555
> URL: https://issues.apache.org/jira/browse/GEODE-2555
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Galen O'Sullivan
>
> In
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> {code}
>
> {code}
> should be
> {code}
>
> {code}
> The region tag doesn't support an id attribute, only refid. Copypasting the
> given config gives me an error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2555) Region Management refers to a field that doesn't work.
Galen O'Sullivan created GEODE-2555:
---
Summary: Region Management refers to a field that doesn't work.
Key: GEODE-2555
URL: https://issues.apache.org/jira/browse/GEODE-2555
Project: Geode
Issue Type: Bug
Components: docs
Reporter: Galen O'Sullivan
In
https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
{code}
{code}
should be
{code}
{code}
The region tag doesn't support an id attribute, only refid. Copypasting the
given config gives me an error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2554) Geode incubator docs are still up
Galen O'Sullivan created GEODE-2554: --- Summary: Geode incubator docs are still up Key: GEODE-2554 URL: https://issues.apache.org/jira/browse/GEODE-2554 Project: Geode Issue Type: Bug Components: docs Reporter: Galen O'Sullivan Search engines still direct users to the Geode incubating docs, which are at: https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html The most recent docs have an 11 in the URL: https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html The old docs should either be taken down, or the path made to refer to whatever the latest docs are. That way visitors won't get stuck on an ever increasingly stale docs site. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (GEODE-2435) Redis adapter MULTI behavior is different from Redis
[
https://issues.apache.org/jira/browse/GEODE-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877040#comment-15877040
]
Galen O'Sullivan edited comment on GEODE-2435 at 2/21/17 11:54 PM:
---
In addition, we throw errors if regions contain data that is spread across
servers, which is a problem:
{code}
27.0.0.1:6379> multi
OK
127.0.0.1:6379> set foo bar
QUEUED
127.0.0.1:6379> set bar baz
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR This transcation cannot be initiated, make sure the command is
executed against a replicate region or your data is collocated. If you are
using persistent regions, make sure transactions are enabled
{code}
was (Author: gosullivan):
In addition, we throw errors if regions contain data that is spread across
servers, which is a problem:
{code}
(error) ERR This transcation cannot be initiated, make sure the command is
executed against a replicate region or your data is collocated. If you are
using persistent regions, make sure transactions are enabled
{code}
> Redis adapter MULTI behavior is different from Redis
>
>
> Key: GEODE-2435
> URL: https://issues.apache.org/jira/browse/GEODE-2435
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Galen O'Sullivan
>
> {{WATCH}} isn't implemented properly, but this is about returning an error
> instead of nil when we have a {{MULTI}} fail:
> {code}
> $ redis-cli -p 11212
> 127.0.0.1:11212> set a b
> OK
> 127.0.0.1:11212> watch a
> (error) ERR Keys cannot be watched or unwatched because GemFire watches all
> keys by default for transactions
> 127.0.0.1:11212> lpush la boo
> (integer) 1
> (2.09s)
> 127.0.0.1:11212> multi
> OK
> 127.0.0.1:11212> lpush la z
> QUEUED
> 127.0.0.1:11212> lpush la x
> QUEUED
> {code}
> At this point, we {{lpush la foo}} in a different client, then:
> {code}
> 127.0.0.1:11212> exec
> 1) (error) ERR The server had an internal error please try again
> 2) (error) ERR The server had an internal error please try again
> 127.0.0.1:11212>
> {code}
> whereas a Redis instance will simply return nil instead of an error.
> Looking in the logs, I see this:
> {code}
> [error 2017/02/06 13:21:39.493 PST server2
> tid=0x2a] GeodeRedisServer-Unexpected error handler for [id: 0x3ddf9f21,
> /127.0.0.1:58862 => /127.0.0.1:11212]
> java.lang.UnsupportedOperationException: Operations on persist-backup regions
> are not allowed because this thread has an active transaction
> at
> org.apache.geode.internal.cache.TXRegionState.(TXRegionState.java:60)
> at
> org.apache.geode.internal.cache.TXBucketRegionState.(TXBucketRegionState.java:29)
> at org.apache.geode.internal.cache.TXState.writeRegion(TXState.java:252)
> at
> org.apache.geode.internal.cache.TXState.txWriteRegion(TXState.java:1110)
> at
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1365)
> at
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1344)
> at
> org.apache.geode.internal.cache.TXState.getDeserializedValue(TXState.java:1414)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.getDeserializedValue(TXStateProxyImpl.java:352)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1394)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.getLocally(PartitionedRegionDataStore.java:2047)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getFromBucket(PartitionedRegion.java:4022)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findObjectInSystem(PartitionedRegion.java:3399)
> at org.apache.geode.internal.cache.TXState.findObject(TXState.java:1540)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:614)
> at
> org.apache.geode.internal.cache.PartitionedRegion.get(PartitionedRegion.java:3160)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1330)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:282)
> at
> org.apache.geode.redis.internal.executor.list.ListExecutor.pushElements(ListExecutor.java:70)
> at
> org.apache.geode.redis.internal.executor.list.PushExecutor.executeCommand(PushExecutor.java:47)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithTransaction(ExecutionHandlerContext.java:244)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:191)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:137)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.Default
[jira] [Commented] (GEODE-2435) Redis adapter MULTI behavior is different from Redis
[
https://issues.apache.org/jira/browse/GEODE-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877040#comment-15877040
]
Galen O'Sullivan commented on GEODE-2435:
-
In addition, we throw errors if regions contain data that is spread across
servers, which is a problem:
{code}
(error) ERR This transcation cannot be initiated, make sure the command is
executed against a replicate region or your data is collocated. If you are
using persistent regions, make sure transactions are enabled
{code}
> Redis adapter MULTI behavior is different from Redis
>
>
> Key: GEODE-2435
> URL: https://issues.apache.org/jira/browse/GEODE-2435
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Galen O'Sullivan
>
> {{WATCH}} isn't implemented properly, but this is about returning an error
> instead of nil when we have a {{MULTI}} fail:
> {code}
> $ redis-cli -p 11212
> 127.0.0.1:11212> set a b
> OK
> 127.0.0.1:11212> watch a
> (error) ERR Keys cannot be watched or unwatched because GemFire watches all
> keys by default for transactions
> 127.0.0.1:11212> lpush la boo
> (integer) 1
> (2.09s)
> 127.0.0.1:11212> multi
> OK
> 127.0.0.1:11212> lpush la z
> QUEUED
> 127.0.0.1:11212> lpush la x
> QUEUED
> {code}
> At this point, we {{lpush la foo}} in a different client, then:
> {code}
> 127.0.0.1:11212> exec
> 1) (error) ERR The server had an internal error please try again
> 2) (error) ERR The server had an internal error please try again
> 127.0.0.1:11212>
> {code}
> whereas a Redis instance will simply return nil instead of an error.
> Looking in the logs, I see this:
> {code}
> [error 2017/02/06 13:21:39.493 PST server2
> tid=0x2a] GeodeRedisServer-Unexpected error handler for [id: 0x3ddf9f21,
> /127.0.0.1:58862 => /127.0.0.1:11212]
> java.lang.UnsupportedOperationException: Operations on persist-backup regions
> are not allowed because this thread has an active transaction
> at
> org.apache.geode.internal.cache.TXRegionState.(TXRegionState.java:60)
> at
> org.apache.geode.internal.cache.TXBucketRegionState.(TXBucketRegionState.java:29)
> at org.apache.geode.internal.cache.TXState.writeRegion(TXState.java:252)
> at
> org.apache.geode.internal.cache.TXState.txWriteRegion(TXState.java:1110)
> at
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1365)
> at
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1344)
> at
> org.apache.geode.internal.cache.TXState.getDeserializedValue(TXState.java:1414)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.getDeserializedValue(TXStateProxyImpl.java:352)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1394)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.getLocally(PartitionedRegionDataStore.java:2047)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getFromBucket(PartitionedRegion.java:4022)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findObjectInSystem(PartitionedRegion.java:3399)
> at org.apache.geode.internal.cache.TXState.findObject(TXState.java:1540)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:614)
> at
> org.apache.geode.internal.cache.PartitionedRegion.get(PartitionedRegion.java:3160)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1330)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:282)
> at
> org.apache.geode.redis.internal.executor.list.ListExecutor.pushElements(ListExecutor.java:70)
> at
> org.apache.geode.redis.internal.executor.list.PushExecutor.executeCommand(PushExecutor.java:47)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithTransaction(ExecutionHandlerContext.java:244)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:191)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:137)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
> at
> io.netty
[jira] [Updated] (GEODE-109) Bugs in redis adapter when running with multiple vms
[ https://issues.apache.org/jira/browse/GEODE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-109: --- Component/s: redis > Bugs in redis adapter when running with multiple vms > > > Key: GEODE-109 > URL: https://issues.apache.org/jira/browse/GEODE-109 > Project: Geode > Issue Type: Bug > Components: core, redis >Affects Versions: 1.0.0-incubating >Reporter: Vitaliy Gavrilov > Fix For: 1.0.0-incubating.M1 > > > 1) The meta data attached with the redis lists implementation does not always > stay synchronized with the list. > 2) Queries run by sorted set requests fail in execution > 3) Potential deadlock when regions are created simultaneously in different vms -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2435) Redis adapter MULTI behavior is different from Redis
[
https://issues.apache.org/jira/browse/GEODE-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2435:
Component/s: redis
> Redis adapter MULTI behavior is different from Redis
>
>
> Key: GEODE-2435
> URL: https://issues.apache.org/jira/browse/GEODE-2435
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Galen O'Sullivan
>
> {{WATCH}} isn't implemented properly, but this is about returning an error
> instead of nil when we have a {{MULTI}} fail:
> {code}
> $ redis-cli -p 11212
> 127.0.0.1:11212> set a b
> OK
> 127.0.0.1:11212> watch a
> (error) ERR Keys cannot be watched or unwatched because GemFire watches all
> keys by default for transactions
> 127.0.0.1:11212> lpush la boo
> (integer) 1
> (2.09s)
> 127.0.0.1:11212> multi
> OK
> 127.0.0.1:11212> lpush la z
> QUEUED
> 127.0.0.1:11212> lpush la x
> QUEUED
> {code}
> At this point, we {{lpush la foo}} in a different client, then:
> {code}
> 127.0.0.1:11212> exec
> 1) (error) ERR The server had an internal error please try again
> 2) (error) ERR The server had an internal error please try again
> 127.0.0.1:11212>
> {code}
> whereas a Redis instance will simply return nil instead of an error.
> Looking in the logs, I see this:
> {code}
> [error 2017/02/06 13:21:39.493 PST server2
> tid=0x2a] GeodeRedisServer-Unexpected error handler for [id: 0x3ddf9f21,
> /127.0.0.1:58862 => /127.0.0.1:11212]
> java.lang.UnsupportedOperationException: Operations on persist-backup regions
> are not allowed because this thread has an active transaction
> at
> org.apache.geode.internal.cache.TXRegionState.(TXRegionState.java:60)
> at
> org.apache.geode.internal.cache.TXBucketRegionState.(TXBucketRegionState.java:29)
> at org.apache.geode.internal.cache.TXState.writeRegion(TXState.java:252)
> at
> org.apache.geode.internal.cache.TXState.txWriteRegion(TXState.java:1110)
> at
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1365)
> at
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1344)
> at
> org.apache.geode.internal.cache.TXState.getDeserializedValue(TXState.java:1414)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.getDeserializedValue(TXStateProxyImpl.java:352)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1394)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.getLocally(PartitionedRegionDataStore.java:2047)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getFromBucket(PartitionedRegion.java:4022)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findObjectInSystem(PartitionedRegion.java:3399)
> at org.apache.geode.internal.cache.TXState.findObject(TXState.java:1540)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:614)
> at
> org.apache.geode.internal.cache.PartitionedRegion.get(PartitionedRegion.java:3160)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1330)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:282)
> at
> org.apache.geode.redis.internal.executor.list.ListExecutor.pushElements(ListExecutor.java:70)
> at
> org.apache.geode.redis.internal.executor.list.PushExecutor.executeCommand(PushExecutor.java:47)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithTransaction(ExecutionHandlerContext.java:244)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:191)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:137)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)
> at
> io.
[jira] [Commented] (GEODE-2281) can not create redis server as the document describle
[ https://issues.apache.org/jira/browse/GEODE-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877032#comment-15877032 ] Galen O'Sullivan commented on GEODE-2281: - It looks like you have another server running. By default, Geode servers use port 40404, and the server still needs to open a Geode server port. If any other server is bound to that port, Geode will be unable to start. Perhaps we should mention in the docs that the server will still need to open a server port? > can not create redis server as the document describle > -- > > Key: GEODE-2281 > URL: https://issues.apache.org/jira/browse/GEODE-2281 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: netroby > > gfsh> start server --name=server1 --redis-bind-address=localhost > --redis-port=11211 --J=-Dgemfireredis.regiontype=PARTITION_PERSISTENT > Starting a Geode Server in > /home/huzhifeng/workspace/geode-demo/apache-geode-1.0.0-incubating/server1... > The Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in > /home/huzhifeng/workspace/geode-demo/apache-geode-1.0.0-incubating/server1 > for full details. > Exception in thread "main" java.lang.RuntimeException: An IO error occurred > while starting a Server in > /home/huzhifeng/workspace/geode-demo/apache-geode-1.0.0-incubating/server1 on > 172.17.0.1[40404]: Network is unreachable; port (40404) is not available on > localhost. > at > org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:735) > at > org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633) > at > org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184) > Caused by: java.net.BindException: Network is unreachable; port (40404) is > not available on localhost. > at > org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:127) > at > org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:688) > ... 2 more > http://geode.apache.org/docs/guide/tools_modules/redis_adapter.html > I download the latest geode binary distribute -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2510) GFSH exits with status 0 when running a command fails
Galen O'Sullivan created GEODE-2510:
---
Summary: GFSH exits with status 0 when running a command fails
Key: GEODE-2510
URL: https://issues.apache.org/jira/browse/GEODE-2510
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Galen O'Sullivan
If a command parameter is missing or the command fails, the exit status of gfsh
is 0:
{code}
$ gfsh ru
Invalid command or option : ru.
Use gfsh help to display additional information.
$ echo $?
1
$ # that's good.
$ gfsh run
Parameter "file" is required. Use "help " for assistance.
$ echo $?
0
$ # this seems wrong to me.
{code}
If a GFSH command fails, the program should return an abnormal exit status.
Otherwise it's hard to reliably script with gfsh.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GEODE-2449) Move redis adapter to extension framework
[ https://issues.apache.org/jira/browse/GEODE-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868715#comment-15868715 ] Galen O'Sullivan commented on GEODE-2449: - >From @metatype: Good news! There is a way to start services and do gfsh extensions. Take a look at the lucene module. The only bits that are in geode-core are for serialization and string messages--which we don't have a good solution for as of yet (contributions welcome!). > Move redis adapter to extension framework > - > > Key: GEODE-2449 > URL: https://issues.apache.org/jira/browse/GEODE-2449 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Addison >Assignee: Udo Kohlmeyer > Fix For: 1.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2464) Review Redis tests
[
https://issues.apache.org/jira/browse/GEODE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868511#comment-15868511
]
Galen O'Sullivan commented on GEODE-2464:
-
We'll also need some manual tests to make sure that GFSH still works,
geode-redis is getting included in the build product, etc.
> Review Redis tests
> --
>
> Key: GEODE-2464
> URL: https://issues.apache.org/jira/browse/GEODE-2464
> Project: Geode
> Issue Type: Sub-task
> Components: redis
>Reporter: Galen O'Sullivan
> Fix For: 1.2.0
>
>
> The existing Redis tests could use some cleanup and probably expansion.
> * [~ukohlmeyer] and I ([~gosullivan]) did some common test code with
> `RedisTestBase`; there is probably some room for improvement there.
> * There is a lot of repetition in the test code for the Redis adapter. We can
> improve this.
> * Randomization: use junit-quickcheck {{@Property}} tests?
> * Make sure every Redis command gets tested.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2464) Review Redis tests
Galen O'Sullivan created GEODE-2464:
---
Summary: Review Redis tests
Key: GEODE-2464
URL: https://issues.apache.org/jira/browse/GEODE-2464
Project: Geode
Issue Type: Sub-task
Components: redis
Reporter: Galen O'Sullivan
The existing Redis tests could use some cleanup and probably expansion.
* [~ukohlmeyer] and I ([~gosullivan]) did some common test code with
`RedisTestBase`; there is probably some room for improvement there.
* There is a lot of repetition in the test code for the Redis adapter. We can
improve this.
* Randomization: use junit-quickcheck {{@Property}} tests?
* Make sure every Redis command gets tested.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2463) Review Netty shutdown in GeodeRedisServiceImpl
Galen O'Sullivan created GEODE-2463:
---
Summary: Review Netty shutdown in GeodeRedisServiceImpl
Key: GEODE-2463
URL: https://issues.apache.org/jira/browse/GEODE-2463
Project: Geode
Issue Type: Sub-task
Components: redis
Reporter: Galen O'Sullivan
Do this after [GEODE-2449].
in {{GeodeRedisServiceImpl.stop()}}:
The old code used to call {{syncUninterruptibly}} on the workerGroup,
bossGroup, and serverChannel. However, the close method is likely being called
as the result of a shutdown message on the channel future, and we can't call
netty sync / await on an I/O thread. We saw deadlocks in testing. Look into
this and make sure we're shutting down right.
http://netty.io/wiki/index.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2295) LocatorCancelException ignores string passed in constructor
[ https://issues.apache.org/jira/browse/GEODE-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2295. - Resolution: Fixed Fix Version/s: 1.1.0 > LocatorCancelException ignores string passed in constructor > --- > > Key: GEODE-2295 > URL: https://issues.apache.org/jira/browse/GEODE-2295 > Project: Geode > Issue Type: Bug > Components: locator >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan >Priority: Minor > Fix For: 1.1.0 > > > The` LocatorCancelException` class has a constructor that takes a String and > fails to call `super`. This should be fixed so that the exception produces a > useful message. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
[
https://issues.apache.org/jira/browse/GEODE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2324.
-
Resolution: Fixed
Fix Version/s: 1.1.0
> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
> Fix For: 1.1.0
>
>
> In {{AcceptorImpl.close()}}, the call to
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which
> case neither {pool} nor {{hsPool}} or anything else that comes after is
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued
> (for example, through gfsh), though I haven't created a reproduction yet.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2295) LocatorCancelException ignores string passed in constructor
[ https://issues.apache.org/jira/browse/GEODE-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2295: Component/s: locator > LocatorCancelException ignores string passed in constructor > --- > > Key: GEODE-2295 > URL: https://issues.apache.org/jira/browse/GEODE-2295 > Project: Geode > Issue Type: Bug > Components: locator >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan >Priority: Minor > > The` LocatorCancelException` class has a constructor that takes a String and > fails to call `super`. This should be fixed so that the exception produces a > useful message. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2435) Redis adapter MULTI behavior is different from Redis
Galen O'Sullivan created GEODE-2435:
---
Summary: Redis adapter MULTI behavior is different from Redis
Key: GEODE-2435
URL: https://issues.apache.org/jira/browse/GEODE-2435
Project: Geode
Issue Type: Bug
Reporter: Galen O'Sullivan
{{WATCH}} isn't implemented properly, but this is about returning an error
instead of nil when we have a {{MULTI}} fail:
{code}
$ redis-cli -p 11212
127.0.0.1:11212> set a b
OK
127.0.0.1:11212> watch a
(error) ERR Keys cannot be watched or unwatched because GemFire watches all
keys by default for transactions
127.0.0.1:11212> lpush la boo
(integer) 1
(2.09s)
127.0.0.1:11212> multi
OK
127.0.0.1:11212> lpush la z
QUEUED
127.0.0.1:11212> lpush la x
QUEUED
{code}
At this point, we {{lpush la foo}} in a different client, then:
{code}
127.0.0.1:11212> exec
1) (error) ERR The server had an internal error please try again
2) (error) ERR The server had an internal error please try again
127.0.0.1:11212>
{code}
whereas a Redis instance will simply return nil instead of an error.
Looking in the logs, I see this:
{code}
[error 2017/02/06 13:21:39.493 PST server2
tid=0x2a] GeodeRedisServer-Unexpected error handler for [id: 0x3ddf9f21,
/127.0.0.1:58862 => /127.0.0.1:11212]
java.lang.UnsupportedOperationException: Operations on persist-backup regions
are not allowed because this thread has an active transaction
at
org.apache.geode.internal.cache.TXRegionState.(TXRegionState.java:60)
at
org.apache.geode.internal.cache.TXBucketRegionState.(TXBucketRegionState.java:29)
at org.apache.geode.internal.cache.TXState.writeRegion(TXState.java:252)
at
org.apache.geode.internal.cache.TXState.txWriteRegion(TXState.java:1110)
at
org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1365)
at
org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1344)
at
org.apache.geode.internal.cache.TXState.getDeserializedValue(TXState.java:1414)
at
org.apache.geode.internal.cache.TXStateProxyImpl.getDeserializedValue(TXStateProxyImpl.java:352)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1394)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.getLocally(PartitionedRegionDataStore.java:2047)
at
org.apache.geode.internal.cache.PartitionedRegion.getFromBucket(PartitionedRegion.java:4022)
at
org.apache.geode.internal.cache.PartitionedRegion.findObjectInSystem(PartitionedRegion.java:3399)
at org.apache.geode.internal.cache.TXState.findObject(TXState.java:1540)
at
org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:614)
at
org.apache.geode.internal.cache.PartitionedRegion.get(PartitionedRegion.java:3160)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1330)
at
org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:282)
at
org.apache.geode.redis.internal.executor.list.ListExecutor.pushElements(ListExecutor.java:70)
at
org.apache.geode.redis.internal.executor.list.PushExecutor.executeCommand(PushExecutor.java:47)
at
org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithTransaction(ExecutionHandlerContext.java:244)
at
org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:191)
at
org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:137)
at
io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
at
io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
at
io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
at
io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2412) Builds are failing in pipeline due to SSL locator tests failing.
[
https://issues.apache.org/jira/browse/GEODE-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2412.
-
Resolution: Workaround
Ignore the test for now.
Closing this ticket, reopened the original to find a proper fix.
> Builds are failing in pipeline due to SSL locator tests failing.
>
>
> Key: GEODE-2412
> URL: https://issues.apache.org/jira/browse/GEODE-2412
> Project: Geode
> Issue Type: Bug
> Components: locator, tests
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> https://builds.apache.org/job/Geode-nightly/734/testReport/junit/org.apache.geode.distributed/LocatorUDPSecurityDUnitTest/testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator/
> We're getting failures in both
> {LocatorUDPSecurityDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> and {LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> This looks related to [GEODE-1793].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2206) Add junit-quickcheck to Gradle test dependencies.
[
https://issues.apache.org/jira/browse/GEODE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2206.
-
Resolution: Done
> Add junit-quickcheck to Gradle test dependencies.
> -
>
> Key: GEODE-2206
> URL: https://issues.apache.org/jira/browse/GEODE-2206
> Project: Geode
> Issue Type: Improvement
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> Unit tests allow us to test cases we know about and have thought of.
> Property-based testing allows us to test those, and some cases we haven't
> thought of -- you're essentially fuzzing a limited subset of the code.
> {{junit-quickcheck}} makes it easy to write "property-based" tests with
> generators for the builtin types. You can also constrain input or build
> custom generators for constrained data.
> I think this would be especially helpful for testing areas like PDX
> serialization, which should be able to accept any serializable object a user
> creates.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GEODE-2414) Determine a mechanism to stream a zip file from server to locator
[ https://issues.apache.org/jira/browse/GEODE-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854686#comment-15854686 ] Galen O'Sullivan commented on GEODE-2414: - Sorry, I typoed the JIRA number on that commit. > Determine a mechanism to stream a zip file from server to locator > - > > Key: GEODE-2414 > URL: https://issues.apache.org/jira/browse/GEODE-2414 > Project: Geode > Issue Type: Sub-task > Components: configuration, gfsh >Reporter: Jared Stewart > > Our export command will execute a function on servers (one at a time) to > build up a zip file of the artifacts for that server. Then, the zip file > needs to be sent back to the locator, so that the locator can aggregate > together the files from all servers. However, we need to make sure to > chunk/stream the data that we send from server to locator so that neither > member will run out of memory if the file is very large. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2412) Builds are failing in pipeline due to SSL locator tests failing.
[
https://issues.apache.org/jira/browse/GEODE-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2412:
Component/s: (was: rest (dev))
> Builds are failing in pipeline due to SSL locator tests failing.
>
>
> Key: GEODE-2412
> URL: https://issues.apache.org/jira/browse/GEODE-2412
> Project: Geode
> Issue Type: Bug
> Components: locator, tests
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> https://builds.apache.org/job/Geode-nightly/734/testReport/junit/org.apache.geode.distributed/LocatorUDPSecurityDUnitTest/testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator/
> We're getting failures in both
> {LocatorUDPSecurityDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> and {LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> This looks related to [GEODE-1793].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2412) Builds are failing in pipeline due to SSL locator tests failing.
[
https://issues.apache.org/jira/browse/GEODE-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2412:
Component/s: rest (dev)
> Builds are failing in pipeline due to SSL locator tests failing.
>
>
> Key: GEODE-2412
> URL: https://issues.apache.org/jira/browse/GEODE-2412
> Project: Geode
> Issue Type: Bug
> Components: locator, tests
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> https://builds.apache.org/job/Geode-nightly/734/testReport/junit/org.apache.geode.distributed/LocatorUDPSecurityDUnitTest/testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator/
> We're getting failures in both
> {LocatorUDPSecurityDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> and {LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> This looks related to [GEODE-1793].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2412) Builds are failing in pipeline due to SSL locator tests failing.
[
https://issues.apache.org/jira/browse/GEODE-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2412:
Component/s: tests
locator
> Builds are failing in pipeline due to SSL locator tests failing.
>
>
> Key: GEODE-2412
> URL: https://issues.apache.org/jira/browse/GEODE-2412
> Project: Geode
> Issue Type: Bug
> Components: locator, tests
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> https://builds.apache.org/job/Geode-nightly/734/testReport/junit/org.apache.geode.distributed/LocatorUDPSecurityDUnitTest/testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator/
> We're getting failures in both
> {LocatorUDPSecurityDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> and {LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> This looks related to [GEODE-1793].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2412) Builds are failing in pipeline due to SSL locator tests failing.
Galen O'Sullivan created GEODE-2412:
---
Summary: Builds are failing in pipeline due to SSL locator tests
failing.
Key: GEODE-2412
URL: https://issues.apache.org/jira/browse/GEODE-2412
Project: Geode
Issue Type: Bug
Reporter: Galen O'Sullivan
https://builds.apache.org/job/Geode-nightly/734/testReport/junit/org.apache.geode.distributed/LocatorUDPSecurityDUnitTest/testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator/
We're getting failures in both
{LocatorUDPSecurityDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
and {LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
This looks related to [GEODE-1793].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-2412) Builds are failing in pipeline due to SSL locator tests failing.
[
https://issues.apache.org/jira/browse/GEODE-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan reassigned GEODE-2412:
---
Assignee: Galen O'Sullivan
> Builds are failing in pipeline due to SSL locator tests failing.
>
>
> Key: GEODE-2412
> URL: https://issues.apache.org/jira/browse/GEODE-2412
> Project: Geode
> Issue Type: Bug
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> https://builds.apache.org/job/Geode-nightly/734/testReport/junit/org.apache.geode.distributed/LocatorUDPSecurityDUnitTest/testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator/
> We're getting failures in both
> {LocatorUDPSecurityDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> and {LocatorDUnitTest.testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator}
> This looks related to [GEODE-1793].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-2206) Add junit-quickcheck to Gradle test dependencies.
[
https://issues.apache.org/jira/browse/GEODE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan reassigned GEODE-2206:
---
Assignee: Galen O'Sullivan
> Add junit-quickcheck to Gradle test dependencies.
> -
>
> Key: GEODE-2206
> URL: https://issues.apache.org/jira/browse/GEODE-2206
> Project: Geode
> Issue Type: Improvement
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> Unit tests allow us to test cases we know about and have thought of.
> Property-based testing allows us to test those, and some cases we haven't
> thought of -- you're essentially fuzzing a limited subset of the code.
> {{junit-quickcheck}} makes it easy to write "property-based" tests with
> generators for the builtin types. You can also constrain input or build
> custom generators for constrained data.
> I think this would be especially helpful for testing areas like PDX
> serialization, which should be able to accept any serializable object a user
> creates.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2381) Make enums not get so mangled by Spotless
Galen O'Sullivan created GEODE-2381:
---
Summary: Make enums not get so mangled by Spotless
Key: GEODE-2381
URL: https://issues.apache.org/jira/browse/GEODE-2381
Project: Geode
Issue Type: Bug
Reporter: Galen O'Sullivan
Perhaps the worst example is in {{CacheXMLVersion}}:
{code}
GEMFIRE_3_0(CacheXml.VERSION_3_0, CacheXml.PUBLIC_ID_3_0,
CacheXml.SYSTEM_ID_3_0, null,
null), GEMFIRE_4_0(CacheXml.VERSION_4_0, CacheXml.PUBLIC_ID_4_0,
CacheXml.SYSTEM_ID_4_0, null,
null), GEMFIRE_4_1(CacheXml.VERSION_4_1, CacheXml.PUBLIC_ID_4_1,
CacheXml.SYSTEM_ID_4_1,
null, null), GEMFIRE_5_0(CacheXml.VERSION_5_0,
CacheXml.PUBLIC_ID_5_0,
CacheXml.SYSTEM_ID_5_0, null, null),
GEMFIRE_5_1(CacheXml.VERSION_5_1,
CacheXml.PUBLIC_ID_5_1, CacheXml.SYSTEM_ID_5_1, null,
null), GEMFIRE_5_5(
CacheXml.VERSION_5_5, CacheXml.PUBLIC_ID_5_5,
CacheXml.SYSTEM_ID_5_5,
null, null), GEMFIRE_5_7(CacheXml.VERSION_5_7,
CacheXml.PUBLIC_ID_5_7,
CacheXml.SYSTEM_ID_5_7, null, null),
GEMFIRE_5_8(CacheXml.VERSION_5_8,
CacheXml.PUBLIC_ID_5_8, CacheXml.SYSTEM_ID_5_8,
null,
null), GEMFIRE_6_0(CacheXml.VERSION_6_0,
CacheXml.PUBLIC_ID_6_0,
CacheXml.SYSTEM_ID_6_0, null, null),
GEMFIRE_6_1(
CacheXml.VERSION_6_1,
CacheXml.PUBLIC_ID_6_1,
CacheXml.SYSTEM_ID_6_1, null, null),
GEMFIRE_6_5(
CacheXml.VERSION_6_5,
CacheXml.PUBLIC_ID_6_5,
CacheXml.SYSTEM_ID_6_5, null,
null), GEMFIRE_6_6(
CacheXml.VERSION_6_6,
CacheXml.PUBLIC_ID_6_6,
CacheXml.SYSTEM_ID_6_6, null,
null), GEMFIRE_7_0(
CacheXml.VERSION_7_0,
CacheXml.PUBLIC_ID_7_0,
CacheXml.SYSTEM_ID_7_0,
null,
null),
GEMFIRE_8_0(CacheXml.VERSION_8_0,
CacheXml.PUBLIC_ID_8_0,
CacheXml.SYSTEM_ID_8_0,
null,
null),
GEMFIRE_8_1(CacheXml.VERSION_8_1,
null, null,
CacheXml.SCHEMA_8_1_LOCATION,
CacheXml.GEMFIRE_NAMESPACE),
{code}
I'd love to just format these one per line. This can be done by changing a
single line in the Spotless eclipse formatter xml file (I'll put up a PR in
just a minute).
I'm not sure how attached we are to using {{eclipse-java-google-style.xml}} in
the same format as upstream (where did it come from exactly?). I also noticed
that Google has [their own tool|https://github.com/google/google-java-format]
for formatting text. Probably what we have is fine for now, and this
modification will make it better.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (GEODE-2375) GemFireException should not inherit from RuntimeException
[
https://issues.apache.org/jira/browse/GEODE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2375:
Comment: was deleted
(was: related to https://issues.apache.org/jira/browse/GEODE-2232)
> GemFireException should not inherit from RuntimeException
> -
>
> Key: GEODE-2375
> URL: https://issues.apache.org/jira/browse/GEODE-2375
> Project: Geode
> Issue Type: Bug
> Components: core, general
>Reporter: Galen O'Sullivan
>
> {{GemFireException}} inherits from {{RuntimeException}}, which means that the
> majority of exceptions in Geode are unchecked. This means that we don't have
> the type system helping us to check potential failure conditions of our code,
> and it's not clear which functions may throw exceptions as a part of their
> nomal failure modes -- for example, {{ReplyException}} has a
> {{handleAsUnexpected}} method that seems to indicate that a normal
> {{ReplyException}} is not unexpected -- but that's not what the type
> inheritance says. {{GemFireException}} accounts for most of the exceptions in
> the codebase.
> Even if we were to convert most of the existing instances of
> {{GemFireException}} to {{GemFireRuntimeException}}, developers (especially
> new ones) would still be tempted to use {{GemFireException}} for new
> exceptions.
> Perhaps the best way to solve this (if we want all our exceptions to inherit
> from a central exception type, which I'm not entirely sold on) would be to
> create a new {{GeodeUncheckedException}} and {{GeodeCheckedException}}, and
> deprecate both kinds of {{GemFireException}}? Then we could convert old
> exceptions as time permits.
> There's a significant amount of work involved here whatever way we decide to
> change it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-2375) GemFireException should not inherit from RuntimeException
[
https://issues.apache.org/jira/browse/GEODE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840976#comment-15840976
]
Galen O'Sullivan commented on GEODE-2375:
-
related to https://issues.apache.org/jira/browse/GEODE-2232
> GemFireException should not inherit from RuntimeException
> -
>
> Key: GEODE-2375
> URL: https://issues.apache.org/jira/browse/GEODE-2375
> Project: Geode
> Issue Type: Bug
> Components: core, general
>Reporter: Galen O'Sullivan
>
> {{GemFireException}} inherits from {{RuntimeException}}, which means that the
> majority of exceptions in Geode are unchecked. This means that we don't have
> the type system helping us to check potential failure conditions of our code,
> and it's not clear which functions may throw exceptions as a part of their
> nomal failure modes -- for example, {{ReplyException}} has a
> {{handleAsUnexpected}} method that seems to indicate that a normal
> {{ReplyException}} is not unexpected -- but that's not what the type
> inheritance says. {{GemFireException}} accounts for most of the exceptions in
> the codebase.
> Even if we were to convert most of the existing instances of
> {{GemFireException}} to {{GemFireRuntimeException}}, developers (especially
> new ones) would still be tempted to use {{GemFireException}} for new
> exceptions.
> Perhaps the best way to solve this (if we want all our exceptions to inherit
> from a central exception type, which I'm not entirely sold on) would be to
> create a new {{GeodeUncheckedException}} and {{GeodeCheckedException}}, and
> deprecate both kinds of {{GemFireException}}? Then we could convert old
> exceptions as time permits.
> There's a significant amount of work involved here whatever way we decide to
> change it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-2375) GemFireException should not inherit from RuntimeException
Galen O'Sullivan created GEODE-2375:
---
Summary: GemFireException should not inherit from RuntimeException
Key: GEODE-2375
URL: https://issues.apache.org/jira/browse/GEODE-2375
Project: Geode
Issue Type: Bug
Components: core, general
Reporter: Galen O'Sullivan
{{GemFireException}} inherits from {{RuntimeException}}, which means that the
majority of exceptions in Geode are unchecked. This means that we don't have
the type system helping us to check potential failure conditions of our code,
and it's not clear which functions may throw exceptions as a part of their
nomal failure modes -- for example, {{ReplyException}} has a
{{handleAsUnexpected}} method that seems to indicate that a normal
{{ReplyException}} is not unexpected -- but that's not what the type
inheritance says. {{GemFireException}} accounts for most of the exceptions in
the codebase.
Even if we were to convert most of the existing instances of
{{GemFireException}} to {{GemFireRuntimeException}}, developers (especially new
ones) would still be tempted to use {{GemFireException}} for new exceptions.
Perhaps the best way to solve this (if we want all our exceptions to inherit
from a central exception type, which I'm not entirely sold on) would be to
create a new {{GeodeUncheckedException}} and {{GeodeCheckedException}}, and
deprecate both kinds of {{GemFireException}}? Then we could convert old
exceptions as time permits.
There's a significant amount of work involved here whatever way we decide to
change it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
[ https://issues.apache.org/jira/browse/GEODE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-1793: --- Assignee: Galen O'Sullivan > Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL > --- > > Key: GEODE-1793 > URL: https://issues.apache.org/jira/browse/GEODE-1793 > Project: Geode > Issue Type: Bug > Components: locator >Reporter: Udo Kohlmeyer >Assignee: Galen O'Sullivan >Priority: Minor > > This test fails due to something not cleaning itself properly. Undetermined > what the problem is, but it will run perfectly by itself everytime, but once > run inside of the TestClass it fails -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1923) CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch
[ https://issues.apache.org/jira/browse/GEODE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-1923: Affects Version/s: 1.0.0-incubating > CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch > --- > > Key: GEODE-1923 > URL: https://issues.apache.org/jira/browse/GEODE-1923 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.0.0-incubating >Reporter: Eric Shu >Assignee: Galen O'Sullivan > Labels: ci, flaky > Fix For: 1.1.0 > > > java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at > org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.updateIntoSinglePR(FixedPRSinglehopDUnitTest.java:765) > at > org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.test_FPAmetadataFetch(FixedPRSinglehopDUnitTest.java:339) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.int
[jira] [Updated] (GEODE-1923) CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch
[ https://issues.apache.org/jira/browse/GEODE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-1923: Fix Version/s: 1.1.0 > CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch > --- > > Key: GEODE-1923 > URL: https://issues.apache.org/jira/browse/GEODE-1923 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.0.0-incubating >Reporter: Eric Shu >Assignee: Galen O'Sullivan > Labels: ci, flaky > Fix For: 1.1.0 > > > java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at > org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.updateIntoSinglePR(FixedPRSinglehopDUnitTest.java:765) > at > org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.test_FPAmetadataFetch(FixedPRSinglehopDUnitTest.java:339) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.
[jira] [Assigned] (GEODE-1923) CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch
[ https://issues.apache.org/jira/browse/GEODE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-1923: --- Assignee: Galen O'Sullivan (was: Bruce Schuchardt) > CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch > --- > > Key: GEODE-1923 > URL: https://issues.apache.org/jira/browse/GEODE-1923 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Assignee: Galen O'Sullivan > Labels: ci, flaky > > java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at > org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.updateIntoSinglePR(FixedPRSinglehopDUnitTest.java:765) > at > org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.test_FPAmetadataFetch(FixedPRSinglehopDUnitTest.java:339) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > 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.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(Refle
[jira] [Commented] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
[
https://issues.apache.org/jira/browse/GEODE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832200#comment-15832200
]
Galen O'Sullivan commented on GEODE-2324:
-
Amends the fix in GEODE-1103.
> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which
> case neither {pool} nor {{hsPool}} or anything else that comes after is
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued
> (for example, through gfsh), though I haven't created a reproduction yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
[
https://issues.apache.org/jira/browse/GEODE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2324:
Description:
In {{AcceptorImpl.close()}}, the call to
{{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which case
neither {pool} nor {{hsPool}} or anything else that comes after is properly
closed and an error message is logged.
I believe that the thread will be interrupted if a shutdown command is issued
(for example, through gfsh), though I haven't created a reproduction yet.
was:
In {{AcceptorImpl,close()}}, the call to
{{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which case
neither {pool} nor {{hsPool}} or anything else that comes after is properly
closed and an error message is logged.
I believe that the thread will be interrupted if a shutdown command is issued
(for example, through gfsh), though I haven't created a reproduction yet.
> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl.close()}}, the call to
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which
> case neither {pool} nor {{hsPool}} or anything else that comes after is
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued
> (for example, through gfsh), though I haven't created a reproduction yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
[
https://issues.apache.org/jira/browse/GEODE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2324:
Description:
In {{AcceptorImpl,close()}}, the call to
{{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which case
neither {pool} nor {{hsPool}} or anything else that comes after is properly
closed and an error message is logged.
I believe that the thread will be interrupted if a shutdown command is issued
(for example, through gfsh), though I haven't created a reproduction yet.
was:
In `AcceptorImpl,close()`, the call to
`this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, TimeUnit.MILLISECONDS))`
can throw an `InterruptedException`, in which case the pool (nor `hsPool`, or
anything else that comes after) is properly closed and an error message is
logged.
I believe that the thread will be interrupted if a shutdown command is issued
(for example, through gfsh), though I haven't created a reproduction yet.
> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>
> In {{AcceptorImpl,close()}}, the call to
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which
> case neither {pool} nor {{hsPool}} or anything else that comes after is
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued
> (for example, through gfsh), though I haven't created a reproduction yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
[
https://issues.apache.org/jira/browse/GEODE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2324:
Affects Version/s: 1.0.0-incubating
> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl,close()}}, the call to
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which
> case neither {pool} nor {{hsPool}} or anything else that comes after is
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued
> (for example, through gfsh), though I haven't created a reproduction yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
[
https://issues.apache.org/jira/browse/GEODE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan reassigned GEODE-2324:
---
Assignee: Galen O'Sullivan
> If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
> --
>
> Key: GEODE-2324
> URL: https://issues.apache.org/jira/browse/GEODE-2324
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.0.0-incubating
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> In {{AcceptorImpl,close()}}, the call to
> {{this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT,
> TimeUnit.MILLISECONDS))}} can throw an {{InterruptedException}}, in which
> case neither {pool} nor {{hsPool}} or anything else that comes after is
> properly closed and an error message is logged.
> I believe that the thread will be interrupted if a shutdown command is issued
> (for example, through gfsh), though I haven't created a reproduction yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-2324) If AcceptorImpl is interrupted during shutdown, it does not clean up properly.
Galen O'Sullivan created GEODE-2324: --- Summary: If AcceptorImpl is interrupted during shutdown, it does not clean up properly. Key: GEODE-2324 URL: https://issues.apache.org/jira/browse/GEODE-2324 Project: Geode Issue Type: Bug Components: client/server Reporter: Galen O'Sullivan In `AcceptorImpl,close()`, the call to `this.pool.awaitTermination(PoolImpl.SHUTDOWN_TIMEOUT, TimeUnit.MILLISECONDS))` can throw an `InterruptedException`, in which case the pool (nor `hsPool`, or anything else that comes after) is properly closed and an error message is logged. I believe that the thread will be interrupted if a shutdown command is issued (for example, through gfsh), though I haven't created a reproduction yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
[ https://issues.apache.org/jira/browse/GEODE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828477#comment-15828477 ] Galen O'Sullivan commented on GEODE-1793: - Of note: the Locator makes two socket connections, one to get the header, and then one to get the rest of the connection. I feel that thi > Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL > --- > > Key: GEODE-1793 > URL: https://issues.apache.org/jira/browse/GEODE-1793 > Project: Geode > Issue Type: Bug > Components: locator >Reporter: Udo Kohlmeyer >Priority: Minor > > This test fails due to something not cleaning itself properly. Undetermined > what the problem is, but it will run perfectly by itself everytime, but once > run inside of the TestClass it fails -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
[ https://issues.apache.org/jira/browse/GEODE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828477#comment-15828477 ] Galen O'Sullivan edited comment on GEODE-1793 at 1/18/17 6:02 PM: -- Of note: the Locator makes two socket connections, one to get the header, and then one to get the rest of the connection. I feel that this could be better if we didn't make so many connections, but that would break backward compatibility. was (Author: gosullivan): Of note: the Locator makes two socket connections, one to get the header, and then one to get the rest of the connection. I feel that thi > Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL > --- > > Key: GEODE-1793 > URL: https://issues.apache.org/jira/browse/GEODE-1793 > Project: Geode > Issue Type: Bug > Components: locator >Reporter: Udo Kohlmeyer >Priority: Minor > > This test fails due to something not cleaning itself properly. Undetermined > what the problem is, but it will run perfectly by itself everytime, but once > run inside of the TestClass it fails -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
[ https://issues.apache.org/jira/browse/GEODE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828472#comment-15828472 ] Galen O'Sullivan commented on GEODE-1793: - Sometimes, there is a RMIException thrown to the actual caller as a result of the connect failing, rather than it happening asynchronously. I haven't gone deep enough into the locator to find the reason for this, but a fix for the test is to catch the exception before it propagates as an RMIException. > Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL > --- > > Key: GEODE-1793 > URL: https://issues.apache.org/jira/browse/GEODE-1793 > Project: Geode > Issue Type: Bug > Components: locator >Reporter: Udo Kohlmeyer >Priority: Minor > > This test fails due to something not cleaning itself properly. Undetermined > what the problem is, but it will run perfectly by itself everytime, but once > run inside of the TestClass it fails -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2295) LocatorCancelException ignores string passed in constructor
[ https://issues.apache.org/jira/browse/GEODE-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-2295: --- Assignee: Galen O'Sullivan > LocatorCancelException ignores string passed in constructor > --- > > Key: GEODE-2295 > URL: https://issues.apache.org/jira/browse/GEODE-2295 > Project: Geode > Issue Type: Bug >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan >Priority: Minor > > The` LocatorCancelException` class has a constructor that takes a String and > fails to call `super`. This should be fixed so that the exception produces a > useful message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2295) LocatorCancelException ignores string passed in constructor
[ https://issues.apache.org/jira/browse/GEODE-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2295: Priority: Minor (was: Major) > LocatorCancelException ignores string passed in constructor > --- > > Key: GEODE-2295 > URL: https://issues.apache.org/jira/browse/GEODE-2295 > Project: Geode > Issue Type: Bug >Reporter: Galen O'Sullivan >Priority: Minor > > The` LocatorCancelException` class has a constructor that takes a String and > fails to call `super`. This should be fixed so that the exception produces a > useful message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2295) LocatorCancelException ignores string passed in constructor
Galen O'Sullivan created GEODE-2295: --- Summary: LocatorCancelException ignores string passed in constructor Key: GEODE-2295 URL: https://issues.apache.org/jira/browse/GEODE-2295 Project: Geode Issue Type: Bug Reporter: Galen O'Sullivan The` LocatorCancelException` class has a constructor that takes a String and fails to call `super`. This should be fixed so that the exception produces a useful message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2206) Add junit-quickcheck to Gradle test dependencies.
[
https://issues.apache.org/jira/browse/GEODE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2206:
Issue Type: Improvement (was: Bug)
> Add junit-quickcheck to Gradle test dependencies.
> -
>
> Key: GEODE-2206
> URL: https://issues.apache.org/jira/browse/GEODE-2206
> Project: Geode
> Issue Type: Improvement
>Reporter: Galen O'Sullivan
>Assignee: Mark Bretl
>
> Unit tests allow us to test cases we know about and have thought of.
> Property-based testing allows us to test those, and some cases we haven't
> thought of -- you're essentially fuzzing a limited subset of the code.
> {{junit-quickcheck}} makes it easy to write "property-based" tests with
> generators for the builtin types. You can also constrain input or build
> custom generators for constrained data.
> I think this would be especially helpful for testing areas like PDX
> serialization, which should be able to accept any serializable object a user
> creates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-2206) Add junit-quickcheck to Gradle test dependencies.
Galen O'Sullivan created GEODE-2206:
---
Summary: Add junit-quickcheck to Gradle test dependencies.
Key: GEODE-2206
URL: https://issues.apache.org/jira/browse/GEODE-2206
Project: Geode
Issue Type: Bug
Reporter: Galen O'Sullivan
Assignee: Mark Bretl
Unit tests allow us to test cases we know about and have thought of.
Property-based testing allows us to test those, and some cases we haven't
thought of -- you're essentially fuzzing a limited subset of the code.
{{junit-quickcheck}} makes it easy to write "property-based" tests with
generators for the builtin types. You can also constrain input or build custom
generators for constrained data.
I think this would be especially helpful for testing areas like PDX
serialization, which should be able to accept any serializable object a user
creates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2191) Add more randomized tests for PDX string serialization/deserialization.
[ https://issues.apache.org/jira/browse/GEODE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-2191: Description: There are currently a number of tests for `DataSerializer.writeString` and `DataSerializer.readString`, which cover many of the corner cases we expect for string serialization/deserialization, but it would be nice to have randomized testing that generated Unicode strings and verified that they were the same after being serialized and deserialized. was: There are currently a number of tests for InternalDataSerializer, which cover many of the corner cases we expect for string serialization/deserialization, but it would be nice to have randomized testing that generated Unicode strings and verified that they were the same after being serialized and deserialized. > Add more randomized tests for PDX string serialization/deserialization. > --- > > Key: GEODE-2191 > URL: https://issues.apache.org/jira/browse/GEODE-2191 > Project: Geode > Issue Type: Test >Reporter: Galen O'Sullivan >Assignee: Mark Bretl > > There are currently a number of tests for `DataSerializer.writeString` and > `DataSerializer.readString`, which cover many of the corner cases we expect > for string serialization/deserialization, but it would be nice to have > randomized testing that generated Unicode strings and verified that they were > the same after being serialized and deserialized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2191) Add more randomized tests for PDX string serialization/deserialization.
Galen O'Sullivan created GEODE-2191: --- Summary: Add more randomized tests for PDX string serialization/deserialization. Key: GEODE-2191 URL: https://issues.apache.org/jira/browse/GEODE-2191 Project: Geode Issue Type: Test Reporter: Galen O'Sullivan Assignee: Mark Bretl There are currently a number of tests for InternalDataSerializer, which cover many of the corner cases we expect for string serialization/deserialization, but it would be nice to have randomized testing that generated Unicode strings and verified that they were the same after being serialized and deserialized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
