[jira] [Created] (GEODE-6286) Duplicate Region name
vaquar khan created GEODE-6286:
--
Summary: Duplicate Region name
Key: GEODE-6286
URL: https://issues.apache.org/jira/browse/GEODE-6286
Project: Geode
Issue Type: Bug
Components: general
Reporter: vaquar khan
{color:#33}I am creating region account with three different way{color}
{color:#33}account{color}
{color:#33}Account{color}
{color:#33}ACCOUNT{color}
{color:#33}Instead of giving error GEODe creating there different region
.{color}
{color:#33}It will create confusion as developer I can make mistake in Java
code and calling different region in above three options.{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6278) CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex
[
https://issues.apache.org/jira/browse/GEODE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shelley Lynn Hughes-Godfrey updated GEODE-6278:
---
Affects Version/s: 1.4.0
> CI failure:
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.
> testRangeIndex
> --
>
> Key: GEODE-6278
> URL: https://issues.apache.org/jira/browse/GEODE-6278
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.4.0
>Reporter: Aditya Anchuri
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
> testRangeIndex FAILED
>
> java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
> invoked on an instance of
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
>
> at org.junit.Assert.fail(Assert.java:88)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
>
> at
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
> Seems like a flakey test.
> http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6278) CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex
[
https://issues.apache.org/jira/browse/GEODE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745290#comment-16745290
]
Shelley Lynn Hughes-Godfrey commented on GEODE-6278:
Closing as a duplicate of GEODE-925 (fixed in 1.7).
> CI failure:
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.
> testRangeIndex
> --
>
> Key: GEODE-6278
> URL: https://issues.apache.org/jira/browse/GEODE-6278
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.4.0
>Reporter: Aditya Anchuri
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
> testRangeIndex FAILED
>
> java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
> invoked on an instance of
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
>
> at org.junit.Assert.fail(Assert.java:88)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
>
> at
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
> Seems like a flakey test.
> http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6278) CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex
[
https://issues.apache.org/jira/browse/GEODE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shelley Lynn Hughes-Godfrey resolved GEODE-6278.
Resolution: Duplicate
Fix Version/s: 1.7.0
> CI failure:
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.
> testRangeIndex
> --
>
> Key: GEODE-6278
> URL: https://issues.apache.org/jira/browse/GEODE-6278
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.4.0
>Reporter: Aditya Anchuri
>Priority: Major
> Fix For: 1.7.0
>
>
> {code:java}
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
> testRangeIndex FAILED
>
> java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
> invoked on an instance of
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
>
> at org.junit.Assert.fail(Assert.java:88)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
>
> at
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
> Seems like a flakey test.
> http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4089) Lucene create index can fail due to comparison of indexedFields as an array (if order of indexes is different)
[
https://issues.apache.org/jira/browse/GEODE-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shelley Lynn Hughes-Godfrey reassigned GEODE-4089:
--
Assignee: (was: Shelley Lynn Hughes-Godfrey)
> Lucene create index can fail due to comparison of indexedFields as an array
> (if order of indexes is different)
> --
>
> Key: GEODE-4089
> URL: https://issues.apache.org/jira/browse/GEODE-4089
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Priority: Major
>
> This issue was fixed in geode 1.4 (GEODE-3953: Incorrect use of .equals() for
> comparison of fieldname arrays), but given that this issue exists in earlier
> versions, re-initialization of members creating lucene indexes can fail when
> upgrading from 1.2 and 1.3 to 1.4 when there is a mix of old and new version
> members in the Distributed System.
> {noformat}
> Cannot create Lucene index index on region /region with fields [field2,
> field1] because another member defines the same index with fields [field1,
> field2].
> 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.cache.lucene.internal.LuceneIndexCreationProfileJUnitTest.testCheckCompatibility(LuceneIndexCreationProfileJUnitTest.java:64)
> 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
> junitparams.internal.InvokeParameterisedMethod.evaluate(InvokeParameterisedMethod.java:234)
> at
> junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47)
> at
> junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40)
> at
> junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:417)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:386)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6276) Benchmark CI should fetch versions and build develop
[ https://issues.apache.org/jira/browse/GEODE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745310#comment-16745310 ] ASF subversion and git services commented on GEODE-6276: Commit e4a68d883bd8664db52aa71f490ba7a25a637953 in geode-benchmarks's branch refs/heads/develop from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=e4a68d8 ] Merge pull request #42 from balesh2/GEODE-6276 GEODE-6276: use named cli options for scripts > Benchmark CI should fetch versions and build develop > > > Key: GEODE-6276 > URL: https://issues.apache.org/jira/browse/GEODE-6276 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The benchmark ci job should build all non-release branches and fetch geode > releases. This avoids the cost of rebuilding released versions of Geode and > illiminates the challenge of the build parameters diverging between old > versions and develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6276) Benchmark CI should fetch versions and build develop
[ https://issues.apache.org/jira/browse/GEODE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745308#comment-16745308 ] ASF subversion and git services commented on GEODE-6276: Commit 8ec6dde1701e568db3fdbe7b9326935553a26207 in geode-benchmarks's branch refs/heads/develop from Helena A. Bales [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=8ec6dde ] GEODE-6276: use named cli options for scripts Name the cli options for running the benchmark. Support either a version number or a branch/commit ref. Use version to fetch previously built releases, to avoid rebuilding them every time. Signed-off-by: Jacob Barrett > Benchmark CI should fetch versions and build develop > > > Key: GEODE-6276 > URL: https://issues.apache.org/jira/browse/GEODE-6276 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The benchmark ci job should build all non-release branches and fetch geode > releases. This avoids the cost of rebuilding released versions of Geode and > illiminates the challenge of the build parameters diverging between old > versions and develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6276) Benchmark CI should fetch versions and build develop
[ https://issues.apache.org/jira/browse/GEODE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745309#comment-16745309 ] ASF subversion and git services commented on GEODE-6276: Commit e4a68d883bd8664db52aa71f490ba7a25a637953 in geode-benchmarks's branch refs/heads/develop from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=e4a68d8 ] Merge pull request #42 from balesh2/GEODE-6276 GEODE-6276: use named cli options for scripts > Benchmark CI should fetch versions and build develop > > > Key: GEODE-6276 > URL: https://issues.apache.org/jira/browse/GEODE-6276 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The benchmark ci job should build all non-release branches and fetch geode > releases. This avoids the cost of rebuilding released versions of Geode and > illiminates the challenge of the build parameters diverging between old > versions and develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6276) Benchmark CI should fetch versions and build develop
[ https://issues.apache.org/jira/browse/GEODE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745311#comment-16745311 ] ASF subversion and git services commented on GEODE-6276: Commit d4da870c3a7fc51db95f80b977b892536f0fe22a in geode's branch refs/heads/develop from Helena Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d4da870 ] GEODE-6276: Use named cli option in benchmark (#3085) The Benchmark scripts now take named cli options instead of positional ones. Use the named options in CI to call the benchmark, and pass the branch and version number through to the scripts, even though only one will be used at a time. Signed-off-by: Helena A. Bales > Benchmark CI should fetch versions and build develop > > > Key: GEODE-6276 > URL: https://issues.apache.org/jira/browse/GEODE-6276 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > The benchmark ci job should build all non-release branches and fetch geode > releases. This avoids the cost of rebuilding released versions of Geode and > illiminates the challenge of the build parameters diverging between old > versions and develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4728) Geode Native Documentation Improvements
[ https://issues.apache.org/jira/browse/GEODE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745319#comment-16745319 ] ASF subversion and git services commented on GEODE-4728: Commit ce3bedb9963706a46c75064aa931879af29fc754 in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=ce3bedb ] GEODE-4728: Update README.md instructions for building the user guide. > Geode Native Documentation Improvements > --- > > Key: GEODE-4728 > URL: https://issues.apache.org/jira/browse/GEODE-4728 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 6h 10m > Remaining Estimate: 0h > > This ticket will capture a series of changes to the Geode Native docs to > bring them inline with the updated API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6283) The v2 REST conrtoller have a LocatorClusterManagementService instance injected and created
[
https://issues.apache.org/jira/browse/GEODE-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6283:
--
Labels: pull-request-available (was: )
> The v2 REST conrtoller have a LocatorClusterManagementService instance
> injected and created
> ---
>
> Key: GEODE-6283
> URL: https://issues.apache.org/jira/browse/GEODE-6283
> Project: Geode
> Issue Type: Sub-task
> Components: configuration
>Reporter: Kenneth Howe
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
>
> As originally implemented, the controller is a noop. Inject a
> {ClusterManagementService}} into the controller and call it's {{create}}
> method.
> The result of this implementation should be:
> When: {{curl :7070/geode-management/v2}} with a cache element
> with region name and type
>
> Then: {{gfsh list regions}} should show that the region was created in the
> cluster
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6269) Extract statistics factories from InternalDistributedSystem
[
https://issues.apache.org/jira/browse/GEODE-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745327#comment-16745327
]
ASF subversion and git services commented on GEODE-6269:
Commit 9d75ff72951231c476b241a0593fed3ee28637cd in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9d75ff7 ]
GEODE-6269: Extract StatisticsRegistry from IDS (#3068)
Extract StatisticsRegistry from InternalDistributedSystem.
Exclude StatisticsRegistry from entry sizing in ReflectionBasedAutoSerializer.
> Extract statistics factories from InternalDistributedSystem
> ---
>
> Key: GEODE-6269
> URL: https://issues.apache.org/jira/browse/GEODE-6269
> Project: Geode
> Issue Type: Improvement
> Components: statistics
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Extract the implementation of {{StatisticsFactory}} and
> {{StatisticsTypeFactory}}
> from {{InternalDistributedSystem}}, to leave {{InternalDistributedSystem}}
> more focused on its primary purpose of connecting to a distributed system.
> Also add unit tests for the newly extracted implementations, to support
> future enhancements to Geode's ability to publish system statistics.
> Because {{InternalDistributedSystem}} inherits these interfaces via a public
> interface ({{DistributedSystem}}), we cannot remove the methods from
> {{InternalDistributedSystem}}. So {{InternalDistributedSystem}} will delegate
> statistics factory functionality to the newly extracted classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6282) CI Failure: WindowsGfshDistributedTestOpenJDK11.connectWithSSL
[
https://issues.apache.org/jira/browse/GEODE-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Jewell resolved GEODE-6282.
-
Resolution: Won't Fix
We are seeing bind exceptions from all tests on windows - may be due to issues
with the AvailablePortHelper seen in GEODE-6268. Closing this in favor of that
issue.
> CI Failure: WindowsGfshDistributedTestOpenJDK11.connectWithSSL
> --
>
> Key: GEODE-6282
> URL: https://issues.apache.org/jira/browse/GEODE-6282
> Project: Geode
> Issue Type: Bug
>Reporter: Ryan McMahon
>Priority: Major
>
>
> {code:java}
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithSSL FAILED
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1233
> [error 2019/01/15 20:17:38.966 GMT tid=63]
> Jmx manager could not be started because HTTP service failed to start
> org.apache.geode.management.ManagementException: HTTP service failed to start
> at
> org.apache.geode.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:349)
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:159)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:115)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2234)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1214)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:799)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:785)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:176)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:223)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:657)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:644)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:330)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:252)
> at org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:139)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:85)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:66)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$22d9b8a8$1(ClusterStartupRule.java:208)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:69)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0
[jira] [Commented] (GEODE-5370) DistributedTest task on CI occasionally exceeds timeout
[ https://issues.apache.org/jira/browse/GEODE-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745343#comment-16745343 ] Owen Nichols commented on GEODE-5370: - This usually means a test hung. If possible, check the logs to identify which test and where it hung. This is especially difficult right now since the capture-call-stacks.sh script is not working (I could only find GEODE-4616, maybe we don't have a ticket open for the current problem?) > DistributedTest task on CI occasionally exceeds timeout > --- > > Key: GEODE-5370 > URL: https://issues.apache.org/jira/browse/GEODE-5370 > Project: Geode > Issue Type: Bug >Reporter: Alexander Murmann >Assignee: Jinmei Liao >Priority: Major > Labels: ci, concourse, flaky, swat > > Occasionally the CI job fails because it exceeds the 8 hour timeout. The job > usually takes ~3 hours, so this is definitely outside the expected variation. > See the following runs: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/88] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/79] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/77] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/71] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6287) When a client connects, registers interest and disconnects normally, its ClientProxyMembershipID is not cleaned up and a memory leak occurs
[
https://issues.apache.org/jira/browse/GEODE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby reassigned GEODE-6287:
Assignee: Barry Oglesby
> When a client connects, registers interest and disconnects normally, its
> ClientProxyMembershipID is not cleaned up and a memory leak occurs
> ---
>
> Key: GEODE-6287
> URL: https://issues.apache.org/jira/browse/GEODE-6287
> Project: Geode
> Issue Type: Bug
> Components: client queues, client/server
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client connects to a distributed system and registers interest, the
> Region's FilterProfile's clientMap (an IDMap) registers the
> ClientProxyMembershipID in both the realIDs and wireIDs like:
> ```
> realIDs=\{identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
> wireIDs=\{1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
> ```
> When the client leaves normally, the UnregisterInterest command is invoked
> which removes the interest and the region. Part of that behavior is to remove
> the regionName from the set of regions.
> ```
> this.regions.remove(regionName)
> ```
> Then ClientInterestList.clearClientInterestList is then invoked which is
> supposed to clear the FilterProfile for each region, but the regions are
> already cleared by the UnregisterInterest command, so this method doesn't do
> anything.
> Then, LocalRegion.cleanupForClient is invoked which invokes
> FilterProfile.cleanupForClient. This method currently only closes CQs (which
> also cleans up the cqMap which is also an IDMap like the clientMap).
> At the end of this, the clientMap's realIDs and wireIDs still contain the
> ClientProxyMembershipID.
> The cleanupForClient method could be changed to also clean up the clientMap.
> Note: If the client is killed abnormally, the UnregisterInterest command is
> not invoked, so the interest and the region is not cleaned up normally. When
> ClientInterestList.clearClientInterestList is called, the set of regions
> still contains the region, and the IDMap is cleaned up properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6287) When a client connects, registers interest and disconnects normally, its ClientProxyMembershipID is not cleaned up and a memory leak occurs
Barry Oglesby created GEODE-6287:
Summary: When a client connects, registers interest and
disconnects normally, its ClientProxyMembershipID is not cleaned up and a
memory leak occurs
Key: GEODE-6287
URL: https://issues.apache.org/jira/browse/GEODE-6287
Project: Geode
Issue Type: Bug
Components: client queues, client/server
Reporter: Barry Oglesby
When a client connects to a distributed system and registers interest, the
Region's FilterProfile's clientMap (an IDMap) registers the
ClientProxyMembershipID in both the realIDs and wireIDs like:
```
realIDs=\{identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
wireIDs=\{1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
```
When the client leaves normally, the UnregisterInterest command is invoked
which removes the interest and the region. Part of that behavior is to remove
the regionName from the set of regions.
```
this.regions.remove(regionName)
```
Then ClientInterestList.clearClientInterestList is then invoked which is
supposed to clear the FilterProfile for each region, but the regions are
already cleared by the UnregisterInterest command, so this method doesn't do
anything.
Then, LocalRegion.cleanupForClient is invoked which invokes
FilterProfile.cleanupForClient. This method currently only closes CQs (which
also cleans up the cqMap which is also an IDMap like the clientMap).
At the end of this, the clientMap's realIDs and wireIDs still contain the
ClientProxyMembershipID.
The cleanupForClient method could be changed to also clean up the clientMap.
Note: If the client is killed abnormally, the UnregisterInterest command is not
invoked, so the interest and the region is not cleaned up normally. When
ClientInterestList.clearClientInterestList is called, the set of regions still
contains the region, and the IDMap is cleaned up properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6287) When a client connects, registers interest and disconnects normally, its ClientProxyMembershipID is not cleaned up and a memory leak occurs
[
https://issues.apache.org/jira/browse/GEODE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby updated GEODE-6287:
-
Description:
When a client connects to a distributed system and registers interest, the
Region's FilterProfile's clientMap (an IDMap) registers the
ClientProxyMembershipID in both the realIDs and wireIDs like:
{noformat}
realIDs={identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
wireIDs={1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
{noformat}
When the client leaves normally, the UnregisterInterest command is invoked
which removes the interest and the region. Part of that behavior is to remove
the regionName from the set of regions.
{noformat}
this.regions.remove(regionName)
{noformat}
Then ClientInterestList.clearClientInterestList is then invoked which is
supposed to clear the FilterProfile for each region, but the regions are
already cleared by the UnregisterInterest command, so this method doesn't do
anything.
Then, LocalRegion.cleanupForClient is invoked which invokes
FilterProfile.cleanupForClient. This method currently only closes CQs (which
also cleans up the cqMap which is also an IDMap like the clientMap).
At the end of this, the clientMap's realIDs and wireIDs still contain the
ClientProxyMembershipID.
The cleanupForClient method could be changed to also clean up the clientMap.
Note: If the client is killed abnormally, the UnregisterInterest command is not
invoked, so the interest and the region is not cleaned up normally. When
ClientInterestList.clearClientInterestList is called, the set of regions still
contains the region, and the IDMap is cleaned up properly.
was:
When a client connects to a distributed system and registers interest, the
Region's FilterProfile's clientMap (an IDMap) registers the
ClientProxyMembershipID in both the realIDs and wireIDs like:
{noformat}
realIDs=\{identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
wireIDs=\{1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
{noformat}
When the client leaves normally, the UnregisterInterest command is invoked
which removes the interest and the region. Part of that behavior is to remove
the regionName from the set of regions.
{noformat}
this.regions.remove(regionName)
{noformat}
Then ClientInterestList.clearClientInterestList is then invoked which is
supposed to clear the FilterProfile for each region, but the regions are
already cleared by the UnregisterInterest command, so this method doesn't do
anything.
Then, LocalRegion.cleanupForClient is invoked which invokes
FilterProfile.cleanupForClient. This method currently only closes CQs (which
also cleans up the cqMap which is also an IDMap like the clientMap).
At the end of this, the clientMap's realIDs and wireIDs still contain the
ClientProxyMembershipID.
The cleanupForClient method could be changed to also clean up the clientMap.
Note: If the client is killed abnormally, the UnregisterInterest command is not
invoked, so the interest and the region is not cleaned up normally. When
ClientInterestList.clearClientInterestList is called, the set of regions still
contains the region, and the IDMap is cleaned up properly.
> When a client connects, registers interest and disconnects normally, its
> ClientProxyMembershipID is not cleaned up and a memory leak occurs
> ---
>
> Key: GEODE-6287
> URL: https://issues.apache.org/jira/browse/GEODE-6287
> Project: Geode
> Issue Type: Bug
> Components: client queues, client/server
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client connects to a distributed system and registers interest, the
> Region's FilterProfile's clientMap (an IDMap) registers the
> ClientProxyMembershipID in both the realIDs and wireIDs like:
> {noformat}
> realIDs={identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
> wireIDs={1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
> {noformat}
> When the client leaves normally, the UnregisterInterest command is invoked
> which removes the interest and the region. Part of that behavior is to remove
> the regionName from the set of regions.
> {noformat}
> this.regions.remove(regionName)
> {noformat}
> Then ClientInterestList.clearClientInterestList is then invoked which is
> supposed to clear the FilterProfile for each region, but the regions are
> already cleared by the UnregisterInterest command, so this method doesn't do
> anything.
>
[jira] [Commented] (GEODE-6287) When a client connects, registers interest and disconnects normally, its ClientProxyMembershipID is not cleaned up and a memory leak occurs
[
https://issues.apache.org/jira/browse/GEODE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745349#comment-16745349
]
Barry Oglesby commented on GEODE-6287:
--
When a client connects to a distributed system and registers interest, the
Region's FilterProfile's clientMap (an IDMap) registers the
ClientProxyMembershipID in both the realIDs and wireIDs like:
{noformat}
realIDs=\{identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
wireIDs=\{1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
{noformat}
When the client leaves normally, the UnregisterInterest command is invoked
which removes the interest and the region. Part of that behavior is to remove
the regionName from the set of regions.
{noformat}
this.regions.remove(regionName)
{noformat}
Then ClientInterestList.clearClientInterestList is then invoked which is
supposed to clear the FilterProfile for each region, but the regions are
already cleared by the UnregisterInterest command, so this method doesn't do
anything.
Then, LocalRegion.cleanupForClient is invoked which invokes
FilterProfile.cleanupForClient. This method currently only closes CQs (which
also cleans up the cqMap which is also an IDMap like the clientMap).
At the end of this, the clientMap's realIDs and wireIDs still contain the
ClientProxyMembershipID.
The cleanupForClient method could be changed to also clean up the clientMap.
Note: If the client is killed abnormally, the UnregisterInterest command is not
invoked, so the interest and the region is not cleaned up normally. When
ClientInterestList.clearClientInterestList is called, the set of regions still
contains the region, and the IDMap is cleaned up properly.
Here is a stack trace showing the ClientProxyMembershipID being registered:
{noformat}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1333)
at
org.apache.geode.internal.cache.FilterProfile$IDMap.getWireID(FilterProfile.java:2032)
at
org.apache.geode.internal.cache.FilterProfile.getClientIDForMaps(FilterProfile.java:1615)
at
org.apache.geode.internal.cache.FilterProfile.registerClientInterest(FilterProfile.java:261)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy$ClientInterestList.registerClientInterest(CacheClientProxy.java:2052)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.registerClientInterest(CacheClientProxy.java:1270)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.registerClientInterest(CacheClientNotifier.java:1194)
at
org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.cmdExecute(RegisterInterest61.java:200)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:178)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:844)
at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:74)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1218)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:613)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Here is a stack trace showing the UnregisterInterest command unregistering the
client interest:
{noformat}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1333)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy$ClientInterestList.unregisterClientInterest(CacheClientProxy.java:2085)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.unregisterClientInterest(CacheClientProxy.java:1330)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.unregisterClientInterest(CacheClientNotifier.java:1245)
at
org.apache.geode.internal.cache.tier.sockets.command.UnregisterInterest.cmdExecute(UnregisterInterest.java:144)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:178)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:844)
at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:75)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1215)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org
[jira] [Updated] (GEODE-6287) When a client connects, registers interest and disconnects normally, its ClientProxyMembershipID is not cleaned up and a memory leak occurs
[
https://issues.apache.org/jira/browse/GEODE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby updated GEODE-6287:
-
Description:
When a client connects to a distributed system and registers interest, the
Region's FilterProfile's clientMap (an IDMap) registers the
ClientProxyMembershipID in both the realIDs and wireIDs like:
{noformat}
realIDs=\{identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
wireIDs=\{1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
{noformat}
When the client leaves normally, the UnregisterInterest command is invoked
which removes the interest and the region. Part of that behavior is to remove
the regionName from the set of regions.
{noformat}
this.regions.remove(regionName)
{noformat}
Then ClientInterestList.clearClientInterestList is then invoked which is
supposed to clear the FilterProfile for each region, but the regions are
already cleared by the UnregisterInterest command, so this method doesn't do
anything.
Then, LocalRegion.cleanupForClient is invoked which invokes
FilterProfile.cleanupForClient. This method currently only closes CQs (which
also cleans up the cqMap which is also an IDMap like the clientMap).
At the end of this, the clientMap's realIDs and wireIDs still contain the
ClientProxyMembershipID.
The cleanupForClient method could be changed to also clean up the clientMap.
Note: If the client is killed abnormally, the UnregisterInterest command is not
invoked, so the interest and the region is not cleaned up normally. When
ClientInterestList.clearClientInterestList is called, the set of regions still
contains the region, and the IDMap is cleaned up properly.
was:
When a client connects to a distributed system and registers interest, the
Region's FilterProfile's clientMap (an IDMap) registers the
ClientProxyMembershipID in both the realIDs and wireIDs like:
```
realIDs=\{identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
wireIDs=\{1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
```
When the client leaves normally, the UnregisterInterest command is invoked
which removes the interest and the region. Part of that behavior is to remove
the regionName from the set of regions.
```
this.regions.remove(regionName)
```
Then ClientInterestList.clearClientInterestList is then invoked which is
supposed to clear the FilterProfile for each region, but the regions are
already cleared by the UnregisterInterest command, so this method doesn't do
anything.
Then, LocalRegion.cleanupForClient is invoked which invokes
FilterProfile.cleanupForClient. This method currently only closes CQs (which
also cleans up the cqMap which is also an IDMap like the clientMap).
At the end of this, the clientMap's realIDs and wireIDs still contain the
ClientProxyMembershipID.
The cleanupForClient method could be changed to also clean up the clientMap.
Note: If the client is killed abnormally, the UnregisterInterest command is not
invoked, so the interest and the region is not cleaned up normally. When
ClientInterestList.clearClientInterestList is called, the set of regions still
contains the region, and the IDMap is cleaned up properly.
> When a client connects, registers interest and disconnects normally, its
> ClientProxyMembershipID is not cleaned up and a memory leak occurs
> ---
>
> Key: GEODE-6287
> URL: https://issues.apache.org/jira/browse/GEODE-6287
> Project: Geode
> Issue Type: Bug
> Components: client queues, client/server
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client connects to a distributed system and registers interest, the
> Region's FilterProfile's clientMap (an IDMap) registers the
> ClientProxyMembershipID in both the realIDs and wireIDs like:
> {noformat}
> realIDs=\{identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
> wireIDs=\{1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
> {noformat}
> When the client leaves normally, the UnregisterInterest command is invoked
> which removes the interest and the region. Part of that behavior is to remove
> the regionName from the set of regions.
> {noformat}
> this.regions.remove(regionName)
> {noformat}
> Then ClientInterestList.clearClientInterestList is then invoked which is
> supposed to clear the FilterProfile for each region, but the regions are
> already cleared by the UnregisterInterest command, so this method doesn't do
> anything.
> Then, LocalRegion.clean
[jira] [Updated] (GEODE-6147) Fail benchmark junit tests if their numbers deviate too far from a baseline
[ https://issues.apache.org/jira/browse/GEODE-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6147: -- Labels: pull-request-available (was: ) > Fail benchmark junit tests if their numbers deviate too far from a baseline > --- > > Key: GEODE-6147 > URL: https://issues.apache.org/jira/browse/GEODE-6147 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > > We want to fail tests if performance gets worse. We also want a signal to > create a new baseline if performance gets better, so perhaps we should fail > tests in that case as well. > One way to do this would be to add a new system property to the > TestRunners.defaultRunner() that takes in a baseline directory. The test > itself could compare it's results with the baseline after running and fail if > it deviates too far from the baseline. > Using that, we could a new flag to the benchmark task to pass in that > baseline and cause tests that deviate to fail. > Eg > ./gradlew benchmark -Pbaseline=/some/dir > Acceptance: > run_against_baseline.sh generates a failure report if benchmarks deviate too > far from the baseline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6287) When a client connects, registers interest and disconnects normally, its ClientProxyMembershipID is not cleaned up and a memory leak occurs
[
https://issues.apache.org/jira/browse/GEODE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745352#comment-16745352
]
Barry Oglesby commented on GEODE-6287:
--
Startup:
{noformat}
num #instances #bytes class name
--
1: 28887 2606096 [C
2: 7205 810664 java.lang.Class
3: 28820 691680 java.lang.String
4: 2004 494408 [B
5: 5153 453464 java.lang.reflect.Method
6: 5538 425016 [Ljava.lang.Object;
7: 657 389224 [J
8: 11600 371200 java.util.concurrent.ConcurrentHashMap$Node
9: 8124 324960 java.util.LinkedHashMap$Entry
10: 3047 277584 [Ljava.util.HashMap$Node;
11: 8536 273152 java.util.HashMap$Node
12: 2533 202640 java.lang.reflect.Constructor
13: 4764 198616 [I
14: 10575 169200 java.lang.Object
15: 2749 153944 java.util.LinkedHashMap
Total 181128 9653224
{noformat}
With 15000 client connects/registerInterests/disconnects:
{noformat}
num #instances #bytes class name
--
1: 104958 9068952 [C
2: 104852 2516448 java.lang.String
3: 16604 2160248 [B
4: 41802 1337664 java.util.concurrent.ConcurrentHashMap$Node
5: 15005 1080360 org.apache.geode.distributed.internal.membership.gms.GMSMember
6: 7473 840680 java.lang.Class
7: 15005 720240
org.apache.geode.distributed.internal.membership.InternalDistributedMember
8: 15031 480992 java.net.InetAddress$InetAddressHolder
9: 14996 479872 org.apache.geode.distributed.DurableClientAttributes
10: 14995 479840
org.apache.geode.internal.cache.tier.sockets.ClientProxyMembershipID
11: 5949 445136 [Ljava.lang.Object;
12: 25820 413120 java.lang.Object
13: 756 407840 [J
14: 15225 365400 java.lang.Long
15: 15026 360624 java.net.Inet4Address
Total 501811 24712960
{noformat}
> When a client connects, registers interest and disconnects normally, its
> ClientProxyMembershipID is not cleaned up and a memory leak occurs
> ---
>
> Key: GEODE-6287
> URL: https://issues.apache.org/jira/browse/GEODE-6287
> Project: Geode
> Issue Type: Bug
> Components: client queues, client/server
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client connects to a distributed system and registers interest, the
> Region's FilterProfile's clientMap (an IDMap) registers the
> ClientProxyMembershipID in both the realIDs and wireIDs like:
> {noformat}
> realIDs={identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
> wireIDs={1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
> {noformat}
> When the client leaves normally, the UnregisterInterest command is invoked
> which removes the interest and the region. Part of that behavior is to remove
> the regionName from the set of regions.
> {noformat}
> this.regions.remove(regionName)
> {noformat}
> Then ClientInterestList.clearClientInterestList is then invoked which is
> supposed to clear the FilterProfile for each region, but the regions are
> already cleared by the UnregisterInterest command, so this method doesn't do
> anything.
> Then, LocalRegion.cleanupForClient is invoked which invokes
> FilterProfile.cleanupForClient. This method currently only closes CQs (which
> also cleans up the cqMap which is also an IDMap like the clientMap).
> At the end of this, the clientMap's realIDs and wireIDs still contain the
> ClientProxyMembershipID.
> The cleanupForClient method could be changed to also clean up the clientMap.
> Note: If the client is killed abnormally, the UnregisterInterest command is
> not invoked, so the interest and the region is not cleaned up normally. When
> ClientInterestList.clearClientInterestList is called, the set of regions
> still contains the region, and the IDMap is cleaned up properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6287) When a client connects, registers interest and disconnects normally, its ClientProxyMembershipID is not cleaned up and a memory leak occurs
[
https://issues.apache.org/jira/browse/GEODE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745357#comment-16745357
]
Barry Oglesby commented on GEODE-6287:
--
I made a change to FilterProfile.cleanupForClient to also clean up the
clientMap. That addressed the leak.
Now with 15000 client connects/registerInterests/disconnects:
{noformat}
num #instances #bytes class name
--
1: 29928 2706856 [C
2: 7472 840576 java.lang.Class
3: 29822 715728 java.lang.String
4: 1607 478240 [B
5: 5946 445008 [Ljava.lang.Object;
6: 773 410136 [J
7: 11820 378240 java.util.concurrent.ConcurrentHashMap$Node
8: 2980 262240 java.lang.reflect.Method
9: 7953 254496 java.util.HashMap$Node
10: 4911 208984 [I
11: 2138 198408 [Ljava.util.HashMap$Node;
12: 10827 173232 java.lang.Object
13: 2119 169520 java.lang.reflect.Constructor
14: 4120 164800 java.util.LinkedHashMap$Entry
15: 1726 96656 java.util.LinkedHashMap
Total 175924 9348120
{noformat}
> When a client connects, registers interest and disconnects normally, its
> ClientProxyMembershipID is not cleaned up and a memory leak occurs
> ---
>
> Key: GEODE-6287
> URL: https://issues.apache.org/jira/browse/GEODE-6287
> Project: Geode
> Issue Type: Bug
> Components: client queues, client/server
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client connects to a distributed system and registers interest, the
> Region's FilterProfile's clientMap (an IDMap) registers the
> ClientProxyMembershipID in both the realIDs and wireIDs like:
> {noformat}
> realIDs={identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
> wireIDs={1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
> {noformat}
> When the client leaves normally, the UnregisterInterest command is invoked
> which removes the interest and the region. Part of that behavior is to remove
> the regionName from the set of regions.
> {noformat}
> this.regions.remove(regionName)
> {noformat}
> Then ClientInterestList.clearClientInterestList is then invoked which is
> supposed to clear the FilterProfile for each region, but the regions are
> already cleared by the UnregisterInterest command, so this method doesn't do
> anything.
> Then, LocalRegion.cleanupForClient is invoked which invokes
> FilterProfile.cleanupForClient. This method currently only closes CQs (which
> also cleans up the cqMap which is also an IDMap like the clientMap).
> At the end of this, the clientMap's realIDs and wireIDs still contain the
> ClientProxyMembershipID.
> The cleanupForClient method could be changed to also clean up the clientMap.
> Note: If the client is killed abnormally, the UnregisterInterest command is
> not invoked, so the interest and the region is not cleaned up normally. When
> ClientInterestList.clearClientInterestList is called, the set of regions
> still contains the region, and the IDMap is cleaned up properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6147) Fail benchmark junit tests if their numbers deviate too far from a baseline
[ https://issues.apache.org/jira/browse/GEODE-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745370#comment-16745370 ] ASF subversion and git services commented on GEODE-6147: Commit d98d389fa775e09e5f68b9dc9a13acdea5b130fa in geode-benchmarks's branch refs/heads/develop from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=d98d389 ] GEODE-6147 - Fail benchmark task if average latency change is 5+% (#43) * GEODE-6147 - Fail benchmark task if average latency change is 5+% * Change ratio to difference * Add difference calculation to ProbeResult * Fail analyzeRun task if average latency difference is >= 5% Authored-by: Sean Goller > Fail benchmark junit tests if their numbers deviate too far from a baseline > --- > > Key: GEODE-6147 > URL: https://issues.apache.org/jira/browse/GEODE-6147 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > We want to fail tests if performance gets worse. We also want a signal to > create a new baseline if performance gets better, so perhaps we should fail > tests in that case as well. > One way to do this would be to add a new system property to the > TestRunners.defaultRunner() that takes in a baseline directory. The test > itself could compare it's results with the baseline after running and fail if > it deviates too far from the baseline. > Using that, we could a new flag to the benchmark task to pass in that > baseline and cause tests that deviate to fail. > Eg > ./gradlew benchmark -Pbaseline=/some/dir > Acceptance: > run_against_baseline.sh generates a failure report if benchmarks deviate too > far from the baseline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6288) PdxInstance.isDeserializable returns false for a JSON pdx instance
Darrel Schneider created GEODE-6288: --- Summary: PdxInstance.isDeserializable returns false for a JSON pdx instance Key: GEODE-6288 URL: https://issues.apache.org/jira/browse/GEODE-6288 Project: Geode Issue Type: Bug Components: serialization Reporter: Darrel Schneider PdxInstance.isDeserializable should only return false if the PdxInstance does not change form. For example PdxInstance.getObject should always return the same PdxInstance it is called on. But in the case of PdxInstances created for JSON, getObject returns the JSON form instead of the PdxInstance. So for JSON PdxInstances, isDeserializable should return true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6288) PdxInstance.isDeserializable returns false for a JSON pdx instance
[ https://issues.apache.org/jira/browse/GEODE-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-6288: --- Assignee: Darrel Schneider > PdxInstance.isDeserializable returns false for a JSON pdx instance > -- > > Key: GEODE-6288 > URL: https://issues.apache.org/jira/browse/GEODE-6288 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > PdxInstance.isDeserializable should only return false if the PdxInstance does > not change form. For example PdxInstance.getObject should always return the > same PdxInstance it is called on. > But in the case of PdxInstances created for JSON, getObject returns the JSON > form instead of the PdxInstance. So for JSON PdxInstances, isDeserializable > should return true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6288) PdxInstance.isDeserializable returns false for a JSON pdx instance
[ https://issues.apache.org/jira/browse/GEODE-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-6288: Affects Version/s: 1.9.0 > PdxInstance.isDeserializable returns false for a JSON pdx instance > -- > > Key: GEODE-6288 > URL: https://issues.apache.org/jira/browse/GEODE-6288 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.9.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > PdxInstance.isDeserializable should only return false if the PdxInstance does > not change form. For example PdxInstance.getObject should always return the > same PdxInstance it is called on. > But in the case of PdxInstances created for JSON, getObject returns the JSON > form instead of the PdxInstance. So for JSON PdxInstances, isDeserializable > should return true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6147) Fail benchmark junit tests if their numbers deviate too far from a baseline
[ https://issues.apache.org/jira/browse/GEODE-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745371#comment-16745371 ] ASF subversion and git services commented on GEODE-6147: Commit d98d389fa775e09e5f68b9dc9a13acdea5b130fa in geode-benchmarks's branch refs/heads/develop from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=d98d389 ] GEODE-6147 - Fail benchmark task if average latency change is 5+% (#43) * GEODE-6147 - Fail benchmark task if average latency change is 5+% * Change ratio to difference * Add difference calculation to ProbeResult * Fail analyzeRun task if average latency difference is >= 5% Authored-by: Sean Goller > Fail benchmark junit tests if their numbers deviate too far from a baseline > --- > > Key: GEODE-6147 > URL: https://issues.apache.org/jira/browse/GEODE-6147 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > We want to fail tests if performance gets worse. We also want a signal to > create a new baseline if performance gets better, so perhaps we should fail > tests in that case as well. > One way to do this would be to add a new system property to the > TestRunners.defaultRunner() that takes in a baseline directory. The test > itself could compare it's results with the baseline after running and fail if > it deviates too far from the baseline. > Using that, we could a new flag to the benchmark task to pass in that > baseline and cause tests that deviate to fail. > Eg > ./gradlew benchmark -Pbaseline=/some/dir > Acceptance: > run_against_baseline.sh generates a failure report if benchmarks deviate too > far from the baseline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5370) DistributedTest task on CI occasionally exceeds timeout
[ https://issues.apache.org/jira/browse/GEODE-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-5370. -- Resolution: Won't Fix As Owen pointed out, if the CI times out, it's probably because a test hangs. If you see a timeout in the future, please investigate the underlying hang rather than putting into this catch all bucket. > DistributedTest task on CI occasionally exceeds timeout > --- > > Key: GEODE-5370 > URL: https://issues.apache.org/jira/browse/GEODE-5370 > Project: Geode > Issue Type: Bug >Reporter: Alexander Murmann >Assignee: Jinmei Liao >Priority: Major > Labels: ci, concourse, flaky, swat > > Occasionally the CI job fails because it exceeds the 8 hour timeout. The job > usually takes ~3 hours, so this is definitely outside the expected variation. > See the following runs: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/88] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/79] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/77] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/71] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6286) Duplicate Region name
[
https://issues.apache.org/jira/browse/GEODE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
vaquar khan updated GEODE-6286:
---
Priority: Minor (was: Major)
> Duplicate Region name
> --
>
> Key: GEODE-6286
> URL: https://issues.apache.org/jira/browse/GEODE-6286
> Project: Geode
> Issue Type: Bug
> Components: general
>Reporter: vaquar khan
>Priority: Minor
>
> {color:#33}I am creating region account with three different way{color}
> {color:#33}account{color}
> {color:#33}Account{color}
> {color:#33}ACCOUNT{color}
> {color:#33}Instead of giving error GEODe creating there different region
> .{color}
>
> {color:#33}It will create confusion as developer I can make mistake in
> Java code and calling different region in above three options.{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6284) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false]
[
https://issues.apache.org/jira/browse/GEODE-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-6284:
-
Description:
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
34bae3263b09 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537)
at org.apache.geode.test.dunit.VM.invoke(VM.java:352)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:57)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:496)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:484)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
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.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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:118)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Me
[jira] [Commented] (GEODE-6288) PdxInstance.isDeserializable returns false for a JSON pdx instance
[ https://issues.apache.org/jira/browse/GEODE-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745403#comment-16745403 ] ASF subversion and git services commented on GEODE-6288: Commit b79e275c8f6fb9d61e76bd67e53137d215f3ba79 in geode's branch refs/heads/feature/GEODE-6288 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b79e275 ] GEODE-6288: change isDeserializable to return true on JSON pdx > PdxInstance.isDeserializable returns false for a JSON pdx instance > -- > > Key: GEODE-6288 > URL: https://issues.apache.org/jira/browse/GEODE-6288 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.9.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > PdxInstance.isDeserializable should only return false if the PdxInstance does > not change form. For example PdxInstance.getObject should always return the > same PdxInstance it is called on. > But in the case of PdxInstances created for JSON, getObject returns the JSON > form instead of the PdxInstance. So for JSON PdxInstances, isDeserializable > should return true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6284) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false]
[
https://issues.apache.org/jira/browse/GEODE-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745407#comment-16745407
]
Dan Smith commented on GEODE-6284:
--
The RMI exception means it couldn't talk to one of the dunit processes. In the
logs, we see this error, which I think indicates the process crashed!
{noformat}
[vm1] #
[vm1] # A fatal error has been detected by the Java Runtime Environment:
[vm1] #
[vm1] # SIGSEGV (0xb) at pc=0x7f99fca8f63f, pid=5176, tid=5421[thread 5418
also had an error]
[vm1] [thread 5427 also had an error]#
[vm1] [thread 5426 also had an error][thread 5423 also had an error]
[vm1] # JRE version: OpenJDK Runtime Environment (11.0.1+13) (build
11.0.1+13-Debian-3)
[vm1] # Java VM: OpenJDK 64-Bit Server VM (11.0.1+13-Debian-3, mixed mode,
sharing, tiered, compressed oops, g1 gc, linux-amd64)
[vm1] # Problematic frame:
[vm1] # v ~BufferBlob::vtable chunks
[vm1] #
[vm1] # Core dump will be written. Default location:
/home/geode/geode/geode-lucene/build/upgradeTest8/dunit/vm1/core
[vm1] #
[vm1] # An error report file with more information is saved as:
[vm1] #
/home/geode/geode/geode-lucene/build/upgradeTest8/dunit/vm1/hs_err_pid5176.log
[vm3_v130] [info 2019/01/16 21:05:09.581 UTC tid=0x23] Received method:
org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit$10.run with 0
args on object: "execute: put"
[vm1] Could not load hsdis-amd64.so; library not loadable; PrintAssembly is
disabled
[vm1] #
[vm1] # If you would like to submit a bug report, please visit:
[vm1] # http://bugreport.java.com/bugreport/crash.jsp
[vm1] #
{noformat}
> CI Failure:
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0,
> with reindex=false]
>
>
> Key: GEODE-6284
> URL: https://issues.apache.org/jira/browse/GEODE-6284
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Priority: Major
>
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> 34bae3263b09 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:352)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:57)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:496)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:484)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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)
[jira] [Updated] (GEODE-6288) PdxInstance.isDeserializable returns false for a JSON pdx instance
[ https://issues.apache.org/jira/browse/GEODE-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6288: -- Labels: pull-request-available (was: ) > PdxInstance.isDeserializable returns false for a JSON pdx instance > -- > > Key: GEODE-6288 > URL: https://issues.apache.org/jira/browse/GEODE-6288 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.9.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > PdxInstance.isDeserializable should only return false if the PdxInstance does > not change form. For example PdxInstance.getObject should always return the > same PdxInstance it is called on. > But in the case of PdxInstances created for JSON, getObject returns the JSON > form instead of the PdxInstance. So for JSON PdxInstances, isDeserializable > should return true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6289) createPdxInstanceFactory should fail if class name is null
Darrel Schneider created GEODE-6289: --- Summary: createPdxInstanceFactory should fail if class name is null Key: GEODE-6289 URL: https://issues.apache.org/jira/browse/GEODE-6289 Project: Geode Issue Type: Bug Components: serialization Reporter: Darrel Schneider Currently if you create a PdxInstanceFactory and give it null as the class name the factory will be created with no complaints. But later, that null class name, will cause NullPointerExceptions to be thrown. createPdxInstanceFactory should check the class name for null and throw IllegalArgumentException -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6289) createPdxInstanceFactory should fail if class name is null
[ https://issues.apache.org/jira/browse/GEODE-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-6289: --- Assignee: Darrel Schneider > createPdxInstanceFactory should fail if class name is null > -- > > Key: GEODE-6289 > URL: https://issues.apache.org/jira/browse/GEODE-6289 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > Currently if you create a PdxInstanceFactory and give it null as the class > name the factory will be created with no complaints. But later, that null > class name, will cause NullPointerExceptions to be thrown. > createPdxInstanceFactory should check the class name for null and throw > IllegalArgumentException -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4337) Geode Native C++ Example (Server-side function execution)
[ https://issues.apache.org/jira/browse/GEODE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745449#comment-16745449 ] ASF subversion and git services commented on GEODE-4337: Commit d52262a18fded4cae4d1f931fcce6a90d802ef6d in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d52262a ] GEODE-4337, GEODE-4346 Geode-native guide: Document function execution examples (#435) * GEODE-4337, GEODE-4346 Geode-native user guide: Document function execution examples > Geode Native C++ Example (Server-side function execution) > - > > Key: GEODE-4337 > URL: https://issues.apache.org/jira/browse/GEODE-4337 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 8h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4337) Geode Native C++ Example (Server-side function execution)
[ https://issues.apache.org/jira/browse/GEODE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745447#comment-16745447 ] ASF subversion and git services commented on GEODE-4337: Commit d52262a18fded4cae4d1f931fcce6a90d802ef6d in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d52262a ] GEODE-4337, GEODE-4346 Geode-native guide: Document function execution examples (#435) * GEODE-4337, GEODE-4346 Geode-native user guide: Document function execution examples > Geode Native C++ Example (Server-side function execution) > - > > Key: GEODE-4337 > URL: https://issues.apache.org/jira/browse/GEODE-4337 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 8h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4346) Geode Native C# Example (Server-side function example)
[ https://issues.apache.org/jira/browse/GEODE-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745450#comment-16745450 ] ASF subversion and git services commented on GEODE-4346: Commit d52262a18fded4cae4d1f931fcce6a90d802ef6d in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d52262a ] GEODE-4337, GEODE-4346 Geode-native guide: Document function execution examples (#435) * GEODE-4337, GEODE-4346 Geode-native user guide: Document function execution examples > Geode Native C# Example (Server-side function example) > -- > > Key: GEODE-4346 > URL: https://issues.apache.org/jira/browse/GEODE-4346 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4346) Geode Native C# Example (Server-side function example)
[ https://issues.apache.org/jira/browse/GEODE-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745448#comment-16745448 ] ASF subversion and git services commented on GEODE-4346: Commit d52262a18fded4cae4d1f931fcce6a90d802ef6d in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d52262a ] GEODE-4337, GEODE-4346 Geode-native guide: Document function execution examples (#435) * GEODE-4337, GEODE-4346 Geode-native user guide: Document function execution examples > Geode Native C# Example (Server-side function example) > -- > > Key: GEODE-4346 > URL: https://issues.apache.org/jira/browse/GEODE-4346 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6289) createPdxInstanceFactory should fail if class name is null
[ https://issues.apache.org/jira/browse/GEODE-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745451#comment-16745451 ] ASF subversion and git services commented on GEODE-6289: Commit aba102e719ecc4a9b5ebf34f3bf3757add677059 in geode's branch refs/heads/feature/GEODE-6289 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=aba102e ] GEODE-6289: check for null className on createPdxInstanceFactory > createPdxInstanceFactory should fail if class name is null > -- > > Key: GEODE-6289 > URL: https://issues.apache.org/jira/browse/GEODE-6289 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > Currently if you create a PdxInstanceFactory and give it null as the class > name the factory will be created with no complaints. But later, that null > class name, will cause NullPointerExceptions to be thrown. > createPdxInstanceFactory should check the class name for null and throw > IllegalArgumentException -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6289) createPdxInstanceFactory should fail if class name is null
[ https://issues.apache.org/jira/browse/GEODE-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6289: -- Labels: pull-request-available (was: ) > createPdxInstanceFactory should fail if class name is null > -- > > Key: GEODE-6289 > URL: https://issues.apache.org/jira/browse/GEODE-6289 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > Currently if you create a PdxInstanceFactory and give it null as the class > name the factory will be created with no complaints. But later, that null > class name, will cause NullPointerExceptions to be thrown. > createPdxInstanceFactory should check the class name for null and throw > IllegalArgumentException -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5913) resolve jstack using JAVA_HOME
[ https://issues.apache.org/jira/browse/GEODE-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745494#comment-16745494 ] ASF subversion and git services commented on GEODE-5913: Commit 9d6c7f427f7f39b76190c8ee34ee569f359a0522 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9d6c7f4 ] GEODE-5913: Use JAVA_HOME/jps in the capture-call-stacks script. This script was using the wrong jps command, it needed to consider JAVA_HOME. > resolve jstack using JAVA_HOME > -- > > Key: GEODE-5913 > URL: https://issues.apache.org/jira/browse/GEODE-5913 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > test in the pipeline do not have java etc on the path, but > capture-call-stacks.sh assumes jstack is on the path. Change it to try > $JAVA_HOME first. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6290) PdxInstance with an empty string as class name should not support class versioning
Darrel Schneider created GEODE-6290: --- Summary: PdxInstance with an empty string as class name should not support class versioning Key: GEODE-6290 URL: https://issues.apache.org/jira/browse/GEODE-6290 Project: Geode Issue Type: Bug Components: serialization Reporter: Darrel Schneider Currently if you create a PdxInstanceFactory with the empty string as the class name then the PdxInstances it creates support class versioning. Since the empty string is not a class, these PdxInstances should not support class versioning. The only place this shows up is in PdxInstance.equal which allows two instances with different identity fields to still be equal. It does this if the one that has the identity field has the default value for it. What should happen if you have two PdxInstances with the class name "", is that they are only equal if the have all the same identity fields. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6290) PdxInstance with an empty string as class name should not support class versioning
[ https://issues.apache.org/jira/browse/GEODE-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-6290: --- Assignee: Darrel Schneider > PdxInstance with an empty string as class name should not support class > versioning > -- > > Key: GEODE-6290 > URL: https://issues.apache.org/jira/browse/GEODE-6290 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > Currently if you create a PdxInstanceFactory with the empty string as the > class name then the PdxInstances it creates support class versioning. Since > the empty string is not a class, these PdxInstances should not support class > versioning. The only place this shows up is in PdxInstance.equal which allows > two instances with different identity fields to still be equal. It does this > if the one that has the identity field has the default value for it. > What should happen if you have two PdxInstances with the class name "", is > that they are only equal if the have all the same identity fields. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6290) PdxInstance with an empty string as class name should not support class versioning
[ https://issues.apache.org/jira/browse/GEODE-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745572#comment-16745572 ] ASF subversion and git services commented on GEODE-6290: Commit e7d9b05c9d1a14798682559429489c5ebf147ec9 in geode's branch refs/heads/feature/GEODE-6290 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e7d9b05 ] GEODE-6290: change PdxInstance.equals for empty class name PdxInstance.equals will only act as if an instance has a field with the default value if the class name is not empty. If the class name is empty it will now require that both instances have all the same identity fields. > PdxInstance with an empty string as class name should not support class > versioning > -- > > Key: GEODE-6290 > URL: https://issues.apache.org/jira/browse/GEODE-6290 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > Currently if you create a PdxInstanceFactory with the empty string as the > class name then the PdxInstances it creates support class versioning. Since > the empty string is not a class, these PdxInstances should not support class > versioning. The only place this shows up is in PdxInstance.equal which allows > two instances with different identity fields to still be equal. It does this > if the one that has the identity field has the default value for it. > What should happen if you have two PdxInstances with the class name "", is > that they are only equal if the have all the same identity fields. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6290) PdxInstance with an empty string as class name should not support class versioning
[ https://issues.apache.org/jira/browse/GEODE-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6290: -- Labels: pull-request-available (was: ) > PdxInstance with an empty string as class name should not support class > versioning > -- > > Key: GEODE-6290 > URL: https://issues.apache.org/jira/browse/GEODE-6290 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > Currently if you create a PdxInstanceFactory with the empty string as the > class name then the PdxInstances it creates support class versioning. Since > the empty string is not a class, these PdxInstances should not support class > versioning. The only place this shows up is in PdxInstance.equal which allows > two instances with different identity fields to still be equal. It does this > if the one that has the identity field has the default value for it. > What should happen if you have two PdxInstances with the class name "", is > that they are only equal if the have all the same identity fields. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6288) PdxInstance.isDeserializable returns false for a JSON pdx instance
[ https://issues.apache.org/jira/browse/GEODE-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-6288. - Resolution: Fixed Fix Version/s: 1.9.0 > PdxInstance.isDeserializable returns false for a JSON pdx instance > -- > > Key: GEODE-6288 > URL: https://issues.apache.org/jira/browse/GEODE-6288 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.9.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > PdxInstance.isDeserializable should only return false if the PdxInstance does > not change form. For example PdxInstance.getObject should always return the > same PdxInstance it is called on. > But in the case of PdxInstances created for JSON, getObject returns the JSON > form instead of the PdxInstance. So for JSON PdxInstances, isDeserializable > should return true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6288) PdxInstance.isDeserializable returns false for a JSON pdx instance
[ https://issues.apache.org/jira/browse/GEODE-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745577#comment-16745577 ] ASF subversion and git services commented on GEODE-6288: Commit 4ca1c220dd8bb59db5e66768e78eb49da191dde2 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4ca1c22 ] GEODE-6288: change isDeserializable to return true on JSON pdx (#3089) > PdxInstance.isDeserializable returns false for a JSON pdx instance > -- > > Key: GEODE-6288 > URL: https://issues.apache.org/jira/browse/GEODE-6288 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.9.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > PdxInstance.isDeserializable should only return false if the PdxInstance does > not change form. For example PdxInstance.getObject should always return the > same PdxInstance it is called on. > But in the case of PdxInstances created for JSON, getObject returns the JSON > form instead of the PdxInstance. So for JSON PdxInstances, isDeserializable > should return true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745600#comment-16745600 ] ASF subversion and git services commented on GEODE-6244: Commit f4b8cf2f8dbcb98b541b24238b50b4066ff136a8 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f4b8cf2 ] GEODE-6244 Healthy member kicked out by sick member - do not allow membership manager suspect initiation to kick out a member on the first failed check - perform a self-health check before sending SuspectRequest messages - consider members who have sent shutdown messages as gone when performing "should I become coordinator" checks in GMSHealthMonitor - modified the membership view installed by GMSJoinLeave to be immutable so it isn't inadvertently changes Squashed commit of the following: commit 44f37c38d3b42f1ec7b1c440cae234b3fc123955 Author: Bruce Schuchardt Date: Thu Jan 17 14:28:25 2019 -0800 fixes for regression failures commit 320e98f85f2e16ea5a48dc316aeb81094b7cfd8d Author: Bruce Schuchardt Date: Fri Jan 4 14:42:03 2019 -0800 fix for failing unit tests & a lgtm warning commit 144f94335042fa8d879413edefe48aa02abb7cb3 Author: Bruce Schuchardt Date: Fri Jan 4 10:36:22 2019 -0800 fixes for unit test hang - remove suspect from members-in-final-check collection and initiate both remote and local suspect processing - renamed "final check" to "availability check" since it isn't necessarily a "final" check - perform a self-check before telling others to check a suspect commit fb3dfd00477cc48fb2d4dd85fe1ec532ed68f82b Author: Bruce Schuchardt Date: Thu Jan 3 14:22:51 2019 -0800 leave the member unsuspected after final check fails If the final check fails and we're not going to remove the suspect from the distributed system we need to leave it in an "unsuspected" state locally so that the background monitoring thread will look at it again. Also, if the final check failed in the membership coordinator there's no point in doing another check so we move directly to removing the suspect. commit 25134b19e2a324ff04c3a3d1139bafe641031729 Author: Bruce Schuchardt Date: Thu Jan 3 12:49:56 2019 -0800 GEODE-6244 Healthy member kicked out by Sick member GMSMembershipManager.verifyMember() should not initiate direct removal of the target member if an availability check fails. Instead it should initiate suspect processing. This adds new unit tests for GMSHealthMonitor.checkIfAvailable() and changes the availability check to initiate suspect processing if the check fails. > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Reporter: Bruce Schuchardt >Priority: Major > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coordinator determines suspect is available > This is all due to the checkMember call in GMSMembershipManager passing > _true_ for the _initiateRemoval_ parameter. It should be passing _false_. -- This messag
[jira] [Commented] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745601#comment-16745601 ] ASF subversion and git services commented on GEODE-6244: Commit f4b8cf2f8dbcb98b541b24238b50b4066ff136a8 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f4b8cf2 ] GEODE-6244 Healthy member kicked out by sick member - do not allow membership manager suspect initiation to kick out a member on the first failed check - perform a self-health check before sending SuspectRequest messages - consider members who have sent shutdown messages as gone when performing "should I become coordinator" checks in GMSHealthMonitor - modified the membership view installed by GMSJoinLeave to be immutable so it isn't inadvertently changes Squashed commit of the following: commit 44f37c38d3b42f1ec7b1c440cae234b3fc123955 Author: Bruce Schuchardt Date: Thu Jan 17 14:28:25 2019 -0800 fixes for regression failures commit 320e98f85f2e16ea5a48dc316aeb81094b7cfd8d Author: Bruce Schuchardt Date: Fri Jan 4 14:42:03 2019 -0800 fix for failing unit tests & a lgtm warning commit 144f94335042fa8d879413edefe48aa02abb7cb3 Author: Bruce Schuchardt Date: Fri Jan 4 10:36:22 2019 -0800 fixes for unit test hang - remove suspect from members-in-final-check collection and initiate both remote and local suspect processing - renamed "final check" to "availability check" since it isn't necessarily a "final" check - perform a self-check before telling others to check a suspect commit fb3dfd00477cc48fb2d4dd85fe1ec532ed68f82b Author: Bruce Schuchardt Date: Thu Jan 3 14:22:51 2019 -0800 leave the member unsuspected after final check fails If the final check fails and we're not going to remove the suspect from the distributed system we need to leave it in an "unsuspected" state locally so that the background monitoring thread will look at it again. Also, if the final check failed in the membership coordinator there's no point in doing another check so we move directly to removing the suspect. commit 25134b19e2a324ff04c3a3d1139bafe641031729 Author: Bruce Schuchardt Date: Thu Jan 3 12:49:56 2019 -0800 GEODE-6244 Healthy member kicked out by Sick member GMSMembershipManager.verifyMember() should not initiate direct removal of the target member if an availability check fails. Instead it should initiate suspect processing. This adds new unit tests for GMSHealthMonitor.checkIfAvailable() and changes the availability check to initiate suspect processing if the check fails. > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Reporter: Bruce Schuchardt >Priority: Major > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coordinator determines suspect is available > This is all due to the checkMember call in GMSMembershipManager passing > _true_ for the _initiateRemoval_ parameter. It should be passing _false_. -- This messag
[jira] [Created] (GEODE-6291) gfsh create jdbc-mapping should store pdx field to JDBC table column mapping to cluster config
Darrel Schneider created GEODE-6291: --- Summary: gfsh create jdbc-mapping should store pdx field to JDBC table column mapping to cluster config Key: GEODE-6291 URL: https://issues.apache.org/jira/browse/GEODE-6291 Project: Geode Issue Type: Improvement Components: extensions Reporter: Darrel Schneider Currently 'gfsh create jdbc-mapping' does not define any of the actual pdx field to column mapping information. Instead it just waits until a get or put is done and then figures out how to do the mapping. gfsh create jdbc-mapping should instead read the meta data from the table and figure out how to map the columns to pdx. The mapping it determines should be stored in cluster config. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-6244. - Resolution: Fixed Fix Version/s: 1.9.0 > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.9.0 > > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coordinator determines suspect is available > This is all due to the checkMember call in GMSMembershipManager passing > _true_ for the _initiateRemoval_ parameter. It should be passing _false_. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6291) gfsh create jdbc-mapping should store pdx field to JDBC table column mapping to cluster config
[ https://issues.apache.org/jira/browse/GEODE-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-6291: Affects Version/s: 1.9.0 > gfsh create jdbc-mapping should store pdx field to JDBC table column mapping > to cluster config > -- > > Key: GEODE-6291 > URL: https://issues.apache.org/jira/browse/GEODE-6291 > Project: Geode > Issue Type: Improvement > Components: extensions >Affects Versions: 1.9.0 >Reporter: Darrel Schneider >Priority: Major > > Currently 'gfsh create jdbc-mapping' does not define any of the actual pdx > field to column mapping information. Instead it just waits until a get or put > is done and then figures out how to do the mapping. > gfsh create jdbc-mapping should instead read the meta data from the table and > figure out how to map the columns to pdx. The mapping it determines should be > stored in cluster config. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt updated GEODE-6244: Affects Version/s: 1.1.0 1.1.1 1.2.0 1.3.0 1.2.1 1.4.0 1.5.0 1.6.0 1.7.0 1.8.0 > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, > 1.7.0, 1.8.0 >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.9.0 > > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coordinator determines suspect is available > This is all due to the checkMember call in GMSMembershipManager passing > _true_ for the _initiateRemoval_ parameter. It should be passing _false_. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6292) Hot loop when joining if locator-wait-time is set and there are no locators
Bruce Schuchardt created GEODE-6292: --- Summary: Hot loop when joining if locator-wait-time is set and there are no locators Key: GEODE-6292 URL: https://issues.apache.org/jira/browse/GEODE-6292 Project: Geode Issue Type: New Feature Components: membership Reporter: Bruce Schuchardt If you start up a locator and three servers and then kill two of the servers the locator and remaining server will go into auto-reconnect mode. When they attempt to start up they will run a hot thread if locator-wait-time is set because there is no stall in the loop that contacts locators for the duration of this wait time in GMSJoinLeave.findCoordinator(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6292) Hot loop when joining if locator-wait-time is set and there are no locators
[ https://issues.apache.org/jira/browse/GEODE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-6292: --- Assignee: Bruce Schuchardt > Hot loop when joining if locator-wait-time is set and there are no locators > --- > > Key: GEODE-6292 > URL: https://issues.apache.org/jira/browse/GEODE-6292 > Project: Geode > Issue Type: New Feature > Components: membership >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > > If you start up a locator and three servers and then kill two of the servers > the locator and remaining server will go into auto-reconnect mode. When they > attempt to start up they will run a hot thread if locator-wait-time is set > because there is no stall in the loop that contacts locators for the duration > of this wait time in GMSJoinLeave.findCoordinator(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6268) initializeUniquePortRange_willReturnUniquePortsForUniqueRanges seems flaky on Windows
[ https://issues.apache.org/jira/browse/GEODE-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6268: -- Labels: pull-request-available (was: ) > initializeUniquePortRange_willReturnUniquePortsForUniqueRanges seems flaky on > Windows > - > > Key: GEODE-6268 > URL: https://issues.apache.org/jira/browse/GEODE-6268 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Assignee: Kenneth Howe >Priority: Major > Labels: pull-request-available > > org.apache.geode.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_willReturnUniquePortsForUniqueRanges > periodically fails on windows. It seems like there's some flakiness being > introduced that may be platform specfic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6291) gfsh create jdbc-mapping should store pdx field to JDBC table column mapping to cluster config
[ https://issues.apache.org/jira/browse/GEODE-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-6291: --- Assignee: Darrel Schneider > gfsh create jdbc-mapping should store pdx field to JDBC table column mapping > to cluster config > -- > > Key: GEODE-6291 > URL: https://issues.apache.org/jira/browse/GEODE-6291 > Project: Geode > Issue Type: Improvement > Components: extensions >Affects Versions: 1.9.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > Currently 'gfsh create jdbc-mapping' does not define any of the actual pdx > field to column mapping information. Instead it just waits until a get or put > is done and then figures out how to do the mapping. > gfsh create jdbc-mapping should instead read the meta data from the table and > figure out how to map the columns to pdx. The mapping it determines should be > stored in cluster config. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6293) Gfsh execute function command expects the function to have a result
Barry Oglesby created GEODE-6293:
Summary: Gfsh execute function command expects the function to
have a result
Key: GEODE-6293
URL: https://issues.apache.org/jira/browse/GEODE-6293
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Barry Oglesby
Functions with hasResult returning false cause gfsh to log this exception
message:
{noformat}
gfsh>execute function --id=TestNoResultFunction --region=/data
Member | Status | Message
| -- |
server-1 | ERROR | Exception: Cannot return any result as the
Function#hasResult() is false
{noformat}
That message is coming from `UserFunctionExecution.execute` which does:
{noformat}
List results = (List)
execution.execute(function.getId()).getResult();
{noformat}
Here is the stack where that happens:
{noformat}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1333)
at
org.apache.geode.internal.cache.execute.NoResult.getResult(NoResult.java:56)
at
org.apache.geode.management.internal.cli.functions.UserFunctionExecution.execute(UserFunctionExecution.java:156)
at
org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193)
at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367)
at
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:433)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:956)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:810)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Here is a potential fix that addresses the issue:
{noformat}
List results = null;
ResultCollector rc = execution.execute(function.getId());
if (function.hasResult()) {
results = (List) rc.getResult();
}
{noformat}
This fix causes gfsh to report an OK result:
{noformat}
gfsh>execute function --id=TestNoResultFunction --region=/data
Member | Status | Message
| -- | ---
server-1 | OK | []
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745622#comment-16745622
]
ASF subversion and git services commented on GEODE-6285:
Commit 73fea3c240a2010d549d066511d07ec54f866111 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=73fea3c ]
GEODE-6285: Make MBean names immutable in loner
Introduce new DistributedMember.getUniqueId which is immutable.
Change MBeanJMXAdapter to use getUniqueId for MBean names
instead of getId when a member name has not been specified.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> *GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}*. The
> *\{1\}* parameter value is *10.118.20.84(28927-loner)-0-6ea32c5* which
> contains a zero where the membership port would normally be displayed:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> {noformat}
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> {noformat}
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the MBean as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-6294: - Issue Type: Improvement (was: Bug) > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, jmx >Reporter: Kirk Lund >Priority: Major > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745639#comment-16745639 ] ASF subversion and git services commented on GEODE-6244: Commit efcfa9390c77814f7654a37e08fb76b42b782b8d in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=efcfa93 ] Revert "GEODE-6244 Healthy member kicked out by sick member" There are unit test failures caused by what I thought were innocuous changes This reverts commit f4b8cf2f8dbcb98b541b24238b50b4066ff136a8. > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, > 1.7.0, 1.8.0 >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.9.0 > > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coordinator determines suspect is available > This is all due to the checkMember call in GMSMembershipManager passing > _true_ for the _initiateRemoval_ parameter. It should be passing _false_. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-6294: Assignee: Kirk Lund > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6294) Add disable-jmx configuration property to disable JMX
Kirk Lund created GEODE-6294: Summary: Add disable-jmx configuration property to disable JMX Key: GEODE-6294 URL: https://issues.apache.org/jira/browse/GEODE-6294 Project: Geode Issue Type: Bug Components: configuration, jmx Reporter: Kirk Lund Add disable-jmx configuration property to disable JMX. This option is boolean and will have a false value by default. Setting it to true will prevent Geode from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6292) Hot loop when joining if locator-wait-time is set and there are no locators
[ https://issues.apache.org/jira/browse/GEODE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745649#comment-16745649 ] ASF subversion and git services commented on GEODE-6292: Commit fc574dffefad90848b2c2e6f924241596316a0da in geode's branch refs/heads/feature/GEODE-6292 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fc574df ] GEODE-6292 hot loop in GMSJoinLeave.findCoordinator Added a 1 second pause before retrying if no locators could be contacted and locator-wait-time has been set. > Hot loop when joining if locator-wait-time is set and there are no locators > --- > > Key: GEODE-6292 > URL: https://issues.apache.org/jira/browse/GEODE-6292 > Project: Geode > Issue Type: New Feature > Components: membership >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > > If you start up a locator and three servers and then kill two of the servers > the locator and remaining server will go into auto-reconnect mode. When they > attempt to start up they will run a hot thread if locator-wait-time is set > because there is no stall in the loop that contacts locators for the duration > of this wait time in GMSJoinLeave.findCoordinator(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745657#comment-16745657 ] ASF subversion and git services commented on GEODE-6244: Commit fce4d61dae28c4b244ee71fb4a10ce0bff11a6c9 in geode's branch refs/heads/feature/GEODE-6244b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fce4d61 ] GEODE-6244 Healthy member kicked out by sick member - do not allow membership manager suspect initiation to kick out a member on the first failed check - perform a self-health check before sending SuspectRequest messages - consider members who have sent shutdown messages as gone when performing "should I become coordinator" checks in GMSHealthMonitor - modified the membership view installed by GMSJoinLeave to be immutable so it isn't inadvertently changes Squashed commit of the following: commit 44f37c38d3b42f1ec7b1c440cae234b3fc123955 Author: Bruce Schuchardt Date: Thu Jan 17 14:28:25 2019 -0800 fixes for regression failures commit 320e98f85f2e16ea5a48dc316aeb81094b7cfd8d Author: Bruce Schuchardt Date: Fri Jan 4 14:42:03 2019 -0800 fix for failing unit tests & a lgtm warning commit 144f94335042fa8d879413edefe48aa02abb7cb3 Author: Bruce Schuchardt Date: Fri Jan 4 10:36:22 2019 -0800 fixes for unit test hang - remove suspect from members-in-final-check collection and initiate both remote and local suspect processing - renamed "final check" to "availability check" since it isn't necessarily a "final" check - perform a self-check before telling others to check a suspect commit fb3dfd00477cc48fb2d4dd85fe1ec532ed68f82b Author: Bruce Schuchardt Date: Thu Jan 3 14:22:51 2019 -0800 leave the member unsuspected after final check fails If the final check fails and we're not going to remove the suspect from the distributed system we need to leave it in an "unsuspected" state locally so that the background monitoring thread will look at it again. Also, if the final check failed in the membership coordinator there's no point in doing another check so we move directly to removing the suspect. commit 25134b19e2a324ff04c3a3d1139bafe641031729 Author: Bruce Schuchardt Date: Thu Jan 3 12:49:56 2019 -0800 GEODE-6244 Healthy member kicked out by Sick member GMSMembershipManager.verifyMember() should not initiate direct removal of the target member if an availability check fails. Instead it should initiate suspect processing. This adds new unit tests for GMSHealthMonitor.checkIfAvailable() and changes the availability check to initiate suspect processing if the check fails. (cherry picked from commit f4b8cf2f8dbcb98b541b24238b50b4066ff136a8) > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, > 1.7.0, 1.8.0 >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.9.0 > > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coord
[jira] [Commented] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745658#comment-16745658 ] ASF subversion and git services commented on GEODE-6244: Commit fce4d61dae28c4b244ee71fb4a10ce0bff11a6c9 in geode's branch refs/heads/feature/GEODE-6244b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fce4d61 ] GEODE-6244 Healthy member kicked out by sick member - do not allow membership manager suspect initiation to kick out a member on the first failed check - perform a self-health check before sending SuspectRequest messages - consider members who have sent shutdown messages as gone when performing "should I become coordinator" checks in GMSHealthMonitor - modified the membership view installed by GMSJoinLeave to be immutable so it isn't inadvertently changes Squashed commit of the following: commit 44f37c38d3b42f1ec7b1c440cae234b3fc123955 Author: Bruce Schuchardt Date: Thu Jan 17 14:28:25 2019 -0800 fixes for regression failures commit 320e98f85f2e16ea5a48dc316aeb81094b7cfd8d Author: Bruce Schuchardt Date: Fri Jan 4 14:42:03 2019 -0800 fix for failing unit tests & a lgtm warning commit 144f94335042fa8d879413edefe48aa02abb7cb3 Author: Bruce Schuchardt Date: Fri Jan 4 10:36:22 2019 -0800 fixes for unit test hang - remove suspect from members-in-final-check collection and initiate both remote and local suspect processing - renamed "final check" to "availability check" since it isn't necessarily a "final" check - perform a self-check before telling others to check a suspect commit fb3dfd00477cc48fb2d4dd85fe1ec532ed68f82b Author: Bruce Schuchardt Date: Thu Jan 3 14:22:51 2019 -0800 leave the member unsuspected after final check fails If the final check fails and we're not going to remove the suspect from the distributed system we need to leave it in an "unsuspected" state locally so that the background monitoring thread will look at it again. Also, if the final check failed in the membership coordinator there's no point in doing another check so we move directly to removing the suspect. commit 25134b19e2a324ff04c3a3d1139bafe641031729 Author: Bruce Schuchardt Date: Thu Jan 3 12:49:56 2019 -0800 GEODE-6244 Healthy member kicked out by Sick member GMSMembershipManager.verifyMember() should not initiate direct removal of the target member if an availability check fails. Instead it should initiate suspect processing. This adds new unit tests for GMSHealthMonitor.checkIfAvailable() and changes the availability check to initiate suspect processing if the check fails. (cherry picked from commit f4b8cf2f8dbcb98b541b24238b50b4066ff136a8) > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, > 1.7.0, 1.8.0 >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.9.0 > > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coord
[jira] [Updated] (GEODE-6292) Hot loop when joining if locator-wait-time is set and there are no locators
[ https://issues.apache.org/jira/browse/GEODE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6292: -- Labels: pull-request-available (was: ) > Hot loop when joining if locator-wait-time is set and there are no locators > --- > > Key: GEODE-6292 > URL: https://issues.apache.org/jira/browse/GEODE-6292 > Project: Geode > Issue Type: New Feature > Components: membership >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > > If you start up a locator and three servers and then kill two of the servers > the locator and remaining server will go into auto-reconnect mode. When they > attempt to start up they will run a hot thread if locator-wait-time is set > because there is no stall in the loop that contacts locators for the duration > of this wait time in GMSJoinLeave.findCoordinator(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6289) createPdxInstanceFactory should fail if class name is null
[ https://issues.apache.org/jira/browse/GEODE-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-6289. - Resolution: Fixed Fix Version/s: 1.9.0 > createPdxInstanceFactory should fail if class name is null > -- > > Key: GEODE-6289 > URL: https://issues.apache.org/jira/browse/GEODE-6289 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently if you create a PdxInstanceFactory and give it null as the class > name the factory will be created with no complaints. But later, that null > class name, will cause NullPointerExceptions to be thrown. > createPdxInstanceFactory should check the class name for null and throw > IllegalArgumentException -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6289) createPdxInstanceFactory should fail if class name is null
[ https://issues.apache.org/jira/browse/GEODE-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745677#comment-16745677 ] ASF subversion and git services commented on GEODE-6289: Commit a757ccb87d75b3af6c5da619338297d24cc21519 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a757ccb ] GEODE-6289: check for null className on createPdxInstanceFactory (#3090) > createPdxInstanceFactory should fail if class name is null > -- > > Key: GEODE-6289 > URL: https://issues.apache.org/jira/browse/GEODE-6289 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Currently if you create a PdxInstanceFactory and give it null as the class > name the factory will be created with no complaints. But later, that null > class name, will cause NullPointerExceptions to be thrown. > createPdxInstanceFactory should check the class name for null and throw > IllegalArgumentException -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6294: -- Labels: pull-request-available (was: ) > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6285.
--
Resolution: Fixed
Fix Version/s: 1.9.0
Introduced new DistributedMember.getUniqueId() API which is now used for naming
MBeans if member name is not provided by User.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> *GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}*. The
> *\{1\}* parameter value is *10.118.20.84(28927-loner)-0-6ea32c5* which
> contains a zero where the membership port would normally be displayed:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> {noformat}
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> {noformat}
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the MBean as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6212) Need to add unit test on checkEquals method in ValueComparisonHelper class
[ https://issues.apache.org/jira/browse/GEODE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745705#comment-16745705 ] ASF subversion and git services commented on GEODE-6212: Commit 3cf75b6e057320ae5b9338dc6433afb168151b6c in geode's branch refs/heads/develop from pivotal-eshu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3cf75b6 ] GEODE-6212: Add unit test coverage for ValueComparisonHelper (#3082) * fixed an error in the helper class when adding test coverage. > Need to add unit test on checkEquals method in ValueComparisonHelper class > -- > > Key: GEODE-6212 > URL: https://issues.apache.org/jira/browse/GEODE-6212 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The method was moved from AbstractRegionEntry. Need to add unit test coverage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6212) Need to add unit test on checkEquals method in ValueComparisonHelper class
[ https://issues.apache.org/jira/browse/GEODE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-6212. - Resolution: Fixed Fix Version/s: 1.9.0 > Need to add unit test on checkEquals method in ValueComparisonHelper class > -- > > Key: GEODE-6212 > URL: https://issues.apache.org/jira/browse/GEODE-6212 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The method was moved from AbstractRegionEntry. Need to add unit test coverage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
