[jira] [Commented] (GEODE-7665) Ability to clear a Partitioned Region
[ https://issues.apache.org/jira/browse/GEODE-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044289#comment-17044289 ] Mario Kevo commented on GEODE-7665: --- Hi, What is the status of this feature? Does anyone working on it? If yes, do you have some estimation when it will be finished? Thanks, Mario > Ability to clear a Partitioned Region > - > > Key: GEODE-7665 > URL: https://issues.apache.org/jira/browse/GEODE-7665 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > > With the successful voting of the RFC for implementing clear operation on > Partitioned Region > [[https://cwiki.apache.org/confluence/display/GEODE/Support+for+clear+operation+on+partitioned+region]] > we are starting the code implementation. > > Details of the implementation and design are maintained in the RFC document > mentioned above. This ticket will act as a parent Jira under which all the > subsequent sub-JIRAs will be created. This ticket will be closed once all the > sub jiras are implemented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7814) Unnecessary Object AllocationsIntroduced in GEODE-7507
Juan Ramos created GEODE-7814:
-
Summary: Unnecessary Object AllocationsIntroduced in GEODE-7507
Key: GEODE-7814
URL: https://issues.apache.org/jira/browse/GEODE-7814
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Juan Ramos
The {{DistributionMessage}} class unnecessary allocates instances of
{{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
These attributes are {{final}} and only used to execute internal comparisons
but, since they are not declared as {{static}}, every instance of
{{DistributionMessage}} will have its own instance, generating unnecessary
garbage.
Using one of our internal testing scenarios and a java profiler we detected
that we create 0 instances of {{java.util.Collection$SingletonList}} and
{{InternalDistributedMember[]}} using Geode 1.10, but 14.824 and 11.212
respectively when using the latest {{develop}} branch.
The increase in the memory footprint is not much (around 1MB all together), and
the time spent on this operation is around 1.5 seconds slower overall
(screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7814) Unnecessary Object AllocationsIntroduced in GEODE-7507
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos reassigned GEODE-7814:
-
Assignee: Juan Ramos
> Unnecessary Object AllocationsIntroduced in GEODE-7507
> --
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that we create 0 instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} using Geode 1.10, but 14.824 and 11.212
> respectively when using the latest {{develop}} branch.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7814) Unnecessary Object AllocationsIntroduced in GEODE-7507
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7814:
--
Labels: GeodeCommons (was: )
> Unnecessary Object AllocationsIntroduced in GEODE-7507
> --
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that we create 0 instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} using Geode 1.10, but 14.824 and 11.212
> respectively when using the latest {{develop}} branch.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7814) Unnecessary Object AllocationsIntroduced in GEODE-7507
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7814:
--
Attachment: timeSpent.png
countDifference.png
> Unnecessary Object AllocationsIntroduced in GEODE-7507
> --
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Attachments: countDifference.png, timeSpent.png
>
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that we create 0 instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} using Geode 1.10, but 14.824 and 11.212
> respectively when using the latest {{develop}} branch.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7814:
--
Summary: Unnecessary Object Allocations in DistributionMessage (was:
Unnecessary Object AllocationsIntroduced in GEODE-7507)
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Attachments: countDifference.png, timeSpent.png
>
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that we create 0 instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} using Geode 1.10, but 14.824 and 11.212
> respectively when using the latest {{develop}} branch.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044678#comment-17044678
]
Darrel Schneider commented on GEODE-6008:
-
I reopened this because CI found another suspect string in this test. See:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1592
{noformat}
org.apache.geode.cache.client.internal.ClientServerHostNameVerificationDistributedTest
> expectConnectionFailureWhenNoHostNameInServerKey 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 4270
[fatal 2020/02/25 02:22:55.435 GMT tid=190] Uncaught
exception in thread Thread[unused p2p reader,5,RMI Runtime]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.2(server-3:212):41003 started at Tue Feb
25 02:22:48 GMT 2020: Message distribution has terminated
at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2874)
at
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:986)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1690)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1472)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
> failed
> ---
>
> Key: GEODE-6008
> URL: https://issues.apache.org/jira/browse/GEODE-6008
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> {noformat}
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1872
> y: java.security.cert.CertificateException: No name matching 88deff82cd47
> found
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:412)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:172)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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
[jira] [Assigned] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-6008:
---
Assignee: Bruce J Schuchardt
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
> failed
> ---
>
> Key: GEODE-6008
> URL: https://issues.apache.org/jira/browse/GEODE-6008
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> {noformat}
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1872
> y: java.security.cert.CertificateException: No name matching 88deff82cd47
> found
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:412)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:172)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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:117)
> 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.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:155)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:137)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
> at
> org.gradle.internal.concurrent.
[jira] [Commented] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044681#comment-17044681
]
Mark Hanson commented on GEODE-6008:
org.apache.geode.cache.client.internal.ClientServerHostNameVerificationDistributedTest
> expectConnectionFailureWhenNoHostNameInServerKey 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 4270
[fatal 2020/02/25 02:22:55.435 GMT tid=190] Uncaught
exception in thread Thread[unused p2p reader,5,RMI Runtime]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.2(server-3:212):41003 started at Tue Feb
25 02:22:48 GMT 2020: Message distribution has terminated
at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2874)
at
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:986)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1690)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1472)
at java.lang.Thread.run(Thread.java:748)
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
> failed
> ---
>
> Key: GEODE-6008
> URL: https://issues.apache.org/jira/browse/GEODE-6008
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> {noformat}
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1872
> y: java.security.cert.CertificateException: No name matching 88deff82cd47
> found
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:412)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:172)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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.dis
[jira] [Commented] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044683#comment-17044683
]
Mark Hanson commented on GEODE-6008:
Another failure.
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1592
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0040/test-results/distributedTest/1582600292/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0040/test-artifacts/1582600292/distributedtestfiles-OpenJDK8-1.13.0-SNAPSHOT.0040.tgz
{noformat}
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
> failed
> ---
>
> Key: GEODE-6008
> URL: https://issues.apache.org/jira/browse/GEODE-6008
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> {noformat}
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1872
> y: java.security.cert.CertificateException: No name matching 88deff82cd47
> found
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:412)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:172)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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:117)
> 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.i
[jira] [Updated] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-6008:
---
Labels: flaky pull-request-available (was: pull-request-available)
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
> failed
> ---
>
> Key: GEODE-6008
> URL: https://issues.apache.org/jira/browse/GEODE-6008
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> {noformat}
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1872
> y: java.security.cert.CertificateException: No name matching 88deff82cd47
> found
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:412)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:172)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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:117)
> 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.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:155)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:137)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
> at
> or
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum commented on GEODE-7763:
--
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1648)
at
org
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 5:35 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Issue Comment Deleted] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-6008:
---
Comment: was deleted
(was:
org.apache.geode.cache.client.internal.ClientServerHostNameVerificationDistributedTest
> expectConnectionFailureWhenNoHostNameInServerKey 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 4270
[fatal 2020/02/25 02:22:55.435 GMT tid=190] Uncaught
exception in thread Thread[unused p2p reader,5,RMI Runtime]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.2(server-3:212):41003 started at Tue Feb
25 02:22:48 GMT 2020: Message distribution has terminated
at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2874)
at
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:986)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1690)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1472)
at java.lang.Thread.run(Thread.java:748))
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
> failed
> ---
>
> Key: GEODE-6008
> URL: https://issues.apache.org/jira/browse/GEODE-6008
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> {noformat}
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1872
> y: java.security.cert.CertificateException: No name matching 88deff82cd47
> found
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:412)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:172)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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.ProxyDispat
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 5:36 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Created] (GEODE-7815) Document setting a GEODE_HOME env variable
Karen Smoler Miller created GEODE-7815: -- Summary: Document setting a GEODE_HOME env variable Key: GEODE-7815 URL: https://issues.apache.org/jira/browse/GEODE-7815 Project: Geode Issue Type: Improvement Components: docs Reporter: Karen Smoler Miller While internal methods will check the classpath for locating WAR files, we should document that setting a GEODE_HOME environment variable might an easier method for some installations than changing the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7604) QueryConfigurationServiceConstraintsDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044712#comment-17044712
]
Mark Hanson commented on GEODE-7604:
More failures.
cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(regionShortcut=REPLICATE,
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/686
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/622
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/588
cqsShouldFailDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsNotAllowedByTheNewAuthorizer(regionShortcut=REPLICATE,
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/745
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/744
> QueryConfigurationServiceConstraintsDistributedTest
> ---
>
> Key: GEODE-7604
> URL: https://issues.apache.org/jira/browse/GEODE-7604
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> QueryConfigurationServiceConstraintsDistributedTest had two failures in the
> mass test run...
> [2]
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2252
> [6]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2211]
>
> {noformat}
> 01:28:56org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [2]
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:CREATE,ExecuteWithInitialResults:true)
> FAILED
> 01:28:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$57/2082907347.run
> in VM 2 running on Host 8cbcba2ac2b2 with 4 VMs
> 01:28:56at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 01:28:56at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 01:28:56at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:260)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> expected:<[7]> but was:<[4]> within 300 seconds.
> 01:28:56at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 01:28:56at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 01:28:56at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$868d1d80$1(QueryConfigurationServiceConstraintsDistributedTest.java:264)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.junit.ComparisonFailure: expected:<[7]> but was:<[4]>
> 01:28:56at
> sun.reflect.GeneratedConstructorAccessor207.newInstance(Unknown Source)
> 01:28:56at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$null$13(QueryConfigurationServiceConstraintsDistributedTest.java:266)
> 02:03:51
> 02:03:51679 tests completed, 1 failed, 39 skipped {
[jira] [Commented] (GEODE-7604) QueryConfigurationServiceConstraintsDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044713#comment-17044713
]
Mark Hanson commented on GEODE-7604:
Both of the failing tests seem to have a timing issue. Adding a
Thread.sleep(2000) seems to make the tests run fine if added to the controller
thread after createClientCq. I am not sure what this is helping by adding the
sleep. Which is just a number I picked. I think it might be better for Juan to
take a look at this as the originator of the tests.
> QueryConfigurationServiceConstraintsDistributedTest
> ---
>
> Key: GEODE-7604
> URL: https://issues.apache.org/jira/browse/GEODE-7604
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> QueryConfigurationServiceConstraintsDistributedTest had two failures in the
> mass test run...
> [2]
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2252
> [6]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2211]
>
> {noformat}
> 01:28:56org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [2]
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:CREATE,ExecuteWithInitialResults:true)
> FAILED
> 01:28:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$57/2082907347.run
> in VM 2 running on Host 8cbcba2ac2b2 with 4 VMs
> 01:28:56at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 01:28:56at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 01:28:56at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:260)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> expected:<[7]> but was:<[4]> within 300 seconds.
> 01:28:56at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 01:28:56at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 01:28:56at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$868d1d80$1(QueryConfigurationServiceConstraintsDistributedTest.java:264)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.junit.ComparisonFailure: expected:<[7]> but was:<[4]>
> 01:28:56at
> sun.reflect.GeneratedConstructorAccessor207.newInstance(Unknown Source)
> 01:28:56at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$null$13(QueryConfigurationServiceConstraintsDistributedTest.java:266)
> 02:03:51
> 02:03:51679 tests completed, 1 failed, 39 skipped {noformat}
>
>
> {noformat}
> 07:59:46org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [6]
> cqsShouldFailDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsNotAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY,ExecuteWithInitialResults:true)
> FAILED
> 07:59:46org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$33/1244479648.run
> in VM 2 running on Host 4f921f4602aa with 4 VMs
> 07:59:46
[jira] [Commented] (GEODE-7806) CI Failure: org.apache.geode.cache.client.internal.CacheServerSSLConnectionDUnitTest > testCacheServerSSL[1] FAILED
[ https://issues.apache.org/jira/browse/GEODE-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044731#comment-17044731 ] Bruce J Schuchardt commented on GEODE-7806: --- Also see GEODE-6008, which hit this same suspect string > CI Failure: > org.apache.geode.cache.client.internal.CacheServerSSLConnectionDUnitTest > > testCacheServerSSL[1] FAILED > --- > > Key: GEODE-7806 > URL: https://issues.apache.org/jira/browse/GEODE-7806 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Anilkumar Gingade >Priority: Major > > org.apache.geode.cache.client.internal.CacheServerSSLConnectionDUnitTest > > testCacheServerSSL[1] 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 2337 > [fatal 2020/02/18 22:01:03.293 GMT tid=178] Uncaught > exception in thread Thread[unused p2p reader,5,main] > org.apache.geode.distributed.DistributedSystemDisconnectedException: > Distribution manager on 172.17.0.19(1:locator):41001 started at Tue > Feb 18 22:00:52 GMT 2020: Message distribution has terminated > at > org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2874) > at > org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:986) > at > org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83) > at > org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1690) > at org.apache.geode.internal.tcp.Connection.run(Connection.java:1472) > at java.base/java.lang.Thread.run(Thread.java:834) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044732#comment-17044732
]
Bruce J Schuchardt commented on GEODE-6008:
---
Also see GEODE-7806, which hit this same suspect string
{noformat}
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.2(server-3:212):41003 started at Tue Feb
25 02:22:48 GMT 2020: Message distribution has terminated
at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2874)
at
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:986)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1690)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1472)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
> failed
> ---
>
> Key: GEODE-6008
> URL: https://issues.apache.org/jira/browse/GEODE-6008
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> {noformat}
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1872
> y: java.security.cert.CertificateException: No name matching 88deff82cd47
> found
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:412)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:172)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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:117)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMet
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:43 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:45 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:45 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:46 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:49 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:49 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:51 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:51 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 6:52 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 7:00 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Assigned] (GEODE-7712) LocatorUDPSecurityDUnitTest has mass test failures
[
https://issues.apache.org/jira/browse/GEODE-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7712:
--
Assignee: (was: Mark Hanson)
> LocatorUDPSecurityDUnitTest has mass test failures
> --
>
> Key: GEODE-7712
> URL: https://issues.apache.org/jira/browse/GEODE-7712
> Project: Geode
> Issue Type: Bug
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> The following test failed in a mass test run.
>
> {noformat}
> testRestartLocatorMultipleTimes
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2944
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/mhansonp-mhanson-mass-test-ru-main/1.12.0-SNAPSHOT.0001/test-results/distributedTest/1579148824/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/mhansonp-mhanson-mass-test-ru-main/1.12.0-SNAPSHOT.0001/test-artifacts/1579148824/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0001.tgz
> {noformat}
>
> {noformat}
> testForceDisconnectAndPeerShutdownCause
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2970
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/mhansonp-mhanson-mass-test-ru-main/1.12.0-SNAPSHOT.0001/test-results/distributedTest/1579188277/
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/mhansonp-mhanson-mass-test-ru-main/1.12.0-SNAPSHOT.0001/test-artifacts/1579188277/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0001.tgz{noformat}
>
> {noformat}
> testStartTwoLocators
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2961
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/mhansonp-mhanson-mass-test-ru-main/1.12.0-SNAPSHOT.0001/test-results/distributedTest/1579172593/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/mhansonp-mhanson-mass-test-ru-main/1.12.0-SNAPSHOT.0001/test-artifacts/1579172593/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0001.tgz
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7604) QueryConfigurationServiceConstraintsDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7604:
--
Assignee: Juan Ramos (was: Mark Hanson)
> QueryConfigurationServiceConstraintsDistributedTest
> ---
>
> Key: GEODE-7604
> URL: https://issues.apache.org/jira/browse/GEODE-7604
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Juan Ramos
>Priority: Major
> Labels: flaky
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> QueryConfigurationServiceConstraintsDistributedTest had two failures in the
> mass test run...
> [2]
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2252
> [6]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2211]
>
> {noformat}
> 01:28:56org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [2]
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:CREATE,ExecuteWithInitialResults:true)
> FAILED
> 01:28:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$57/2082907347.run
> in VM 2 running on Host 8cbcba2ac2b2 with 4 VMs
> 01:28:56at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 01:28:56at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 01:28:56at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:260)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> expected:<[7]> but was:<[4]> within 300 seconds.
> 01:28:56at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 01:28:56at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 01:28:56at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$868d1d80$1(QueryConfigurationServiceConstraintsDistributedTest.java:264)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.junit.ComparisonFailure: expected:<[7]> but was:<[4]>
> 01:28:56at
> sun.reflect.GeneratedConstructorAccessor207.newInstance(Unknown Source)
> 01:28:56at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$null$13(QueryConfigurationServiceConstraintsDistributedTest.java:266)
> 02:03:51
> 02:03:51679 tests completed, 1 failed, 39 skipped {noformat}
>
>
> {noformat}
> 07:59:46org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [6]
> cqsShouldFailDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsNotAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY,ExecuteWithInitialResults:true)
> FAILED
> 07:59:46org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$33/1244479648.run
> in VM 2 running on Host 4f921f4602aa with 4 VMs
> 07:59:46at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 07:59:46at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 07:59:46at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 07:59:46at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsS
[jira] [Updated] (GEODE-7604) QueryConfigurationServiceConstraintsDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7604:
---
Labels: (was: flaky)
> QueryConfigurationServiceConstraintsDistributedTest
> ---
>
> Key: GEODE-7604
> URL: https://issues.apache.org/jira/browse/GEODE-7604
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Juan Ramos
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> QueryConfigurationServiceConstraintsDistributedTest had two failures in the
> mass test run...
> [2]
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2252
> [6]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2211]
>
> {noformat}
> 01:28:56org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [2]
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:CREATE,ExecuteWithInitialResults:true)
> FAILED
> 01:28:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$57/2082907347.run
> in VM 2 running on Host 8cbcba2ac2b2 with 4 VMs
> 01:28:56at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 01:28:56at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 01:28:56at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:260)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> expected:<[7]> but was:<[4]> within 300 seconds.
> 01:28:56at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 01:28:56at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 01:28:56at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$868d1d80$1(QueryConfigurationServiceConstraintsDistributedTest.java:264)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.junit.ComparisonFailure: expected:<[7]> but was:<[4]>
> 01:28:56at
> sun.reflect.GeneratedConstructorAccessor207.newInstance(Unknown Source)
> 01:28:56at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$null$13(QueryConfigurationServiceConstraintsDistributedTest.java:266)
> 02:03:51
> 02:03:51679 tests completed, 1 failed, 39 skipped {noformat}
>
>
> {noformat}
> 07:59:46org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [6]
> cqsShouldFailDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsNotAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY,ExecuteWithInitialResults:true)
> FAILED
> 07:59:46org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$33/1244479648.run
> in VM 2 running on Host 4f921f4602aa with 4 VMs
> 07:59:46at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 07:59:46at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 07:59:46at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 07:59:46at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldFailDuringEventProcessingAfterRegionOperationWhen
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 8:01 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 8:02 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044687#comment-17044687
]
John Blum edited comment on GEODE-7763 at 2/25/20 8:04 PM:
---
I am currently reviewing the analysis and comments on this ticket.
I observed a few discrepancies in the comments.
First, is a statement made in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039238&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039238]
referring to a "{{put}}" by the {{SessionEventHandlerCacheListenerAdapter}}:
{quote}The second during the put in the SessionEventHandlerCacheListenerAdapter
here:{quote}
Citing this _Stack Trace_:
{code:java}
2020-02-12 14:46:34,381 WARN
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession
[Session Thread 10] XXX DeltaCapableGemFireSession instantiated
java.lang.Exception: null
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession.(AbstractGemFireOperationsSessionRepository.java:704)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.copy(AbstractGemFireOperationsSessionRepository.java:772)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.from(AbstractGemFireOperationsSessionRepository.java:787)
at
org.springframework.session.data.gemfire.serialization.data.provider.DataSerializableSessionSerializer.deserialize(DataSerializableSessionSerializer.java:122)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:474)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.deserialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.fromData(AbstractDataSerializableSessionSerializer.java:107)
at
org.apache.geode.internal.InternalDataSerializer.readUserObject(InternalDataSerializer.java:1786)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2878)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:242)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:1063)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.isSession(AbstractGemFireOperationsSessionRepository.java:1732)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.remember(AbstractGemFireOperationsSessionRepository.java:1699)
at java.util.Optional.filter(Optional.java:178)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$SessionEventHandlerCacheListenerAdapter.afterCreate(AbstractGemFireOperationsSessionRepository.java:1481)
at
org.apache.geode.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:130)
at
org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8485)
at
org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7049)
at
org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6013)
at
org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2402)
at
org.apache.geode.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:615)
at
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5869)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:244)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5691)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5119)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1661)
at
org.apache.geode.internal.cache.Loca
[jira] [Created] (GEODE-7816) Enable SSL for Redis API
Murtuza Boxwala created GEODE-7816: -- Summary: Enable SSL for Redis API Key: GEODE-7816 URL: https://issues.apache.org/jira/browse/GEODE-7816 Project: Geode Issue Type: Improvement Components: redis Reporter: Murtuza Boxwala When SSL is enabled for the "server" component Then the Redis API should also be SSL enabled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044828#comment-17044828
]
John Blum commented on GEODE-7763:
--
Regarding this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039240&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039240]...
What in Geode causes a {{Region.get(..)}} to lead back to a serialization with
{{DataSerializer.toData(..)}} ???
{code:java}
...
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.toData(AbstractDataSerializableSessionSerializer.java:90)
at
org.apache.geode.internal.InternalDataSerializer.writeUserObject(InternalDataSerializer.java:1625)
at
org.apache.geode.internal.InternalDataSerializer.writeWellKnownObject(InternalDataSerializer.java:1587)
at
org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2238)
at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2953)
at org.apache.geode.CopyHelper.doDeepCopy(CopyHelper.java:241)
at org.apache.geode.CopyHelper.copy(CopyHelper.java:190)
at
org.apache.geode.internal.cache.LocalRegion.conditionalCopy(LocalRegion.java:1606)
at
org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1519)
at
org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:188)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1443)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1377)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1362)
at
org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:416)
...
{code}
This seems rather odd to me.
Also, you should *not* take all these additional
{{[[DeltaCapable]GemFire]Session}} object creations de/serializations to mean
this is what SSDG does in practice (i.e. in production code)!
Some of these object creations & de/serializations is triggered by the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class itself, to assert "specific conditions" are in fact in effect in
order for certain downstream operations (e.g. a {{save}}) to happen correctly.
1 instance is the superfluous {{hasDelta}}
[call|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L399]
in the {{SpyingDataSerializableSessionSerializer}} implementation itself,
which is only a implementation used by the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class.
Given [GEODE-6032], we certainly do *NOT* want the Session object to be
serialized in its entirety, again and again (over and over), if the Session
object truly is NOT dirty (i.e. {{Session.hasDelta()}} returns *false*). If
{{save}} is called on a non-dirty Session object, then data is bound to be
lost, especially in a highly-concurrent Web/Servlet context, and definitely if
Deltas are not used (!), hence this
[condition|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/main/java/org/springframework/session/data/gemfire/GemFireOperationsSessionRepository.java#L185].
It also means, the Session object, {{hasDelta()}} method must be properly
*synchronized* since 1) it is a compound action and 2) because multiple HTTP
requests (processed by separate Threads) may in fact be accessing the same
exact (i.e. same Object), or "logically" identical Session object. In the
"logical" case, this is exactly why Deltas are important!
Anyway, again there are other situations, or conditions, where the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class may be causing additional Session object creations due to
de/serializations, which are necessary to make appropriate assertions with
regards to expectations in behavior of SSDG. All of the synchronizations in
SSDG were carefully crafted with intent.
In summary for this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039240&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039240],
I have already taken steps to reduce the de/serializations, and subsequent
Session object creations, in the {{SessionEventHandlerCacheListenerAdapter}}
class by ignoring {{LOCAL_LOAD_CREATE}} EntryEvents.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
>
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044830#comment-17044830
]
John Blum commented on GEODE-7763:
--
The {{FastLogger.isTraceEnabled()}} observation in this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039242&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039242]
is a nice find!
Logging definitely has an impact on performance.
It is surprising though that a log-level check method (i.e.
{{isTraceEnabled()}}) would be that expensive? The log-level check methods
were put into place to avoid the more costly log operation (e.g. {{trace(..)}})
at that particular log-level (i.e. {{TRACE}}) in the first place.
Of course, in all fairness, in my test, logging was not enabled to begin with.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044838#comment-17044838
]
John Blum commented on GEODE-7763:
--
Regarding this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039243]...
If I am not mistaken, this only affects the server-side for "other" interested
clients.
So long as it does not affect the {{SessionEventHandlerCacheListenerAdapter}}
logic on the client-side of the originator, I am fine with it. Again, this
{{CacheListener}} implementation must be invoked by the client even if that
client was the 1 to initiate the Session changes (creation, update, deletion,
expiration, invalidation) to begin with.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
>
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044838#comment-17044838
]
John Blum edited comment on GEODE-7763 at 2/25/20 8:50 PM:
---
Regarding this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039243]...
If I am not mistaken, this only affects the server-side for "other" interested
clients.
So long as it does not affect the {{SessionEventHandlerCacheListenerAdapter}}
logic on the client-side of the originator, I am fine with it. Again, this
{{CacheListener}} implementation must be invoked by the client even if that
client was the 1 to initiate the Session changes (creation, update, deletion,
expiration, invalidation) to begin with.
This is for the intended purpose of translating cache Session Region
EntryEvents to {{ApplicationEvents}} for interested {{ApplicationListeners}} or
other _Spring_ beans annotated with the {{@EventListener}} annotation.
was (Author: jblum):
Regarding this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039243]...
If I am not mistaken, this only affects the server-side for "other" interested
clients.
So long as it does not affect the {{SessionEventHandlerCacheListenerAdapter}}
logic on the client-side of the originator, I am fine with it. Again, this
{{CacheListener}} implementation must be invoked by the client even if that
client was the 1 to initiate the Session changes (creation, update, deletion,
expiration, invalidation) to begin with.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the G
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044844#comment-17044844
]
John Blum commented on GEODE-7763:
--
Regarding this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039245&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039245]...
The important part of [GEODE-6152] is that a client {{PROXY}} Region should
never return a reference to the same object in memory, i.e. it should honor its
[contract|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientRegionShortcut.html#PROXY].
However, that is accomplished, whether a client {{PROXY}} Region {{get(..)}}
results in calling the server-side Region each time, or a copy is made on the
client so that separate Threads making identical requests to the same "logical"
object gets a unique reference, matters little.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerH
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044850#comment-17044850
]
John Blum commented on GEODE-7763:
--
Regarding this
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039247&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039247]...
While a nice observation, this call:
{code:java}
"ServerConnection on port 49245 Thread 194" #256 daemon prio=5 os_prio=31
tid=0x7fe692082000 nid=0x1c607 waiting for monitor entry
[0x7baac000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.hasDelta(AbstractGemFireOperationsSessionRepository.java:932)
- waiting to lock <0x0007425d11b0> (a
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.serialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:466)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.serialize(MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java:439)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.lambda$toData$0(AbstractDataSerializableSessionSerializer.java:91)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer$$Lambda$596/1792537377.apply(Unknown
Source)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer.toData(AbstractDataSerializableSessionSerializer.java:90)
at
org.apache.geode.internal.InternalDataSerializer.writeUserObject(InternalDataSerializer.java:1564)
at
org.apache.geode.internal.InternalDataSerializer.writeWellKnownObject(InternalDataSerializer.java:1526)
at
org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2105)
at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
at
org.apache.geode.internal.util.BlobHelper.serializeTo(BlobHelper.java:66)
at
org.apache.geode.internal.cache.tier.sockets.Message.serializeAndAddPart(Message.java:406)
at
org.apache.geode.internal.cache.tier.sockets.Message.addPartInAnyForm(Message.java:369)
at
org.apache.geode.internal.cache.tier.sockets.command.Get70.writeResponse(Get70.java:426)
at
org.apache.geode.internal.cache.tier.sockets.command.Get70.cmdExecute(Get70.java:207)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
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:675)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$539/1077688833.invoke(Unknown
Source)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$240/2081964843.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:745)
{code}
And in particular:
{code:java}
"ServerConnection on port 49245 Thread 194" #256 daemon prio=5 os_prio=31
tid=0x7fe692082000 nid=0x1c607 waiting for monitor entry
[0x7baac000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.hasDelta(AbstractGemFireOperationsSessionRepository.java:932)
- waiting to lock <0x0007425d11b0> (a
org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$DeltaCapableGemFireSession)
at
org.springframework.session.data.gemfire.MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests$SpyingDataSerializableSessionSerializer.serialize(MultiT
[jira] [Commented] (GEODE-7798) CI: org.apache.geode.redis.PubSubTest failed intermittently on Windows
[ https://issues.apache.org/jira/browse/GEODE-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044852#comment-17044852 ] ASF subversion and git services commented on GEODE-7798: Commit 0f9bbf023df2b97ff54d9053cf41be57b1964203 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f9bbf0 ] GEODE-7798: Fix flakiness in PubSubTest (#4717) - Remove flusher execution in favor of just calling writeAndFlush - Bump Netty to 4.1.45 - Correct message depending on type of subscription processing a PUBLISH > CI: org.apache.geode.redis.PubSubTest failed intermittently on Windows > > > Key: GEODE-7798 > URL: https://issues.apache.org/jira/browse/GEODE-7798 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jens Deppe >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1240 > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1242 > org.apache.geode.redis.PubSubTest > testTwoSubscribersOneChannel FAILED > org.junit.ComparisonFailure: expected:<[2]L> but was:<[1]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testTwoSubscribersOneChannel(PubSubTest.java:163) > org.apache.geode.redis.PubSubTest > testOneSubscriberSubscribingToTwoChannels > FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testOneSubscriberSubscribingToTwoChannels(PubSubTest.java:124) > org.apache.geode.redis.PubSubTest > testDeadSubscriber FAILED > org.junit.ComparisonFailure: expected:<[0]L> but was:<[2]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testDeadSubscriber(PubSubTest.java:250) > org.apache.geode.redis.PubSubTest > testOneSubscriberOneChannelTwoTimes FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[3]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testOneSubscriberOneChannelTwoTimes(PubSubTest.java:210) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:11 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
access from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside a multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
access from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> ---
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum commented on GEODE-7763:
--
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside a multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
access from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test c
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:12 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
access from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> ---
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:13 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications) and even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications) and even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resou
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:13 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications) and even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> -
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:13 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications) and even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and r
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:14 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, it would be extremely bad if the Session object
itself changed while being serialized, which is why the GemFire {{Session}} and
{{SessionAttibute}} object implementations in SSDG were carefully crafted with
intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:15 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, it would be extremely bad if the Session object
itself changed while being serialized, which is why the GemFire {{Session}} and
{{SessionAttibute}} object implementations in SSDG were carefully crafted with
intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true*.
Technically, it should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, it would be extremely bad if the Session object
itself changed while being serialized, which is why the GemFire {{Session}} and
{{SessionAttibute}} object implementations in SSDG were carefully crafted with
intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts perfor
[jira] [Commented] (GEODE-7813) add Build-Java-Vendor to gfsh version --full
[ https://issues.apache.org/jira/browse/GEODE-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044938#comment-17044938 ] ASF subversion and git services commented on GEODE-7813: Commit 6f5ebefe800c5b29570eedc47dfe26a79e60158f in geode's branch refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6f5ebef ] GEODE-7813: add Build-Java-Vendor to gfsh version --full (#4729) > add Build-Java-Vendor to gfsh version --full > > > Key: GEODE-7813 > URL: https://issues.apache.org/jira/browse/GEODE-7813 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The version info already includes the version of the compiler in > Build-Java-Version. As there are now several java compiler vendors and a > multitude of ways Geode may get compiled (various pipeline jobs, by a release > manager, by users, etc) it makes sense to record the provider of that javac > version as well. This is also required to audit that only open-source tools > are being used to produce Geode artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7803) provide a way to create an internal region without using deprecated classes
[ https://issues.apache.org/jira/browse/GEODE-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044937#comment-17044937 ] ASF subversion and git services commented on GEODE-7803: Commit 4f3a001ff9a886981246d5a91c1a6a22b037337e in geode's branch refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f3a001 ] GEODE-7803: provide undeprecated internal region create (#4722) You can now use InternalRegionFactory to create a region configured with InternalRegionArguments. No need to use the deprecated AttributesFactory. InternalRegionFactory used to be named RegionFactoryImpl. > provide a way to create an internal region without using deprecated classes > --- > > Key: GEODE-7803 > URL: https://issues.apache.org/jira/browse/GEODE-7803 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently geode has some places that create internal regions (using > InternalRegionArguments) that use deprecated classes to do this. It would be > nice if an internal way was provided to do this that was not deprecated. > GEODE-7799 is doing this. Once that fix is merged in then the > RegionFactoryImpl enhancement it add could be used in the places that use > deprecated apis to specify InternalRegionArguments -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7810) Cannot form connection to alert listener should be logged at WARNING level
[
https://issues.apache.org/jira/browse/GEODE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044936#comment-17044936
]
ASF subversion and git services commented on GEODE-7810:
Commit 25cf22e273e9e017446b879204b470f202fa87e3 in geode's branch
refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging
from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=25cf22e ]
GEODE-7810: Change alert listener connection warning from fatal
> Cannot form connection to alert listener should be logged at WARNING level
> --
>
> Key: GEODE-7810
> URL: https://issues.apache.org/jira/browse/GEODE-7810
> Project: Geode
> Issue Type: Bug
> Components: logging, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Cannot form connection to alert listener log message is currently being
> logged at FATAL level. This should be logged as a WARNING (or ERROR) instead.
> {noformat}
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.7(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:998)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:567)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:782)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:545)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:334)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2061)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1988)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2025)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1085)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:92)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7798) CI: org.apache.geode.redis.PubSubTest failed intermittently on Windows
[ https://issues.apache.org/jira/browse/GEODE-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044939#comment-17044939 ] ASF subversion and git services commented on GEODE-7798: Commit a3e084d8ae9895accfe3c55adf33a006cb01daf2 in geode's branch refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a3e084d ] GEODE-7798: Fix flakiness in PubSubTest (#4717) - Remove flusher execution in favor of just calling writeAndFlush - Bump Netty to 4.1.45 - Correct message depending on type of subscription processing a PUBLISH > CI: org.apache.geode.redis.PubSubTest failed intermittently on Windows > > > Key: GEODE-7798 > URL: https://issues.apache.org/jira/browse/GEODE-7798 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jens Deppe >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1240 > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1242 > org.apache.geode.redis.PubSubTest > testTwoSubscribersOneChannel FAILED > org.junit.ComparisonFailure: expected:<[2]L> but was:<[1]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testTwoSubscribersOneChannel(PubSubTest.java:163) > org.apache.geode.redis.PubSubTest > testOneSubscriberSubscribingToTwoChannels > FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testOneSubscriberSubscribingToTwoChannels(PubSubTest.java:124) > org.apache.geode.redis.PubSubTest > testDeadSubscriber FAILED > org.junit.ComparisonFailure: expected:<[0]L> but was:<[2]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testDeadSubscriber(PubSubTest.java:250) > org.apache.geode.redis.PubSubTest > testOneSubscriberOneChannelTwoTimes FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[3]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testOneSubscriberOneChannelTwoTimes(PubSubTest.java:210) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7817) Server creation hangs when async-distribution-timeout is set on JDK11
Donal Evans created GEODE-7817: -- Summary: Server creation hangs when async-distribution-timeout is set on JDK11 Key: GEODE-7817 URL: https://issues.apache.org/jira/browse/GEODE-7817 Project: Geode Issue Type: Bug Reporter: Donal Evans Following the changes introduced in [https://github.com/apache/geode/pull/4629], hangs are frequently observed when starting more than one server configured with an async-distribution-timeout when running on JDK 11. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7817) Server creation hangs when async-distribution-timeout is set on JDK11
[
https://issues.apache.org/jira/browse/GEODE-7817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-7817:
---
Description:
Following the changes introduced in
[https://github.com/apache/geode/pull/4629], hangs are frequently observed when
starting more than one server configured with an async-distribution-timeout
when running on JDK 11.
A test to reproduce the issue is provided below:
{code:java}
public class ConnectionChangeHangTest {
int serversToStart = 3;
@Rule
public ClusterStartupRule cluster = new ClusterStartupRule(serversToStart +
1);
@Test
/*
* This test must be run with JDK 11 for it to show the hang
*/
public void test() {
MemberVM locator = cluster.startLocatorVM(0);
int locatorPort = locator.getPort();
for (int i = 0; i < serversToStart; ++i) {
cluster.startServerVM(i + 1, s -> s.withConnectionToLocator(locatorPort)
.withProperty("async-distribution-timeout", "5"));
}
}
}
{code}
was:Following the changes introduced in
[https://github.com/apache/geode/pull/4629], hangs are frequently observed when
starting more than one server configured with an async-distribution-timeout
when running on JDK 11.
> Server creation hangs when async-distribution-timeout is set on JDK11
> -
>
> Key: GEODE-7817
> URL: https://issues.apache.org/jira/browse/GEODE-7817
> Project: Geode
> Issue Type: Bug
>Reporter: Donal Evans
>Priority: Major
>
> Following the changes introduced in
> [https://github.com/apache/geode/pull/4629], hangs are frequently observed
> when starting more than one server configured with an
> async-distribution-timeout when running on JDK 11.
> A test to reproduce the issue is provided below:
> {code:java}
> public class ConnectionChangeHangTest {
> int serversToStart = 3;
> @Rule
> public ClusterStartupRule cluster = new ClusterStartupRule(serversToStart +
> 1);
> @Test
> /*
>* This test must be run with JDK 11 for it to show the hang
>*/
> public void test() {
> MemberVM locator = cluster.startLocatorVM(0);
> int locatorPort = locator.getPort();
> for (int i = 0; i < serversToStart; ++i) {
> cluster.startServerVM(i + 1, s -> s.withConnectionToLocator(locatorPort)
> .withProperty("async-distribution-timeout", "5"));
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7727) Geode P2P connection hanging
[
https://issues.apache.org/jira/browse/GEODE-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044976#comment-17044976
]
ASF subversion and git services commented on GEODE-7727:
Commit 0eb49ab9c1535a6ae5d56c63ce7f85ed33e090fb in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0eb49ab ]
Revert "GEODE-7727: modify sender thread to detect release of connection
(#4629)" (#4726)
This reverts commit 1a0d9769e482f49e0c725c0d6adc75d324f88958.
> Geode P2P connection hanging
>
>
> Key: GEODE-7727
> URL: https://issues.apache.org/jira/browse/GEODE-7727
> Project: Geode
> Issue Type: Bug
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {color:#172b4d}Geode P2P handshake reader stops listening to it's socket once
> the handshake between 2 peers is established. This seems to be a design
> choice.
> {color}
> {color:#172b4d}The problem is when the connection gets killed (TCP FIN).
> Since nothing is listening on the socket, nothing will get that FIN package
> and close the connection. The connection is left hanging (CLOSE-WAIT state).
> The peers are then unable to establish proper P2P communication later.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7815) Document setting a GEODE_HOME env variable
[ https://issues.apache.org/jira/browse/GEODE-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-7815: -- Assignee: Karen Smoler Miller > Document setting a GEODE_HOME env variable > -- > > Key: GEODE-7815 > URL: https://issues.apache.org/jira/browse/GEODE-7815 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > While internal methods will check the classpath for locating WAR files, we > should document that setting a GEODE_HOME environment variable might an > easier method for some installations than changing the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6448) LocatorUDPSecurityDUnitTest.testStartTwoLocators has suspicious string for javax.crypto.BadPaddingException
[
https://issues.apache.org/jira/browse/GEODE-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045029#comment-17045029
]
Kirk Lund commented on GEODE-6448:
--
Note that many dunit tests are reproducing this failure (not frequently though).
While running PersistentColocatedPartitionedRegionDistributedTest a thousand
times to verify that I've fixed a flaky issue in the test, it hit an
interesting failure trying to send a RequestImageMessage. This generated a
stack trace which caused the test to fail grep for suspect strings. I can
easily suppress this failure, BUT it looks like a bug in message distribution
which may have been introduced by the recent membership changes
(modularization).
{noformat}
[fatal 2020/02/19 02:50:04.862 GMT
tid=8410] While pushing message
:41003; keysOnly=false; processorId=40462;
waitForInit=false; checkTombstoneVersions=true;
versionVector=RegionVersionVector[2ab5849689d446bd-a7da0400b0e718f7={rv0 gc0
localVersion=0 local exceptions=[]} others={}, gc={}]; unfinished keys=[])> to
recipients: <172.17.0.4(179):41002>
java.lang.IllegalArgumentException: newPosition > limit: (32768 > 90)
at java.base/java.nio.Buffer.createPositionException(Buffer.java:318)
at java.base/java.nio.Buffer.position(Buffer.java:293)
at java.base/java.nio.ByteBuffer.position(ByteBuffer.java:1086)
at
java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:226)
at
java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:67)
at java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:116)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:58)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:50)
at
java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:463)
at
org.apache.geode.internal.tcp.Connection.writeFully(Connection.java:2587)
at
org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:1867)
at
org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:324)
at
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:249)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2060)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1987)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2024)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1084)
at
org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:514)
at
org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1222)
at
org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1082)
at
org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:259)
at
org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:983)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:785)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:460)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:319)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2896)
at
org.apache.geode.internal.cache.partitioned.ManageBackupBucketMessage.operateOnPartitionedRegion(ManageBackupBucketMessage.java:159)
at
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:394)
at
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:458)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[jira] [Updated] (GEODE-6448) LocatorUDPSecurityDUnitTest.testStartTwoLocators has suspicious string for javax.crypto.BadPaddingException
[
https://issues.apache.org/jira/browse/GEODE-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6448:
-
Component/s: (was: locator)
messaging
> LocatorUDPSecurityDUnitTest.testStartTwoLocators has suspicious string for
> javax.crypto.BadPaddingException
> ---
>
> Key: GEODE-6448
> URL: https://issues.apache.org/jira/browse/GEODE-6448
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: CI
>
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/427
> failed with
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.LocatorUDPSecurityDUnitTest >
> testStartTwoLocators 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 1024
> [error 2019/02/22 23:02:43.432 UTC
> tid=603] Exception deserializing message payload: [dst: 170b732f838e:41002,
> src: 170b732f838e:41001 (2 headers), size=250 bytes,
> flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
> java.lang.Exception: Message id is -143
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readEncryptedMessage(JGroupsMessenger.java:1138)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readJGMessage(JGroupsMessenger.java:1042)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1296)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1265)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.BadPaddingException: Given final block not
> properly padded. Such issues can arise if a bad key is used during decryption.
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991)
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847)
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
> at javax.crypto.Cipher.doFinal(Cipher.java:2164)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncryptionCipherPool.decryptBytes(GMSEncryptionCipherPool.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.decryptData(GMSEncrypt.java:147)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readEncryptedMessage(JGroupsMessenger.java:1117)
> ... 21 more
> ---
> Found suspect string in log4j at line
> [error 2019/02/22 23:02:43.737 UTC
> tid=603] Exception deserializing message payload: [dst:
> 170b732f838e:41002, src: 170b732f838e:41001 (2 headers), size=1324
> bytes, flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
> java.lang.Exception: Message id is -150
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readEncryptedMessage(JGroupsMessenger.java:1138)
> at
> org.apache.geode.distributed
[jira] [Updated] (GEODE-6448) LocatorUDPSecurityDUnitTest.testStartTwoLocators has suspicious string for javax.crypto.BadPaddingException
[
https://issues.apache.org/jira/browse/GEODE-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6448:
-
Component/s: locator
> LocatorUDPSecurityDUnitTest.testStartTwoLocators has suspicious string for
> javax.crypto.BadPaddingException
> ---
>
> Key: GEODE-6448
> URL: https://issues.apache.org/jira/browse/GEODE-6448
> Project: Geode
> Issue Type: Bug
> Components: locator, membership, messaging
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: CI
>
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/427
> failed with
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.LocatorUDPSecurityDUnitTest >
> testStartTwoLocators 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 1024
> [error 2019/02/22 23:02:43.432 UTC
> tid=603] Exception deserializing message payload: [dst: 170b732f838e:41002,
> src: 170b732f838e:41001 (2 headers), size=250 bytes,
> flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
> java.lang.Exception: Message id is -143
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readEncryptedMessage(JGroupsMessenger.java:1138)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readJGMessage(JGroupsMessenger.java:1042)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1296)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1265)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.BadPaddingException: Given final block not
> properly padded. Such issues can arise if a bad key is used during decryption.
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991)
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847)
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
> at javax.crypto.Cipher.doFinal(Cipher.java:2164)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncryptionCipherPool.decryptBytes(GMSEncryptionCipherPool.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.decryptData(GMSEncrypt.java:147)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readEncryptedMessage(JGroupsMessenger.java:1117)
> ... 21 more
> ---
> Found suspect string in log4j at line
> [error 2019/02/22 23:02:43.737 UTC
> tid=603] Exception deserializing message payload: [dst:
> 170b732f838e:41002, src: 170b732f838e:41001 (2 headers), size=1324
> bytes, flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
> java.lang.Exception: Message id is -150
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readEncryptedMessage(JGroupsMessenger.java:1138)
> at
> org.apache.geode.distributed.internal.membership.gms.mess
[jira] [Issue Comment Deleted] (GEODE-6448) LocatorUDPSecurityDUnitTest.testStartTwoLocators has suspicious string for javax.crypto.BadPaddingException
[
https://issues.apache.org/jira/browse/GEODE-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6448:
-
Comment: was deleted
(was: Note that many dunit tests are reproducing this failure (not frequently
though).
While running PersistentColocatedPartitionedRegionDistributedTest a thousand
times to verify that I've fixed a flaky issue in the test, it hit an
interesting failure trying to send a RequestImageMessage. This generated a
stack trace which caused the test to fail grep for suspect strings. I can
easily suppress this failure, BUT it looks like a bug in message distribution
which may have been introduced by the recent membership changes
(modularization).
{noformat}
[fatal 2020/02/19 02:50:04.862 GMT
tid=8410] While pushing message
:41003; keysOnly=false; processorId=40462;
waitForInit=false; checkTombstoneVersions=true;
versionVector=RegionVersionVector[2ab5849689d446bd-a7da0400b0e718f7={rv0 gc0
localVersion=0 local exceptions=[]} others={}, gc={}]; unfinished keys=[])> to
recipients: <172.17.0.4(179):41002>
java.lang.IllegalArgumentException: newPosition > limit: (32768 > 90)
at java.base/java.nio.Buffer.createPositionException(Buffer.java:318)
at java.base/java.nio.Buffer.position(Buffer.java:293)
at java.base/java.nio.ByteBuffer.position(ByteBuffer.java:1086)
at
java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:226)
at
java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:67)
at java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:116)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:58)
at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:50)
at
java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:463)
at
org.apache.geode.internal.tcp.Connection.writeFully(Connection.java:2587)
at
org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:1867)
at
org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:324)
at
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:249)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2060)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1987)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2024)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1084)
at
org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:514)
at
org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1222)
at
org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1082)
at
org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:259)
at
org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:983)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:785)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:460)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:319)
at
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2896)
at
org.apache.geode.internal.cache.partitioned.ManageBackupBucketMessage.operateOnPartitionedRegion(ManageBackupBucketMessage.java:159)
at
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:394)
at
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:458)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.geode.dis
[jira] [Commented] (GEODE-7810) Cannot form connection to alert listener should be logged at WARNING level
[
https://issues.apache.org/jira/browse/GEODE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045039#comment-17045039
]
ASF subversion and git services commented on GEODE-7810:
Commit 387848f10c0362569b453ca3ed583990547bac84 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=387848f ]
GEODE-7810: Change alert listener connection warning from fatal (#4728)
Add AlertingIOException to excludedClasses.txt for geode-core
AnalyzeSerializablesJUnitTest.
> Cannot form connection to alert listener should be logged at WARNING level
> --
>
> Key: GEODE-7810
> URL: https://issues.apache.org/jira/browse/GEODE-7810
> Project: Geode
> Issue Type: Bug
> Components: logging, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The Cannot form connection to alert listener log message is currently being
> logged at FATAL level. This should be logged as a WARNING (or ERROR) instead.
> {noformat}
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.7(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:998)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:567)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:782)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:545)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:334)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2061)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1988)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2025)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1085)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:92)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7813) add Build-Java-Vendor to gfsh version --full
[ https://issues.apache.org/jira/browse/GEODE-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045041#comment-17045041 ] ASF subversion and git services commented on GEODE-7813: Commit 56f51e8724b1644a2af6b1a8998f131c544725de in geode's branch refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=56f51e8 ] GEODE-7813: add Build-Java-Vendor to gfsh version --full (#4729) > add Build-Java-Vendor to gfsh version --full > > > Key: GEODE-7813 > URL: https://issues.apache.org/jira/browse/GEODE-7813 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The version info already includes the version of the compiler in > Build-Java-Version. As there are now several java compiler vendors and a > multitude of ways Geode may get compiled (various pipeline jobs, by a release > manager, by users, etc) it makes sense to record the provider of that javac > version as well. This is also required to audit that only open-source tools > are being used to produce Geode artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7798) CI: org.apache.geode.redis.PubSubTest failed intermittently on Windows
[ https://issues.apache.org/jira/browse/GEODE-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045042#comment-17045042 ] ASF subversion and git services commented on GEODE-7798: Commit 0f9bbf023df2b97ff54d9053cf41be57b1964203 in geode's branch refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f9bbf0 ] GEODE-7798: Fix flakiness in PubSubTest (#4717) - Remove flusher execution in favor of just calling writeAndFlush - Bump Netty to 4.1.45 - Correct message depending on type of subscription processing a PUBLISH > CI: org.apache.geode.redis.PubSubTest failed intermittently on Windows > > > Key: GEODE-7798 > URL: https://issues.apache.org/jira/browse/GEODE-7798 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jens Deppe >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1240 > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1242 > org.apache.geode.redis.PubSubTest > testTwoSubscribersOneChannel FAILED > org.junit.ComparisonFailure: expected:<[2]L> but was:<[1]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testTwoSubscribersOneChannel(PubSubTest.java:163) > org.apache.geode.redis.PubSubTest > testOneSubscriberSubscribingToTwoChannels > FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testOneSubscriberSubscribingToTwoChannels(PubSubTest.java:124) > org.apache.geode.redis.PubSubTest > testDeadSubscriber FAILED > org.junit.ComparisonFailure: expected:<[0]L> but was:<[2]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testDeadSubscriber(PubSubTest.java:250) > org.apache.geode.redis.PubSubTest > testOneSubscriberOneChannelTwoTimes FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[3]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testOneSubscriberOneChannelTwoTimes(PubSubTest.java:210) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7803) provide a way to create an internal region without using deprecated classes
[ https://issues.apache.org/jira/browse/GEODE-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045040#comment-17045040 ] ASF subversion and git services commented on GEODE-7803: Commit b082c0352b0a96c3dc1cf07caaf1f7f2e4fb8177 in geode's branch refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b082c03 ] GEODE-7803: provide undeprecated internal region create (#4722) You can now use InternalRegionFactory to create a region configured with InternalRegionArguments. No need to use the deprecated AttributesFactory. InternalRegionFactory used to be named RegionFactoryImpl. > provide a way to create an internal region without using deprecated classes > --- > > Key: GEODE-7803 > URL: https://issues.apache.org/jira/browse/GEODE-7803 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently geode has some places that create internal regions (using > InternalRegionArguments) that use deprecated classes to do this. It would be > nice if an internal way was provided to do this that was not deprecated. > GEODE-7799 is doing this. Once that fix is merged in then the > RegionFactoryImpl enhancement it add could be used in the places that use > deprecated apis to specify InternalRegionArguments -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7727) Geode P2P connection hanging
[
https://issues.apache.org/jira/browse/GEODE-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045043#comment-17045043
]
ASF subversion and git services commented on GEODE-7727:
Commit 0eb49ab9c1535a6ae5d56c63ce7f85ed33e090fb in geode's branch
refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging
from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0eb49ab ]
Revert "GEODE-7727: modify sender thread to detect release of connection
(#4629)" (#4726)
This reverts commit 1a0d9769e482f49e0c725c0d6adc75d324f88958.
> Geode P2P connection hanging
>
>
> Key: GEODE-7727
> URL: https://issues.apache.org/jira/browse/GEODE-7727
> Project: Geode
> Issue Type: Bug
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {color:#172b4d}Geode P2P handshake reader stops listening to it's socket once
> the handshake between 2 peers is established. This seems to be a design
> choice.
> {color}
> {color:#172b4d}The problem is when the connection gets killed (TCP FIN).
> Since nothing is listening on the socket, nothing will get that FIN package
> and close the connection. The connection is left hanging (CLOSE-WAIT state).
> The peers are then unable to establish proper P2P communication later.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7810) Cannot form connection to alert listener should be logged at WARNING level
[
https://issues.apache.org/jira/browse/GEODE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045044#comment-17045044
]
ASF subversion and git services commented on GEODE-7810:
Commit 387848f10c0362569b453ca3ed583990547bac84 in geode's branch
refs/heads/GEODE-7513-PersistentColocatedPartitionedRegionDistributedTest-debugging
from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=387848f ]
GEODE-7810: Change alert listener connection warning from fatal (#4728)
Add AlertingIOException to excludedClasses.txt for geode-core
AnalyzeSerializablesJUnitTest.
> Cannot form connection to alert listener should be logged at WARNING level
> --
>
> Key: GEODE-7810
> URL: https://issues.apache.org/jira/browse/GEODE-7810
> Project: Geode
> Issue Type: Bug
> Components: logging, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The Cannot form connection to alert listener log message is currently being
> logged at FATAL level. This should be logged as a WARNING (or ERROR) instead.
> {noformat}
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.7(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:998)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:567)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:782)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:545)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:334)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2061)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1988)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2025)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1085)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:92)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7784) Region entry has wrong RVV version after removeAll retried
[
https://issues.apache.org/jira/browse/GEODE-7784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045048#comment-17045048
]
ASF subversion and git services commented on GEODE-7784:
Commit 72360701462e4320baf3ad2975c2bbe830a8f535 in geode's branch
refs/heads/develop from Jianxia Chen
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7236070 ]
GEODE-7784: Fix the test to compare unordered list of version tags
Comparing two potentially unordered list
Authored-by: Jianxia Chen
> Region entry has wrong RVV version after removeAll retried
> --
>
> Key: GEODE-7784
> URL: https://issues.apache.org/jira/browse/GEODE-7784
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Kirk Lund
>Assignee: Jianxia Chen
>Priority: Major
> Labels: ConcurrencyChecksEnabled, GeodeCommons, RVV, removeAll
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I believe this is a product bug that
> PutAllClientServerDistributedTest.shouldReturnVersionTagOfTombstoneVersionWhenRemoveAllRetried
> intermittently reproduces.
> The test fails because rv1 is discovered instead of expected rv12 during
> validation:
> {noformat}
> {v2; rv12]; mbr=782257b7f21e4b...> but was:<[{v2; rv1[1;
> mbr=782257b7f21e4b70-910600606032139d; time=1581098169625; remote},
> {noformat}
> Here's the full failure stack trace:
> {noformat}
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest >
> shouldReturnVersionTagOfTombstoneVersionWhenRemoveAllRetried FAILED
> org.junit.ComparisonFailure: expected:<[{v2; rv1[5;
> mbr=782257b7f21e4b70-910600606032139d; time=1581098169624; remote},
> {v2; rv20; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv14; mbr=782257b7f21e4b70-910600606032139d; time=1581098169624;
> remote},
> {v2; rv19; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv17; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv16; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv11; mbr=782257b7f21e4b70-910600606032139d; time=1581098169624;
> remote},
> {v2; rv13; mbr=782257b7f21e4b70-910600606032139d; time=1581098169624;
> remote},
> {v2; rv18; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv12; mbr=782257b7f21e4b70-910600606032139d; time=1581098169624;
> remote},
> {v2; rv14; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv19; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv13; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv18; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv16; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv15; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv20; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv11; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv12; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv17; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv11; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv14; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv19; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv13; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv18; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv15; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv20; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv12; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv17; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv16; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv11; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv13; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv18; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv12; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv17; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> rem
[jira] [Resolved] (GEODE-7784) Region entry has wrong RVV version after removeAll retried
[
https://issues.apache.org/jira/browse/GEODE-7784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen resolved GEODE-7784.
-
Resolution: Fixed
> Region entry has wrong RVV version after removeAll retried
> --
>
> Key: GEODE-7784
> URL: https://issues.apache.org/jira/browse/GEODE-7784
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Kirk Lund
>Assignee: Jianxia Chen
>Priority: Major
> Labels: ConcurrencyChecksEnabled, GeodeCommons, RVV, removeAll
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I believe this is a product bug that
> PutAllClientServerDistributedTest.shouldReturnVersionTagOfTombstoneVersionWhenRemoveAllRetried
> intermittently reproduces.
> The test fails because rv1 is discovered instead of expected rv12 during
> validation:
> {noformat}
> {v2; rv12]; mbr=782257b7f21e4b...> but was:<[{v2; rv1[1;
> mbr=782257b7f21e4b70-910600606032139d; time=1581098169625; remote},
> {noformat}
> Here's the full failure stack trace:
> {noformat}
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest >
> shouldReturnVersionTagOfTombstoneVersionWhenRemoveAllRetried FAILED
> org.junit.ComparisonFailure: expected:<[{v2; rv1[5;
> mbr=782257b7f21e4b70-910600606032139d; time=1581098169624; remote},
> {v2; rv20; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv14; mbr=782257b7f21e4b70-910600606032139d; time=1581098169624;
> remote},
> {v2; rv19; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv17; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv16; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv11; mbr=782257b7f21e4b70-910600606032139d; time=1581098169624;
> remote},
> {v2; rv13; mbr=782257b7f21e4b70-910600606032139d; time=1581098169624;
> remote},
> {v2; rv18; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv12; mbr=782257b7f21e4b70-910600606032139d; time=1581098169624;
> remote},
> {v2; rv14; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv19; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv13; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv18; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv16; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv15; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv20; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv11; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv12; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv17; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv11; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv14; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv19; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv13; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv18; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv15; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv20; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv12; mbr=782257b7f21e4b70-910600606032139d; time=1581098169625;
> remote},
> {v2; rv17; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv16; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv11; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv13; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv18; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv12; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv17; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv20; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv14; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv19; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
> {v2; rv16; mbr=782257b7f21e4b70-910600606032139d; time=1581098169626;
> remote},
>
