[jira] [Resolved] (GEODE-7335) CI failure: TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest fails with ContainerException: Server port 22617 did not shutdown within the timeout
[
https://issues.apache.org/jira/browse/GEODE-7335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-7335.
Resolution: Cannot Reproduce
I have run several thousand passes of this. It has not failed. I think this is
related to the low memory and image problems we had at that time.
> CI failure:
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest fails
> with ContainerException: Server port 22617 did not shutdown within the
> timeout period
> ---
>
> Key: GEODE-7335
> URL: https://issues.apache.org/jira/browse/GEODE-7335
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: CI, Flaky
>
> {noformat}
> org.codehaus.cargo.container.ContainerException: Failed to stop the Tomcat
> 7.x container. Check the
> [/home/geode/geode/geode-assembly/build/upgradeTest54/cargo_logs/TOMCAT7_client-server_test0_1_8b40f4f1-1c3c-4c78-9e8e-dc934c7ce7aa/container.log]
> file containing the container logs for more details.
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.stop(AbstractLocalContainer.java:305)
> at
> org.apache.geode.session.tests.ServerContainer.stop(ServerContainer.java:233)
> at
> org.apache.geode.session.tests.ContainerManager.stopContainer(ContainerManager.java:105)
> at
> org.apache.geode.session.tests.ContainerManager.stopContainers(ContainerManager.java:115)
> at
> org.apache.geode.session.tests.ContainerManager.stopAllActiveContainers(ContainerManager.java:122)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTestBase.stop(TomcatSessionBackwardsCompatibilityTestBase.java:173)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.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.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:62)
> at
>
[jira] [Commented] (GEODE-7395) Add Micrometer to documentation
[ https://issues.apache.org/jira/browse/GEODE-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965110#comment-16965110 ] ASF subversion and git services commented on GEODE-7395: Commit 37955245fd496594fa67b746de1aa2e2500d3530 in geode's branch refs/heads/develop from Nick Vallely [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3795524 ] GEODE-7395: Add Micrometer docs (#4266) * GEODE-7395: Add Micrometer docs Created a new section in the user guide's Tools and Modules section where we document what micrometer is, meters we have added, and how to use it. > Add Micrometer to documentation > --- > > Key: GEODE-7395 > URL: https://issues.apache.org/jira/browse/GEODE-7395 > Project: Geode > Issue Type: Improvement > Components: docs, statistics >Reporter: Nick Vallely >Assignee: Nick Vallely >Priority: Major > Labels: observability > Time Spent: 3h > Remaining Estimate: 0h > > As of 1.9 we added Micrometer as a way to publish metrics to external > monitoring systems. As of 1.10/1.11 we added metrics that would be emitted > out of a Meter Registry and documented everything in the Apache Geode wiki. > We need to formalize some of this functionality a little more with a section > on Micrometer in our docx. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7395) Add Micrometer to documentation
[ https://issues.apache.org/jira/browse/GEODE-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965111#comment-16965111 ] ASF subversion and git services commented on GEODE-7395: Commit 37955245fd496594fa67b746de1aa2e2500d3530 in geode's branch refs/heads/develop from Nick Vallely [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3795524 ] GEODE-7395: Add Micrometer docs (#4266) * GEODE-7395: Add Micrometer docs Created a new section in the user guide's Tools and Modules section where we document what micrometer is, meters we have added, and how to use it. > Add Micrometer to documentation > --- > > Key: GEODE-7395 > URL: https://issues.apache.org/jira/browse/GEODE-7395 > Project: Geode > Issue Type: Improvement > Components: docs, statistics >Reporter: Nick Vallely >Assignee: Nick Vallely >Priority: Major > Labels: observability > Time Spent: 3h > Remaining Estimate: 0h > > As of 1.9 we added Micrometer as a way to publish metrics to external > monitoring systems. As of 1.10/1.11 we added metrics that would be emitted > out of a Meter Registry and documented everything in the Apache Geode wiki. > We need to formalize some of this functionality a little more with a section > on Micrometer in our docx. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7017) CI failure: org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest > startupReportsOnlineOnlyAfterRedundancyRestored
[
https://issues.apache.org/jira/browse/GEODE-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-7017.
Resolution: Cannot Reproduce
Cannot reproduce after 12000 passes.
> CI failure:
> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored
> ---
>
> Key: GEODE-7017
> URL: https://issues.apache.org/jira/browse/GEODE-7017
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0
>Reporter: Anilkumar Gingade
>Assignee: Mark Hanson
>Priority: Major
>
> {noformat}
> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupValueRecoveryNotificationTest.persistentRegionThatRequiresValueRecovery(ServerStartupValueRecoveryNotificationTest.java:120)
> {noformat}
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/AcceptanceTestOpenJDK8/builds/797
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.9.0-build.0258/test-artifacts/1564078711/acceptancetestfiles-OpenJDK8-9.9.0-build.0258.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7372) gfsh shutdown --include-locators confirmation is ignored
[
https://issues.apache.org/jira/browse/GEODE-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-7372.
Fix Version/s: 1.11.0
Resolution: Fixed
> gfsh shutdown --include-locators confirmation is ignored
>
>
> Key: GEODE-7372
> URL: https://issues.apache.org/jira/browse/GEODE-7372
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Affects Versions: 1.11.0
>Reporter: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The gfsh shutdown command prompts the User for confirmation of the shutdown.
> If the User types {{n}} for no, it should abort and do nothing. However, the
> shutdown proceeds and shuts down the entire cluster including the locator
> regardless of how the User answers the prompt.
> {noformat}
> gfsh>shutdown --include-locators
> As a lot of data in memory will be lost, including possibly events in queues,
> do you really want to shutdown the entire distributed system? (Y/n): n
> Shutdown is triggered
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7374) ResultModel cannot be cast to Result
[ https://issues.apache.org/jira/browse/GEODE-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-7374. Fix Version/s: 1.11.0 Resolution: Fixed > ResultModel cannot be cast to Result > > > Key: GEODE-7374 > URL: https://issues.apache.org/jira/browse/GEODE-7374 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > a class cast failure when they use CommandService(like attached java class) > to run gfsh command such as list region: > org.apache.geode.management.internal.cli.result.model.ResultModel cannot be > cast to org.ap -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7386) CI failure: JmxCredentialTypeTest > testWithNonStringCredential failed with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-7386.
Fix Version/s: 1.11.0
Resolution: Fixed
> CI failure: JmxCredentialTypeTest > testWithNonStringCredential failed with
> AssertionError
> --
>
> Key: GEODE-7386
> URL: https://issues.apache.org/jira/browse/GEODE-7386
> Project: Geode
> Issue Type: Bug
> Components: jmx, management, security
>Reporter: Barrett Oglesby
>Assignee: Jinmei Liao
>Priority: Major
> Fix For: 1.11.0
>
>
> This test has failed in the last 2 IntegrationTestOpenJDK8 builds:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/1223
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/1224
> {noformat}
> org.apache.geode.management.internal.security.JmxCredentialTypeTest >
> testWithNonStringCredential FAILED
> java.lang.AssertionError:
> Expecting:
> <"Unsupported type: java.lang.Integer">
> to contain:
> <"filter status: REJECTED">
> at
> org.apache.geode.management.internal.security.JmxCredentialTypeTest.testWithNonStringCredential(JmxCredentialTypeTest.java:47)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965084#comment-16965084
]
Darrel Schneider commented on GEODE-7394:
-
I don't think this statement is true: "Without a PdxSerializer the command
essentially serves no purpose nor has any effect".
Pdx serialization can be used without a PdxSerializer. Domain classes can
implement the PdxSerializable interface.
Also, even if you are using a PdxSerializer, you may not need to have it on
your server. If you set --read-serialized=true on the server then it should
never need to use the PdxSerializer on the server even though it is used on the
client.
In the above use cases you may still want to set --read-serialized or
--ignore-unread-fields or the pdx disk store and the configure pdx command
allows you to do that.
The ReflectionBasedAutoSerializer is the easiest way to use pdx provided by
geode. My understanding is that one of the Spring projects has its own
PdxSerializer that works better with Spring than the
ReflectionBasedAutoSerializer. I know we have had requests before for the
default to be ReflectionBasedAutoSerializer with the .* REGEX. But I think one
of the current problems we have with that is that if you have a
ReflectionBasedAutoSerializer whose regex matches that class name then that
serialization takes precedence over other forms of serialization. So you could
have a JDK class that has its own special serialization code suddenly ignored
by geode serialization and instead it would be serialized by PDX. That could
cause performance issues, correctness issues, and compatibility issues.
Maybe we could enhance the PdxSerializer to have two stages in the
serialization precedence. The first state would ask it early if it wants to
serialize a class before all other serialization frameworks. If that request is
turned down it would then check the other ways of doing serialization like it
currently does. But a new stage at the end could be added after we have not
found any way to serialize an object. That would be to ask the PdxSerializer to
attempt serialization as a last ditch attempt. Maybe this "last ditch attempt"
could just be hardcoded into our serialization precedence with no need for the
user to even configure a PdxSerializer. We could just try all the current ways
we have and if none of them work ask our built in ReflectionBasedAutoSerializer
with a REGEX of .* to give it a try.
> Gfsh `configure pdx` command is non-intuitive and currently has a bad user
> experience
> -
>
> Key: GEODE-7394
> URL: https://issues.apache.org/jira/browse/GEODE-7394
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
>
> The _Gfsh_ {{configure pdx}} command does *not* register a {{PdxSerializer}}
> (e.g. {{ReflectionBasedAutoSerializer}}, or otherwise) unless the
> {{--auto-serializable-classes}} option is explicitly specified. Without a
> {{PdxSerializer}} the command essentially serves no purpose nor has any
> effect. Effectively, the command is useless.
> For example, doing something like `gfsh> configure pdx
> --read-serialized=false` or `gfsh> configure pdx --ignore-unread-fields` by
> itself is *pointless* since ultimately there would be no `PdxSerializer`
> registered in this case.
> _Gfsh_ should minimally register a `PdxSerializer` anytime the `configure
> pdx` command is used regardless of the options provided, especially if it
> returns successfully without incident. For instance, it could register the
> `ReflectionBaseAutoSerializer` with the REGEX {{.*}} (de/serializing all
> types, regardless of whether that is optimal or not).
> Alternatively, if we decide not to register the
> {{ReflectionBasedAutoSerialier}} with a generic REGEX (e.g. {{.*}}), then we
> should _fail-fast_ and the command should report that
> {{--[portable-]-auto-serializable-classes}} is required!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7370) ClassGraph library causes large memory leak in Geode after adding geode-log4j
[
https://issues.apache.org/jira/browse/GEODE-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-7370.
--
Fix Version/s: 1.11.0
Resolution: Fixed
> ClassGraph library causes large memory leak in Geode after adding geode-log4j
> -
>
> Key: GEODE-7370
> URL: https://issues.apache.org/jira/browse/GEODE-7370
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> According to the source code and documentation,
> io.github.classgraph.ScanResult must be closed to avoid memory and file leaks.
> I identified a large memory leak that apparently after adding geode-log4j.
> Surprisingly the cause ended up being an instance of ScanResult which is used
> by the management code to search the classpath for user classes that
> implement geode functions or gfsh commands.
> Geode currently depends on ClassGraph version 4.0.6, but the library is up to
> version 4.8.52 (averaging around a dozen releases per month).
> JVM bytes in use by io.github.classgraph after closing all ScanResult
> instances:
> * Before geode-log4j with ClassGraph 4.0.6: 20,488 bytes
> * Before geode-log4j with ClassGraph 4.8.52: 1,056 bytes
> * After geode-log4j with ClassGraph 4.0.6: 56,753,008 bytes
> * After geode-log4j with ClassGraph 4.8.52: 1,056 bytes
> Given the above results of my testing, I believe we need to keep this
> dependency up-to-date and upgrade to 4.8.52.
>
> More detailed notes below:
> Git version shas that were tested:
> {noformat}
> Before: 802687154131af16d350bf39d152feb4685ba7e6 (sha before geode-log4j)
> Before-w/upgrade: Before w/ ClassGraph upgraded from 4.0.6 to 4.8.52
> << Geode-log4j: efc2362d2bae0877a427ce2c29beae94118d6567 (geode-log4j) >>
> After: dffcb9446aef09c7bf6e626121f4d2ec5c74586f (async alerts)
> After-w/upgrade: After w/ ClassGraph upgraded from 4.0.6 to 4.8.52
> {noformat}
> Java process memory sizes:
> Before:
> {noformat}
> ChildVMs
> 22297 java 0.000:07.51 32 1104 252M 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> 22295 java 0.000:07.72 32 1104 259M 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> 22291 java 0.100:11.66 32 1104 291M 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> 22289 java 0.100:11.68 32 1104 300M 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> 22287 java 0.500:07.67 64 1168 276M+ 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> GradleWorkerMain
> 22286 java 0.400:03.55 67 1174 184M+ 0B 0B
> 0 0 sleeping *0[1]0.0 0.0501
> GradleWrapperMain
> 22173 java 0.100:01.63 28 19688M+ 0B 0B
> 22173 86991 sleeping *0[1]0.0 0.0501
> GradleDaemon
> 0 java 0.600:52.27 81 1201 814M 0B 0B
> 0 22173 sleeping *0[1]0.0 0.0501
> {noformat}
> Before-w/upgrade:
> {noformat}
> ChildVMs
> 25789 java 0.0 00:06.93 31 1101 257M 0B 0B
> 25714 25779 sleeping *0[1] 0.0 0.0501
> 25788 java 0.1 00:06.93 31 1101 259M+ 0B 0B
> 25714 25779 sleeping *0[1] 0.0 0.0501
> 25784 java 0.0 00:10.37 31 1101 286M 0B 0B
> 25714 25779 sleeping *0[1] 0.0 0.0501
> 25782 java 0.1 00:11.68 31 1101 278M 0B 0B
> 25714 25779 sleeping *0[1] 0.0 0.0501
> 25780 java 0.3 00:07.84 63/1 1165 308M+ 0B 0B
> 25714 25779 running *0[1] 0.0 0.0501
> GradleWorkerMain
> 25779 java 0.1 00:03.39 60 1160 183M 0B 0B
> 25714 25714 sleeping *0[1] 0.0 0.0501
> GradleDaemon
> 25714 java 0.8 00:48.79 79 1197 793M 0B 0B
> 25714 25667 sleeping *0[1] 0.0 0.0501
> GradleWrapperMain
> 25667 java 0.2 00:02.16 28 196101M+ 0B 0B
> 25667 86991 sleeping *0[1] 0.0 0.0501
> {noformat}
> After:
> {noformat}
> ChildVMs
> 21056 java 0.1 00:06.67 31 1101 256M 0B 0B
> 20988 21049 sleeping *0[1]0.0 0.0501
>
[jira] [Resolved] (GEODE-7399) Test functions do not need to use LogService
[ https://issues.apache.org/jira/browse/GEODE-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-7399. -- Fix Version/s: 1.11.0 Resolution: Fixed > Test functions do not need to use LogService > > > Key: GEODE-7399 > URL: https://issues.apache.org/jira/browse/GEODE-7399 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Dan Smith >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We have test functions that use LogService. That's an internal API, these > test functions should use LogManager instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7370) ClassGraph library causes large memory leak in Geode after adding geode-log4j
[
https://issues.apache.org/jira/browse/GEODE-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965066#comment-16965066
]
ASF subversion and git services commented on GEODE-7370:
Commit 7d08bfd3d268704f71d0d75c354b01d51ec3d8ce in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7d08bfd ]
GEODE-7370: Upgrade ClassGraph to 4.8.52 (#4237)
Upgrading ClassGraph from 4.0.6 to 4.8.52 fixes a memory leak that
appeared after introducing geode-log4j even though logging does not
use ClassGraph.
> ClassGraph library causes large memory leak in Geode after adding geode-log4j
> -
>
> Key: GEODE-7370
> URL: https://issues.apache.org/jira/browse/GEODE-7370
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> According to the source code and documentation,
> io.github.classgraph.ScanResult must be closed to avoid memory and file leaks.
> I identified a large memory leak that apparently after adding geode-log4j.
> Surprisingly the cause ended up being an instance of ScanResult which is used
> by the management code to search the classpath for user classes that
> implement geode functions or gfsh commands.
> Geode currently depends on ClassGraph version 4.0.6, but the library is up to
> version 4.8.52 (averaging around a dozen releases per month).
> JVM bytes in use by io.github.classgraph after closing all ScanResult
> instances:
> * Before geode-log4j with ClassGraph 4.0.6: 20,488 bytes
> * Before geode-log4j with ClassGraph 4.8.52: 1,056 bytes
> * After geode-log4j with ClassGraph 4.0.6: 56,753,008 bytes
> * After geode-log4j with ClassGraph 4.8.52: 1,056 bytes
> Given the above results of my testing, I believe we need to keep this
> dependency up-to-date and upgrade to 4.8.52.
>
> More detailed notes below:
> Git version shas that were tested:
> {noformat}
> Before: 802687154131af16d350bf39d152feb4685ba7e6 (sha before geode-log4j)
> Before-w/upgrade: Before w/ ClassGraph upgraded from 4.0.6 to 4.8.52
> << Geode-log4j: efc2362d2bae0877a427ce2c29beae94118d6567 (geode-log4j) >>
> After: dffcb9446aef09c7bf6e626121f4d2ec5c74586f (async alerts)
> After-w/upgrade: After w/ ClassGraph upgraded from 4.0.6 to 4.8.52
> {noformat}
> Java process memory sizes:
> Before:
> {noformat}
> ChildVMs
> 22297 java 0.000:07.51 32 1104 252M 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> 22295 java 0.000:07.72 32 1104 259M 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> 22291 java 0.100:11.66 32 1104 291M 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> 22289 java 0.100:11.68 32 1104 300M 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> 22287 java 0.500:07.67 64 1168 276M+ 0B 0B
> 0 22286 sleeping *0[1]0.0 0.0501
> GradleWorkerMain
> 22286 java 0.400:03.55 67 1174 184M+ 0B 0B
> 0 0 sleeping *0[1]0.0 0.0501
> GradleWrapperMain
> 22173 java 0.100:01.63 28 19688M+ 0B 0B
> 22173 86991 sleeping *0[1]0.0 0.0501
> GradleDaemon
> 0 java 0.600:52.27 81 1201 814M 0B 0B
> 0 22173 sleeping *0[1]0.0 0.0501
> {noformat}
> Before-w/upgrade:
> {noformat}
> ChildVMs
> 25789 java 0.0 00:06.93 31 1101 257M 0B 0B
> 25714 25779 sleeping *0[1] 0.0 0.0501
> 25788 java 0.1 00:06.93 31 1101 259M+ 0B 0B
> 25714 25779 sleeping *0[1] 0.0 0.0501
> 25784 java 0.0 00:10.37 31 1101 286M 0B 0B
> 25714 25779 sleeping *0[1] 0.0 0.0501
> 25782 java 0.1 00:11.68 31 1101 278M 0B 0B
> 25714 25779 sleeping *0[1] 0.0 0.0501
> 25780 java 0.3 00:07.84 63/1 1165 308M+ 0B 0B
> 25714 25779 running *0[1] 0.0 0.0501
> GradleWorkerMain
> 25779 java 0.1 00:03.39 60 1160 183M 0B 0B
> 25714 25714 sleeping *0[1] 0.0 0.0501
> GradleDaemon
> 25714 java 0.8 00:48.79 79 1197 793M 0B 0B
> 25714 25667 sleeping *0[1] 0.0 0.0
[jira] [Commented] (GEODE-7399) Test functions do not need to use LogService
[ https://issues.apache.org/jira/browse/GEODE-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965067#comment-16965067 ] ASF subversion and git services commented on GEODE-7399: Commit d9438c7653762de4ec82b31a7970341c9e59596e in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d9438c7 ] GEODE-7399: Use LogManager instead of LogService in test functions (#4269) These test functions should not use an internal logging API. > Test functions do not need to use LogService > > > Key: GEODE-7399 > URL: https://issues.apache.org/jira/browse/GEODE-7399 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Dan Smith >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We have test functions that use LogService. That's an internal API, these > test functions should use LogManager instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6661) NioSslEngine has some problems in its ByteBuffer management
[ https://issues.apache.org/jira/browse/GEODE-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-6661. - Resolution: Fixed > NioSslEngine has some problems in its ByteBuffer management > --- > > Key: GEODE-6661 > URL: https://issues.apache.org/jira/browse/GEODE-6661 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 0.5h > Remaining Estimate: 0h > > the NioSslEngine appears to have some problems with how it manages ByteBuffer > instances, > # It has a "handshakeBuffer" instance variable and code that will > conditionally create it but higher level code always passes in a non-null > inputBuffer. It should just be changed to require an outside buffer. Also no > need for an instance variable since "handshakeBuffer" is only used by a > single method. It can just be passed in to it. > # The "myNetData" and "peerAppData" are both created as heap ByteBuffer > instances in the constructor. But if they ever need to be resized it does it > by calling Buffers.expandWriteBufferIfNeeded which will return the original > heap ByteBuffer to the queue of buffers that should always be direct byte > buffers. And now the one used by NioSslEngine will be direct instead of heap. > This will also cause the stats that Buffers has to be wrong because we return > a buffer to it that we did not allocate from it. > # From a performance standpoint, we want to also have the buffer that we > directly write to a socket channel, or fill by reading from a socket channel, > be a direct byte buffer. Other byte buffers should not be direct. So normally > the ByteBuffer we serialize an outgoing message into is a direct ByteBuffer > because it will be handed to the socket channel for the message write. But in > the case of the NioSslEngine we would want that first buffer to be a > non-direct, heap ByteBuffer. It ends up being passed to NioSslEngine.wrap > which copies it into "myNetData". The encrypted data in "myNetData" in turn > is written to the socket channel so it is the one that should be a direct > ByteBuffer. For reading it is just the opposite. We read encrypted data from > the socket channel into what should be direct byte buffer (and it currently > is because it is allocated with Buffers). But then it is passed to > NioSslEngine.unwrap which will copy (and decrypt) what is in it into the > "peerAppData". So "peerAppData" should be kept a heap ByteBuffer. You can > always get away with using either type of ByteBuffer. It is simply a > performance issue. What happens at a lower level in the jdk with a heap > ByteBuffer being used with a socket channel is that it eventually just copies > it into a direct ByteBuffer and then uses it. That extra copy can hurt > performance and in the past we had trouble with the jdk caching of direct > ByteBuffers not reusing as well as ours and running out of direct memory. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7402) running create disk store multiple time resulted in duplicate entries in cluster.xml
[ https://issues.apache.org/jira/browse/GEODE-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos closed GEODE-7402. - Assignee: Juan Ramos > running create disk store multiple time resulted in duplicate entries in > cluster.xml > > > Key: GEODE-7402 > URL: https://issues.apache.org/jira/browse/GEODE-7402 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Ashish Choudhary >Assignee: Juan Ramos >Priority: Major > Fix For: 1.10.0 > > > # run gfsh create disk store command > # export cluster configuration. no duplicate entry for disk store. > # execute step1 again. > # execute step2 again. > # there are duplicate entry for disk store in cluster.xml > It should fail fast if disk store already exists. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7402) running create disk store multiple time resulted in duplicate entries in cluster.xml
[ https://issues.apache.org/jira/browse/GEODE-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos resolved GEODE-7402. --- Fix Version/s: 1.10.0 Resolution: Duplicate > running create disk store multiple time resulted in duplicate entries in > cluster.xml > > > Key: GEODE-7402 > URL: https://issues.apache.org/jira/browse/GEODE-7402 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Ashish Choudhary >Priority: Major > Fix For: 1.10.0 > > > # run gfsh create disk store command > # export cluster configuration. no duplicate entry for disk store. > # execute step1 again. > # execute step2 again. > # there are duplicate entry for disk store in cluster.xml > It should fail fast if disk store already exists. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7402) running create disk store multiple time resulted in duplicate entries in cluster.xml
[
https://issues.apache.org/jira/browse/GEODE-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965049#comment-16965049
]
Juan Ramos commented on GEODE-7402:
---
[~achoudhary]: this has been fixed in Geode 1.10.0 trough GEODE-6749 already
{noformat}
gfsh>version
1.10.0
gfsh>create disk-store --name=testDiskStore --allow-force-compaction=false
--auto-compact=false --dir=test
Member | Status | Message
--- | -- |
server1 | OK | Created disk store testDiskStore
gfsh>export cluster-configuration --xml-file=test1.xml
cluster.xml:
xml content exported to /temp/GEODE-7402/test1.xml
bash> cat /temp/GEODE-7402/test1.xml
http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd
http://geode.apache.org/schema/jdbc
http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd
http://geode.apache.org/schema/lucene
http://geode.apache.org/schema/lucene/lucene-1.0.xsd;
xmlns="http://geode.apache.org/schema/cache;
xmlns:lucene="http://geode.apache.org/schema/lucene;
xmlns:jdbc="http://geode.apache.org/schema/jdbc;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
test
gfsh>create disk-store --name=testDiskStore --allow-force-compaction=false
--auto-compact=false --dir=test
Error: Disk store testDiskStore already exists
gfsh>export cluster-configuration --xml-file=test2.xml
cluster.xml:
xml content exported to /temp/GEODE-7402/test2.xml
bash> cat /temp/GEODE-7402/test2.xml
http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd
http://geode.apache.org/schema/jdbc
http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd
http://geode.apache.org/schema/lucene
http://geode.apache.org/schema/lucene/lucene-1.0.xsd;
xmlns="http://geode.apache.org/schema/cache;
xmlns:lucene="http://geode.apache.org/schema/lucene;
xmlns:jdbc="http://geode.apache.org/schema/jdbc;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
test
{noformat}
> running create disk store multiple time resulted in duplicate entries in
> cluster.xml
>
>
> Key: GEODE-7402
> URL: https://issues.apache.org/jira/browse/GEODE-7402
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Ashish Choudhary
>Priority: Major
>
> # run gfsh create disk store command
> # export cluster configuration. no duplicate entry for disk store.
> # execute step1 again.
> # execute step2 again.
> # there are duplicate entry for disk store in cluster.xml
> It should fail fast if disk store already exists.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6661) NioSslEngine has some problems in its ByteBuffer management
[ https://issues.apache.org/jira/browse/GEODE-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965046#comment-16965046 ] ASF subversion and git services commented on GEODE-6661: Commit 418d929e3e03185cd6330c828c9b9ed395a76d4b in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=418d929 ] GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267) - Fixed use of Direct and Non-Direct buffers > NioSslEngine has some problems in its ByteBuffer management > --- > > Key: GEODE-6661 > URL: https://issues.apache.org/jira/browse/GEODE-6661 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 0.5h > Remaining Estimate: 0h > > the NioSslEngine appears to have some problems with how it manages ByteBuffer > instances, > # It has a "handshakeBuffer" instance variable and code that will > conditionally create it but higher level code always passes in a non-null > inputBuffer. It should just be changed to require an outside buffer. Also no > need for an instance variable since "handshakeBuffer" is only used by a > single method. It can just be passed in to it. > # The "myNetData" and "peerAppData" are both created as heap ByteBuffer > instances in the constructor. But if they ever need to be resized it does it > by calling Buffers.expandWriteBufferIfNeeded which will return the original > heap ByteBuffer to the queue of buffers that should always be direct byte > buffers. And now the one used by NioSslEngine will be direct instead of heap. > This will also cause the stats that Buffers has to be wrong because we return > a buffer to it that we did not allocate from it. > # From a performance standpoint, we want to also have the buffer that we > directly write to a socket channel, or fill by reading from a socket channel, > be a direct byte buffer. Other byte buffers should not be direct. So normally > the ByteBuffer we serialize an outgoing message into is a direct ByteBuffer > because it will be handed to the socket channel for the message write. But in > the case of the NioSslEngine we would want that first buffer to be a > non-direct, heap ByteBuffer. It ends up being passed to NioSslEngine.wrap > which copies it into "myNetData". The encrypted data in "myNetData" in turn > is written to the socket channel so it is the one that should be a direct > ByteBuffer. For reading it is just the opposite. We read encrypted data from > the socket channel into what should be direct byte buffer (and it currently > is because it is allocated with Buffers). But then it is passed to > NioSslEngine.unwrap which will copy (and decrypt) what is in it into the > "peerAppData". So "peerAppData" should be kept a heap ByteBuffer. You can > always get away with using either type of ByteBuffer. It is simply a > performance issue. What happens at a lower level in the jdk with a heap > ByteBuffer being used with a socket channel is that it eventually just copies > it into a direct ByteBuffer and then uses it. That extra copy can hurt > performance and in the past we had trouble with the jdk caching of direct > ByteBuffers not reusing as well as ours and running out of direct memory. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7392) Add tag indicating the commit under test to heavy lifters
[ https://issues.apache.org/jira/browse/GEODE-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Goller resolved GEODE-7392. Assignee: Sean Goller Resolution: Fixed > Add tag indicating the commit under test to heavy lifters > - > > Key: GEODE-7392 > URL: https://issues.apache.org/jira/browse/GEODE-7392 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Currently heavy lifter instances are tagged with information about the build > in concourse it was launched by. In order to facilitate forensics from > metrics, tag the instance with the commit under test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7402) running create disk store multiple time resulted in duplicate entries in cluster.xml
Ashish Choudhary created GEODE-7402: --- Summary: running create disk store multiple time resulted in duplicate entries in cluster.xml Key: GEODE-7402 URL: https://issues.apache.org/jira/browse/GEODE-7402 Project: Geode Issue Type: Bug Components: gfsh Reporter: Ashish Choudhary # run gfsh create disk store command # export cluster configuration. no duplicate entry for disk store. # execute step1 again. # execute step2 again. # there are duplicate entry for disk store in cluster.xml It should fail fast if disk store already exists. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7390) Add Micrometer metrics example to geode-examples
[ https://issues.apache.org/jira/browse/GEODE-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7390: - Fix Version/s: 1.11.0 > Add Micrometer metrics example to geode-examples > > > Key: GEODE-7390 > URL: https://issues.apache.org/jira/browse/GEODE-7390 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.11.0 > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Why > We want users of Geode to be able to spin up a Prometheus/Grafana setup along > with a simple meter registry that exposes Prometheus endpoints to be scraped > with all of the meters in the registry. > h3. Acceptance Criteria > Add Micrometer metrics example to geode-examples repository. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7390) Add Micrometer metrics example to geode-examples
[ https://issues.apache.org/jira/browse/GEODE-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-7390. -- Resolution: Done > Add Micrometer metrics example to geode-examples > > > Key: GEODE-7390 > URL: https://issues.apache.org/jira/browse/GEODE-7390 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > h3. Why > We want users of Geode to be able to spin up a Prometheus/Grafana setup along > with a simple meter registry that exposes Prometheus endpoints to be scraped > with all of the meters in the registry. > h3. Acceptance Criteria > Add Micrometer metrics example to geode-examples repository. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7401) Use locator launcher to start a locator in a rule
Jinmei Liao created GEODE-7401: -- Summary: Use locator launcher to start a locator in a rule Key: GEODE-7401 URL: https://issues.apache.org/jira/browse/GEODE-7401 Project: Geode Issue Type: Improvement Components: tests Reporter: Jinmei Liao currently we have LocatorStartupRule that use internal api to create the locator, sometimes the tests needs to get hold of the locatorLauncher to verify certain state, would be nice to have a rule that would start the locator using the locatorLauncher. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7400) Prevent RejectedExecutionException in FederatingManager
[
https://issues.apache.org/jira/browse/GEODE-7400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-7400:
Assignee: Aaron Lindsey
> Prevent RejectedExecutionException in FederatingManager
> ---
>
> Key: GEODE-7400
> URL: https://issues.apache.org/jira/browse/GEODE-7400
> Project: Geode
> Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The fix for GEODE-7330 changed the {{FederatingManager}} class so that it
> reuses the same {{ExecutorService}} between restarts. Now, if we start the
> manager after previously starting and stopping it, we get
> {{RejectedExecutionException}} because it tries to invoke a task on the same
> {{ExecutorService}} which has been shut down.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7390) Add Micrometer metrics example to geode-examples
[ https://issues.apache.org/jira/browse/GEODE-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965000#comment-16965000 ] ASF subversion and git services commented on GEODE-7390: Commit 039f637c9b4e8f1e28d8c49b812aeaa12e0affaa in geode-examples's branch refs/heads/develop from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=039f637 ] GEODE-7390: Add Micrometer metrics example (#90) Add example to demonstrate publishing metrics from Geode to a monitoring system comprised of Prometheus and Grafana. Co-authored-by: Aaron Lindsey Co-authored-by: Dale Emery Co-authored-by: Mark Hanson Co-authored-by: Nick Vallely Authored-by: Aaron Lindsey > Add Micrometer metrics example to geode-examples > > > Key: GEODE-7390 > URL: https://issues.apache.org/jira/browse/GEODE-7390 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > h3. Why > We want users of Geode to be able to spin up a Prometheus/Grafana setup along > with a simple meter registry that exposes Prometheus endpoints to be scraped > with all of the meters in the registry. > h3. Acceptance Criteria > Add Micrometer metrics example to geode-examples repository. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7386) CI failure: JmxCredentialTypeTest > testWithNonStringCredential failed with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964999#comment-16964999
]
Bill Burcham commented on GEODE-7386:
-
failed here too:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/478
> CI failure: JmxCredentialTypeTest > testWithNonStringCredential failed with
> AssertionError
> --
>
> Key: GEODE-7386
> URL: https://issues.apache.org/jira/browse/GEODE-7386
> Project: Geode
> Issue Type: Bug
> Components: jmx, management, security
>Reporter: Barrett Oglesby
>Assignee: Jinmei Liao
>Priority: Major
>
> This test has failed in the last 2 IntegrationTestOpenJDK8 builds:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/1223
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/1224
> {noformat}
> org.apache.geode.management.internal.security.JmxCredentialTypeTest >
> testWithNonStringCredential FAILED
> java.lang.AssertionError:
> Expecting:
> <"Unsupported type: java.lang.Integer">
> to contain:
> <"filter status: REJECTED">
> at
> org.apache.geode.management.internal.security.JmxCredentialTypeTest.testWithNonStringCredential(JmxCredentialTypeTest.java:47)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7384) OldId from the same distributed member should be removed when processing the dm's PrepareNewPersistentMemberMessage
[ https://issues.apache.org/jira/browse/GEODE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-7384. - Fix Version/s: 1.11.0 Resolution: Fixed > OldId from the same distributed member should be removed when processing the > dm's PrepareNewPersistentMemberMessage > --- > > Key: GEODE-7384 > URL: https://issues.apache.org/jira/browse/GEODE-7384 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The old id is being removed only if the PersistenceAdvisorImpl is initialized > when processing the message. However, this could lead to two > PersistentMemberIDs from the same member being persisted and there is no way > that the old id can be removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7384) OldId from the same distributed member should be removed when processing the dm's PrepareNewPersistentMemberMessage
[ https://issues.apache.org/jira/browse/GEODE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-7384: Affects Version/s: 1.1.0 > OldId from the same distributed member should be removed when processing the > dm's PrepareNewPersistentMemberMessage > --- > > Key: GEODE-7384 > URL: https://issues.apache.org/jira/browse/GEODE-7384 > Project: Geode > Issue Type: Bug > Components: persistence >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The old id is being removed only if the PersistenceAdvisorImpl is initialized > when processing the message. However, this could lead to two > PersistentMemberIDs from the same member being persisted and there is no way > that the old id can be removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7400) Prevent RejectedExecutionException in FederatingManager
Aaron Lindsey created GEODE-7400:
Summary: Prevent RejectedExecutionException in FederatingManager
Key: GEODE-7400
URL: https://issues.apache.org/jira/browse/GEODE-7400
Project: Geode
Issue Type: Bug
Reporter: Aaron Lindsey
The fix for GEODE-7330 changed the {{FederatingManager}} class so that it
reuses the same {{ExecutorService}} between restarts. Now, if we start the
manager after previously starting and stopping it, we get
{{RejectedExecutionException}} because it tries to invoke a task on the same
{{ExecutorService}} which has been shut down.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7399) Test functions do not need to use LogService
[ https://issues.apache.org/jira/browse/GEODE-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-7399: - Issue Type: Bug (was: Task) > Test functions do not need to use LogService > > > Key: GEODE-7399 > URL: https://issues.apache.org/jira/browse/GEODE-7399 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Dan Smith >Priority: Major > > We have test functions that use LogService. That's an internal API, these > test functions should use LogManager instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7399) Test functions do not need to use LogService
Dan Smith created GEODE-7399: Summary: Test functions do not need to use LogService Key: GEODE-7399 URL: https://issues.apache.org/jira/browse/GEODE-7399 Project: Geode Issue Type: Task Components: tests Reporter: Dan Smith We have test functions that use LogService. That's an internal API, these test functions should use LogManager instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7256) Dunit Test Failure: alterLogFileSizeLimitTooBig_errorCanNotSet(false) [1]
[
https://issues.apache.org/jira/browse/GEODE-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7256:
--
Assignee: Mark Hanson
> Dunit Test Failure: alterLogFileSizeLimitTooBig_errorCanNotSet(false) [1]
> -
>
> Key: GEODE-7256
> URL: https://issues.apache.org/jira/browse/GEODE-7256
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
>
> It looks like we are not dealing with a reply well. Logs are not conclusive.
> Test run failed
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsGfshDistributedTestOpenJDK11/builds/890]
>
> Logs are at
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-results/distributedTest/1569874663/
>
> {noformat}
> 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 118[fatal 2019/09/30 19:41:11.953 GMT
> tid=2185] Unknown handshake reply code: %s
> nioMessageLength: %s
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:380)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:193)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:148)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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:446)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 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(Method.java:566)
>
[jira] [Commented] (GEODE-7177) Move membership's logging dependencies to its own module
[ https://issues.apache.org/jira/browse/GEODE-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964970#comment-16964970 ] ASF subversion and git services commented on GEODE-7177: Commit c852309ba691458570feeec1aa1877ff4e2b0cd5 in geode's branch refs/heads/develop from Ernie Burghardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c852309 ] GEODE-7177: Adjusted ArchUnit tests to allow geode-logging package s… (#4264) - This is a Mulligan from the geode-logging package move. > Move membership's logging dependencies to its own module > > > Key: GEODE-7177 > URL: https://issues.apache.org/jira/browse/GEODE-7177 > Project: Geode > Issue Type: Improvement > Components: logging, membership >Reporter: Ryan McMahon >Assignee: Dan Smith >Priority: Major > Time Spent: 6.5h > Remaining Estimate: 0h > > As part of eliminating membership's dependency on geode-core, we want to move > LogService and some other supporting classes to its own module which > membership can depend on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7384) OldId from the same distributed member should be removed when processing the dm's PrepareNewPersistentMemberMessage
[ https://issues.apache.org/jira/browse/GEODE-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964959#comment-16964959 ] ASF subversion and git services commented on GEODE-7384: Commit ba21b6345c0e9158549d2958a268d1fc0b7f38f7 in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ba21b63 ] GEODE-7384: Members's old Persistent Member Id should be removed (#4257) * Always remove old Persistent Member Id if persisting its new Id. > OldId from the same distributed member should be removed when processing the > dm's PrepareNewPersistentMemberMessage > --- > > Key: GEODE-7384 > URL: https://issues.apache.org/jira/browse/GEODE-7384 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Time Spent: 0.5h > Remaining Estimate: 0h > > The old id is being removed only if the PersistenceAdvisorImpl is initialized > when processing the message. However, this could lead to two > PersistentMemberIDs from the same member being persisted and there is no way > that the old id can be removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7373) Add restriction to the type of credentials jmx should accept
[ https://issues.apache.org/jira/browse/GEODE-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964953#comment-16964953 ] ASF subversion and git services commented on GEODE-7373: Commit a9e451c5ed3e4f7caa6eba133c60201b2d2fdd98 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a9e451c ] GEODE-7373: add jmx credential type constraint (#4268) > Add restriction to the type of credentials jmx should accept > > > Key: GEODE-7373 > URL: https://issues.apache.org/jira/browse/GEODE-7373 > Project: Geode > Issue Type: Improvement > Components: jmx >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.11.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Jmx credentials should only be in the form of String or String[] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7362) Break dependencies on version class
[ https://issues.apache.org/jira/browse/GEODE-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt updated GEODE-7362: Fix Version/s: 1.11.0 > Break dependencies on version class > --- > > Key: GEODE-7362 > URL: https://issues.apache.org/jira/browse/GEODE-7362 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Ernest Burghardt >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.11.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7348) Break dependencies on "god" classes
[ https://issues.apache.org/jira/browse/GEODE-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt updated GEODE-7348: Fix Version/s: 1.11.0 > Break dependencies on "god" classes > --- > > Key: GEODE-7348 > URL: https://issues.apache.org/jira/browse/GEODE-7348 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Ernest Burghardt >Priority: Major > Fix For: 1.11.0 > > Time Spent: 40m > Remaining Estimate: 0h > > DistributedSystem > InternalConfigurationPersistenceService > GemFireCache > InternalLocator > InternalCache > InternalDistributedSystem > SystemFailure -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7358) Membership code should use InternalDistributedMember as the membership identifier
[ https://issues.apache.org/jira/browse/GEODE-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-7358. - Fix Version/s: 1.11.0 Resolution: Fixed > Membership code should use InternalDistributedMember as the membership > identifier > - > > Key: GEODE-7358 > URL: https://issues.apache.org/jira/browse/GEODE-7358 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.11.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > In 1.10 we used InternalDistributedMember as a membership identifier in > membership code. Since then we have moved to using GMSMember as the > identifier. We should instead provide an interface in membership code that > InternalDistributedMember can implement and we should use this interface in > membership code. This will provide more flexibility in membership code for > supporting arbitrary additional data required to identify a member. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7379) Break dependencies on CancelException class
[
https://issues.apache.org/jira/browse/GEODE-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt resolved GEODE-7379.
-
Fix Version/s: 1.11.0
Resolution: Fixed
> Break dependencies on CancelException class
> ---
>
> Key: GEODE-7379
> URL: https://issues.apache.org/jira/browse/GEODE-7379
> Project: Geode
> Issue Type: Sub-task
> Components: membership
>Reporter: Bill Burcham
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> eliminate this rule in {{TcpServerDependenciesTest}}
> {code}
> // TODO - cancel excpetion
> .or(type(CancelException.class))
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7396) JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes
[
https://issues.apache.org/jira/browse/GEODE-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-7396.
Fix Version/s: 1.11.0
Resolution: Fixed
> JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes
> --
>
> Key: GEODE-7396
> URL: https://issues.apache.org/jira/browse/GEODE-7396
> Project: Geode
> Issue Type: Bug
> Components: querying, security
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.11.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The following test failed using an authorizer with java.lang and java.io
> packages specified as allowed. It's unclear at this time if the problem is
> related specifically to the java.io package or if it is a problem with how
> the JavaBeanAccessorMethodAuthorizer handles multiple parameters.
> {noformat}
> @Test
> public void test() throws NoSuchMethodException {
> Method disallowedJavaIOMethod = File.class.getMethod("getPath");
>
> assertThat(authorizerWithStringAndIOPackageSpecified.authorize(allowedJavaIOMethod,
> new File(""))).isTrue();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7396) JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes
[
https://issues.apache.org/jira/browse/GEODE-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964887#comment-16964887
]
ASF subversion and git services commented on GEODE-7396:
Commit d7efa93f8d66626d43109de8be9077102ad9e82d in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d7efa93 ]
GEODE-7396: Fixed incorrect regex in JavaBeanAccessorMethodAuthorizer (#4263)
Authored-by: Donal Evans
> JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes
> --
>
> Key: GEODE-7396
> URL: https://issues.apache.org/jira/browse/GEODE-7396
> Project: Geode
> Issue Type: Bug
> Components: querying, security
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The following test failed using an authorizer with java.lang and java.io
> packages specified as allowed. It's unclear at this time if the problem is
> related specifically to the java.io package or if it is a problem with how
> the JavaBeanAccessorMethodAuthorizer handles multiple parameters.
> {noformat}
> @Test
> public void test() throws NoSuchMethodException {
> Method disallowedJavaIOMethod = File.class.getMethod("getPath");
>
> assertThat(authorizerWithStringAndIOPackageSpecified.authorize(allowedJavaIOMethod,
> new File(""))).isTrue();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
