[jira] [Commented] (GEODE-9565) DeploymentManagementDUnitTest fails mass test run with (HTTP form data?) in the log
[
https://issues.apache.org/jira/browse/GEODE-9565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407004#comment-17407004
]
Geode Integration commented on GEODE-9565:
--
Seen in [distributed-test-openjdk8
#1430|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1430]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630137526/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630137526/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz].
> DeploymentManagementDUnitTest fails mass test run with (HTTP form data?) in
> the log
> ---
>
> Key: GEODE-9565
> URL: https://issues.apache.org/jira/browse/GEODE-9565
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> Failure in this run due to "Suspicious strings were written to the log":
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11466814
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1430
> Here's the beginning of the offending log content:
> {code:java}
> org.apache.geode.management.internal.rest.DeploymentManagementDUnitTest >
> classMethod 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 'dunit_suspect-vm0.log' at line 602
>
> $ \u\u\utimestamp3436046\u0001bS#C\uPK\u0007\u0008C??{}
> \u\u\u
>
> \u\u\uPK\u0001\u0002\u0014\u\u0014\u\u0008\u0008\u0008\u\u00068\u001cS?\u\u\u??\u\u\u\u000c\u\u0004\u\u\u\u\u\u\u\u\u\u\u\u\u\u\uClass2.class\u\uPK\u0001\u0002\u0014\u\u0014\u\u0008\u0008\u0008\u\u00068\u001cSC??{}
> \u\u\u
> \u\u\u
> \u\u\u\u\u\u\u\u\u\u\u\u\u??\u\u\utimestampPK\u0005\u0006\u\u\u\u\u0002\u\u0002\uu\u\u\u\u001d\u0001\u\u\u\u
> --YZ_CWqvae2jydiy-5zCOPBjJdXq3V4ISPRu
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9565) DeploymentManagementDUnitTest fails mass test run with (HTTP form data?) in the log
Bill Burcham created GEODE-9565:
---
Summary: DeploymentManagementDUnitTest fails mass test run with
(HTTP form data?) in the log
Key: GEODE-9565
URL: https://issues.apache.org/jira/browse/GEODE-9565
Project: Geode
Issue Type: Bug
Components: management
Affects Versions: 1.15.0
Reporter: Bill Burcham
Failure in this run due to "Suspicious strings were written to the log":
https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11466814
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1430
Here's the beginning of the offending log content:
{code:java}
org.apache.geode.management.internal.rest.DeploymentManagementDUnitTest >
classMethod 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 'dunit_suspect-vm0.log' at line 602
$
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406999#comment-17406999
]
Geode Integration commented on GEODE-9486:
--
Seen in [windows-integration-test-openjdk11
#152.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk11/builds/152.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0450/test-results/integrationTest/1630365419/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0450/test-artifacts/1630365419/windows-integrationtestfiles-openjdk11-1.15.0-build.0450.tgz].
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9564) Radish ParameterRequirements package name does not follow naming conventions
[ https://issues.apache.org/jira/browse/GEODE-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9564: -- Labels: pull-request-available (was: ) > Radish ParameterRequirements package name does not follow naming conventions > > > Key: GEODE-9564 > URL: https://issues.apache.org/jira/browse/GEODE-9564 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > Per [the style > guide|https://google.github.io/styleguide/javaguide.html#s5.2.1-package-names] > adopted by Geode, package names should be all lower-case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9564) Radish ParameterRequirements package name does not follow naming conventions
[ https://issues.apache.org/jira/browse/GEODE-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-9564: -- Assignee: Donal Evans > Radish ParameterRequirements package name does not follow naming conventions > > > Key: GEODE-9564 > URL: https://issues.apache.org/jira/browse/GEODE-9564 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > Per [the style > guide|https://google.github.io/styleguide/javaguide.html#s5.2.1-package-names] > adopted by Geode, package names should be all lower-case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9564) Radish ParameterRequirements package name does not follow naming conventions
Donal Evans created GEODE-9564: -- Summary: Radish ParameterRequirements package name does not follow naming conventions Key: GEODE-9564 URL: https://issues.apache.org/jira/browse/GEODE-9564 Project: Geode Issue Type: Bug Components: redis Affects Versions: 1.15.0 Reporter: Donal Evans Per [the style guide|https://google.github.io/styleguide/javaguide.html#s5.2.1-package-names] adopted by Geode, package names should be all lower-case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9563) Examples for Token Refresh/Reauthentication With Redis Clients
Wayne created GEODE-9563: Summary: Examples for Token Refresh/Reauthentication With Redis Clients Key: GEODE-9563 URL: https://issues.apache.org/jira/browse/GEODE-9563 Project: Geode Issue Type: New Feature Components: redis Reporter: Wayne The Redis Server and clients do not directly support token refresh or reauthentication. Write example code of how we can accomplish a forced reauthentication using the existing Redis clients. _Acceptance Criteria_ Example code has been written using the Jedis and Lettuce clients that illustrate how to force these clients to reauthenticate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406987#comment-17406987
]
Geode Integration commented on GEODE-9486:
--
Seen in [windows-integration-test-openjdk11
#153|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk11/builds/153]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0451/test-results/integrationTest/1630363004/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0451/test-artifacts/1630363004/windows-integrationtestfiles-openjdk11-1.15.0-build.0451.tgz].
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406985#comment-17406985
]
Geode Integration commented on GEODE-9486:
--
Seen in [windows-integration-test-openjdk8
#157|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk8/builds/157]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0451/test-results/integrationTest/1630361853/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0451/test-artifacts/1630361853/windows-integrationtestfiles-openjdk8-1.15.0-build.0451.tgz].
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9562) Reserved Word for Redis Region Name
Wayne created GEODE-9562: Summary: Reserved Word for Redis Region Name Key: GEODE-9562 URL: https://issues.apache.org/jira/browse/GEODE-9562 Project: Geode Issue Type: New Feature Components: redis Reporter: Wayne We need a reserved word for the Redis region name to prevent Geode users from creating a region name with the same name as the Redis Region name as well as performing normal Geode operations on that region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406986#comment-17406986
]
Geode Integration commented on GEODE-9486:
--
Seen in [windows-integration-test-openjdk11
#153|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk11/builds/153]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0451/test-results/integrationTest/1630363004/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0451/test-artifacts/1630363004/windows-integrationtestfiles-openjdk11-1.15.0-build.0451.tgz].
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406983#comment-17406983 ] Geode Integration commented on GEODE-9038: -- Seen in [distributed-test-openjdk8 #156|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/156] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0451/test-results/distributedTest/1630362171/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0451/test-artifacts/1630362171/distributedtestfiles-openjdk8-1.15.0-build.0451.tgz]. > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Priority: Major > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting 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 'dunit_suspect-vm0.log' at line 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > 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) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406978#comment-17406978
]
Geode Integration commented on GEODE-7053:
--
Seen in [distributed-test-openjdk8
#1492|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1492]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630190965/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630190965/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz].
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
> This test depends on a background thread waking up every 10 ms to perform a
> GET which prevents another thread from expiring an entry. I think that would
> be very prone to failing if the thread loses CPU for any reason.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9408) Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true
[ https://issues.apache.org/jira/browse/GEODE-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406977#comment-17406977 ] Geode Integration commented on GEODE-9408: -- Seen in [distributed-test-openjdk8 #1488|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1488] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630185773/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630185773/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz]. > Avoid duplicate events sent by Serial Gateway Sender when > group-transaction-events is true > -- > > Key: GEODE-9408 > URL: https://issues.apache.org/jira/browse/GEODE-9408 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When group-transaction-events is set to true for a serial gateway sender, it > is possible that events that were retrieved from the queue to be added to a > batch in order to complete a transaction are later sent again in another > batch due to a bug in the removal logic of events when the ack for a batch is > received from the receiver. > This situation has been seen when several clients are sending transactions to > a Geode cluster when the events for the transactions sent by the clients are > mixed in the gateway sender queue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406968#comment-17406968 ] Geode Integration commented on GEODE-9038: -- Seen in [distributed-test-openjdk8 #1483|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1483] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630183264/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630183264/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz]. > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Priority: Major > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting 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 'dunit_suspect-vm0.log' at line 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > 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) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6489) CI Failures with testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406967#comment-17406967
]
Geode Integration commented on GEODE-6489:
--
Seen in [distributed-test-openjdk8
#1482|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1482]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630182920/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630182920/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz].
> CI Failures with testDistributedDeadlock
>
>
> Key: GEODE-6489
> URL: https://issues.apache.org/jira/browse/GEODE-6489
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Jinmei Liao
>Priority: Major
> Labels: flaky
>
> In an single CI run, we see 3 failures all related to testDistributedDeadlock:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/469
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> 137 tests completed, 2 failed
> > Task :geode-web:distributedTest FAILED
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:201)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-results/distributedTest/1551833386/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-artifacts/1551833386/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0019.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406966#comment-17406966 ] Geode Integration commented on GEODE-8644: -- Seen in [distributed-test-openjdk8 #1476|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1476] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630177251/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630177251/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz]. > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on client
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406965#comment-17406965
]
Geode Integration commented on GEODE-8616:
--
Seen in [distributed-test-openjdk8
#1458|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1458]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630161907/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630161907/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz].
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1
>Reporter: Donal Evans
>Priority: Major
> Labels: GeodeOperationAPI, flaky-test
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406961#comment-17406961
]
Geode Integration commented on GEODE-7710:
--
Seen in [distributed-test-openjdk8
#1452|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1452]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630159733/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630159733/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz].
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406962#comment-17406962
]
Geode Integration commented on GEODE-7710:
--
Seen in [distributed-test-openjdk8
#1455|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1455]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630161044/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630161044/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz].
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6352) CI Failure: org.apache.geode.cache30.GlobalRegionCCEDUnitTest.testTombstones
[
https://issues.apache.org/jira/browse/GEODE-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406959#comment-17406959
]
Geode Integration commented on GEODE-6352:
--
Seen in [distributed-test-openjdk8
#1451|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1451]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630159651/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630159651/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz].
> CI Failure: org.apache.geode.cache30.GlobalRegionCCEDUnitTest.testTombstones
>
>
> Key: GEODE-6352
> URL: https://issues.apache.org/jira/browse/GEODE-6352
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.4.0
>Reporter: Lynn Hughes-Godfrey
>Priority: Major
>
> http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/23
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results Website
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://s3proxy.gemfire.pivotal.io/gemfire-test-results/9.3/distributedTest/1548995701/index.html
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> To download the test artifacts from this job, execute the following command
> after the job has completed:
> aws s3 cp
> s3://gemfire-build-artifacts/9.3/9.3.3-build.6/1548995701/distributedtestfiles-9.3.3-build.6.tgz
> .
> {noformat}
> Test failure:
> {noformat}
> org.apache.geode.cache30.GlobalRegionCCEDUnitTest > testTombstones FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.MultiVMRegionTestCase$277.run in VM 1 running on
> Host 01e2b31fd72b with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.cache30.MultiVMRegionTestCase.versionTestTombstones(MultiVMRegionTestCase.java:8494)
> at
> org.apache.geode.cache30.GlobalRegionCCEDUnitTest.testTombstones(GlobalRegionCCEDUnitTest.java:155)
> Caused by:
> java.lang.AssertionError: after destroys in other vm region
> tombstone count was 0 expected=100 TombstoneService=Destroyed entries GC
> service. Replicate Queue=[0] [] batchedExpiredTombstones[0] = []
> Non-replicate Queue=[0] [] expected:<100> but was:<0>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9252) CI failure: NativeRedisClusterTestRule incorrect primary node count (expected 3 but was 2)
[
https://issues.apache.org/jira/browse/GEODE-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406958#comment-17406958
]
Jens Deppe commented on GEODE-9252:
---
Agreed - I'll increase it to 60 seconds
> CI failure: NativeRedisClusterTestRule incorrect primary node count (expected
> 3 but was 2)
> --
>
> Key: GEODE-9252
> URL: https://issues.apache.org/jira/browse/GEODE-9252
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HashesNativeRedisAcceptanceTest
> > classMethod FAILED
> org.junit.ComparisonFailure: [Incorrect primary node count]
> expected:<[3]> but was:<[2]>
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:93)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-9320) CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404768#comment-17404768
]
Jens Deppe edited comment on GEODE-9320 at 8/30/21, 9:53 PM:
-
Note, the most recent failure was not a port conflict but this error message.
Reopened GEODE-9252 for that. Leaving this open for the original port conflict
for now.
{noformat}
org.junit.ComparisonFailure: [Incorrect primary node count] expected:<[3]> but
was:<[2]>
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.NativeRedisClusterTestRule.waitForPrimaries(NativeRedisClusterTestRule.java:156)
at
org.apache.geode.redis.NativeRedisClusterTestRule.access$100(NativeRedisClusterTestRule.java:44)
at
org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:91)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
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:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.lang.Thread.run(Thread.java:829)
{noformat}
was (Author: upthewaterspout):
Note, the most recent failure was not a port conflict but this error message.
Reopened GEODE-5252 for that. Leaving this open for the original port conflict
for now.
{noformat}
org.junit.ComparisonFailure: [Incorrect primary node count] expected:<[3]> but
was:<[2]>
at
[jira] [Comment Edited] (GEODE-8970) CI failure: MicrometerBinderTest.jvmThreadMetricsBinderExists fails with NullPointerException during stopServer
[
https://issues.apache.org/jira/browse/GEODE-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406952#comment-17406952
]
Kirk Lund edited comment on GEODE-8970 at 8/30/21, 9:33 PM:
{{MicrometerBinderTest}} failed because the server failed to start within the
{{startServer}} setup:
{noformat}
Executing 889fbdd0a4f9ec5a: gfsh -e start server --name=server
--dir=C:\Users\geode\AppData\Local\Temp\junit7809244121723738090
--server-port=26437
--classpath=C:\Users\geode\AppData\Local\Temp\junit4985974788060045051\metrics-publishing-service.jar
--http-service-port=0 --J=-Dgemfire.enable-cluster-config=true
--J=-Dgemfire.jmx-manager=true --J=-Dgemfire.jmx-manager-start=true
--J=-Dgemfire.jmx-manager-port=26438 -e sleep --time=1
[info 2021/08/28 00:21:35.636 GMT tid=0x8c]
[info 2021/08/28 00:21:35.636 GMT tid=0x8c] (1) Executing -
start server --name=server
--dir=C:\Users\geode\AppData\Local\Temp\junit7809244121723738090
--server-port=26437
--classpath=C:\Users\geode\AppData\Local\Temp\junit4985974788060045051\metrics-publishing-service.jar
--http-service-port=0 --J=-Dgemfire.enable-cluster-config=true
--J=-Dgemfire.jmx-manager=true --J=-Dgemfire.jmx-manager-start=true
--J=-Dgemfire.jmx-manager-port=26438
[info 2021/08/28 00:21:35.636 GMT tid=0x8c]
[info 2021/08/28 00:21:42.964 GMT tid=0x8c] ...[error
2021/08/28 00:21:42.964 GMT tid=0x29] Unable to control process with
C:\Users\geode\AppData\Local\Temp\junit7809244121723738090\vf.gf.server.status.
Please add tools.jar from JDK to classpath for improved process control.
{noformat}
This appears to be a bug in FileProcessController caused by creating the result
file by its final name ({{vf.gf.server.status}}) before writing the contents of
the file.
The fix should be to create a result file with a temporary name, write the
complete contents to that file, and then rename the file to
{{vf.gf.server.status}}.
The {{stopServer}} teardown should also change to check {{clientCache}} and
{{serverPool}} for null before calling them.
was (Author: klund):
{{MicrometerBinderTest}} failed because the server failed to start within the
{{startServer}} setup:
{noformat}
Executing 889fbdd0a4f9ec5a: gfsh -e start server --name=server
--dir=C:\Users\geode\AppData\Local\Temp\junit7809244121723738090
--server-port=26437
--classpath=C:\Users\geode\AppData\Local\Temp\junit4985974788060045051\metrics-publishing-service.jar
--http-service-port=0 --J=-Dgemfire.enable-cluster-config=true
--J=-Dgemfire.jmx-manager=true --J=-Dgemfire.jmx-manager-start=true
--J=-Dgemfire.jmx-manager-port=26438 -e sleep --time=1
[info 2021/08/28 00:21:35.636 GMT tid=0x8c]
[info 2021/08/28 00:21:35.636 GMT tid=0x8c] (1) Executing -
start server --name=server
--dir=C:\Users\geode\AppData\Local\Temp\junit7809244121723738090
--server-port=26437
--classpath=C:\Users\geode\AppData\Local\Temp\junit4985974788060045051\metrics-publishing-service.jar
--http-service-port=0 --J=-Dgemfire.enable-cluster-config=true
--J=-Dgemfire.jmx-manager=true --J=-Dgemfire.jmx-manager-start=true
--J=-Dgemfire.jmx-manager-port=26438
[info 2021/08/28 00:21:35.636 GMT tid=0x8c]
[info 2021/08/28 00:21:42.964 GMT tid=0x8c] ...[error
2021/08/28 00:21:42.964 GMT tid=0x29] Unable to control process with
C:\Users\geode\AppData\Local\Temp\junit7809244121723738090\vf.gf.server.status.
Please add tools.jar from JDK to classpath for improved process control.
{noformat}
This appears to be a bug in FileProcessController caused by creating the result
file by its final name ({{vf.gf.server.status}}) before writing the contents of
the file.
The fix should be to create a result file with a temporary name, write the
complete contents to that file, and then rename the file to
{{vf.gf.server.status}}.
> CI failure: MicrometerBinderTest.jvmThreadMetricsBinderExists fails with
> NullPointerException during stopServer
> ---
>
> Key: GEODE-8970
> URL: https://issues.apache.org/jira/browse/GEODE-8970
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.1
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.metrics.MicrometerBinderTest > jvmThreadMetricsBinderExists
> FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [5649fcaf482615ff: gfsh -e connect --jmx-manager=localhost[22864] -e deploy
> --jar=/tmp/junit654213865788865628/function.jar]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
>
[jira] [Commented] (GEODE-8970) CI failure: MicrometerBinderTest.jvmThreadMetricsBinderExists fails with NullPointerException during stopServer
[
https://issues.apache.org/jira/browse/GEODE-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406952#comment-17406952
]
Kirk Lund commented on GEODE-8970:
--
{{MicrometerBinderTest}} failed because the server failed to start within the
{{startServer}} setup:
{noformat}
Executing 889fbdd0a4f9ec5a: gfsh -e start server --name=server
--dir=C:\Users\geode\AppData\Local\Temp\junit7809244121723738090
--server-port=26437
--classpath=C:\Users\geode\AppData\Local\Temp\junit4985974788060045051\metrics-publishing-service.jar
--http-service-port=0 --J=-Dgemfire.enable-cluster-config=true
--J=-Dgemfire.jmx-manager=true --J=-Dgemfire.jmx-manager-start=true
--J=-Dgemfire.jmx-manager-port=26438 -e sleep --time=1
[info 2021/08/28 00:21:35.636 GMT tid=0x8c]
[info 2021/08/28 00:21:35.636 GMT tid=0x8c] (1) Executing -
start server --name=server
--dir=C:\Users\geode\AppData\Local\Temp\junit7809244121723738090
--server-port=26437
--classpath=C:\Users\geode\AppData\Local\Temp\junit4985974788060045051\metrics-publishing-service.jar
--http-service-port=0 --J=-Dgemfire.enable-cluster-config=true
--J=-Dgemfire.jmx-manager=true --J=-Dgemfire.jmx-manager-start=true
--J=-Dgemfire.jmx-manager-port=26438
[info 2021/08/28 00:21:35.636 GMT tid=0x8c]
[info 2021/08/28 00:21:42.964 GMT tid=0x8c] ...[error
2021/08/28 00:21:42.964 GMT tid=0x29] Unable to control process with
C:\Users\geode\AppData\Local\Temp\junit7809244121723738090\vf.gf.server.status.
Please add tools.jar from JDK to classpath for improved process control.
{noformat}
This appears to be a bug in FileProcessController caused by creating the result
file by its final name ({{vf.gf.server.status}}) before writing the contents of
the file.
The fix should be to create a result file with a temporary name, write the
complete contents to that file, and then rename the file to
{{vf.gf.server.status}}.
> CI failure: MicrometerBinderTest.jvmThreadMetricsBinderExists fails with
> NullPointerException during stopServer
> ---
>
> Key: GEODE-8970
> URL: https://issues.apache.org/jira/browse/GEODE-8970
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.1
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.metrics.MicrometerBinderTest > jvmThreadMetricsBinderExists
> FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [5649fcaf482615ff: gfsh -e connect --jmx-manager=localhost[22864] -e deploy
> --jar=/tmp/junit654213865788865628/function.jar]] expected:<[0]> but was:<[1]>
> 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:139)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:150)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:114)
> at
> org.apache.geode.metrics.MicrometerBinderTest.startServer(MicrometerBinderTest.java:95)
> java.lang.NullPointerException
> at
> org.apache.geode.metrics.MicrometerBinderTest.stopServer(MicrometerBinderTest.java:111)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406950#comment-17406950
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#153|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/153].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406948#comment-17406948
]
Geode Integration commented on GEODE-9486:
--
Seen in [windows-integration-test-openjdk11
#152|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk11/builds/152]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0450/test-results/integrationTest/1630351863/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0450/test-artifacts/1630351863/windows-integrationtestfiles-openjdk11-1.15.0-build.0450.tgz].
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406947#comment-17406947
]
Geode Integration commented on GEODE-9486:
--
Seen in [windows-integration-test-openjdk8
#155|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk8/builds/155]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0450/test-results/integrationTest/1630350322/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0450/test-artifacts/1630350322/windows-integrationtestfiles-openjdk8-1.15.0-build.0450.tgz].
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406949#comment-17406949
]
Geode Integration commented on GEODE-9486:
--
Seen in [windows-integration-test-openjdk8
#156|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk8/builds/156]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0450/test-results/integrationTest/1630357345/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0450/test-artifacts/1630357345/windows-integrationtestfiles-openjdk8-1.15.0-build.0450.tgz].
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9561) User Guide - clarify jmx-manager-ssl vs jmx-manager-ssl-enabled
[ https://issues.apache.org/jira/browse/GEODE-9561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-9561: -- Assignee: Dave Barnes > User Guide - clarify jmx-manager-ssl vs jmx-manager-ssl-enabled > --- > > Key: GEODE-9561 > URL: https://issues.apache.org/jira/browse/GEODE-9561 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.12.4, 1.13.4 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > On page > https://geode.apache.org/docs/guide/113/managing/management/jmx_manager_operations.html, > Property jmx-manager-ssl should be jmx-manager-ssl-enabled. > Both properties exist -- differentiate between them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9561) User Guide - clarify jmx-manager-ssl vs jmx-manager-ssl-enabled
Dave Barnes created GEODE-9561: -- Summary: User Guide - clarify jmx-manager-ssl vs jmx-manager-ssl-enabled Key: GEODE-9561 URL: https://issues.apache.org/jira/browse/GEODE-9561 Project: Geode Issue Type: Improvement Components: docs Affects Versions: 1.13.4, 1.12.4 Reporter: Dave Barnes On page https://geode.apache.org/docs/guide/113/managing/management/jmx_manager_operations.html, Property jmx-manager-ssl should be jmx-manager-ssl-enabled. Both properties exist -- differentiate between them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9320) CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406941#comment-17406941
]
Dan Smith commented on GEODE-9320:
--
The latest port conflict failure seems to be before we even get to the redis
container. It is trying to start the "ryuk" container, which I guess is used
for cleaning up after tests? However, this command itself is just passing a
list of exposed ports to docker and asking docker to assign random host ports
to these exposed ports. At a guess this looks like a docker bug.
This is the code in testcontainers that is failing.
{code:java}
String ryukContainerId = client.createContainerCmd(ryukImage)
.withHostConfig(new HostConfig().withAutoRemove(true))
.withExposedPorts(new ExposedPort(8080))
.withPublishAllPorts(true)
.withName("testcontainers-ryuk-" + DockerClientFactory.SESSION_ID)
.withLabels(Collections.singletonMap(DockerClientFactory.TESTCONTAINERS_LABEL,
"true"))
.withBinds(binds)
.withPrivileged(TestcontainersConfiguration.getInstance().isRyukPrivileged())
.exec()
.getId(); {code}
> CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
> ---
>
> Key: GEODE-9320
> URL: https://issues.apache.org/jira/browse/GEODE-9320
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: flaky-test
>
> {noformat}
> org.apache.geode.redis.internal.executor.string.SetNXNativeRedisAcceptanceTest
> > classMethod FAILED
> 13:40:47org.testcontainers.containers.ContainerLaunchException: Container
> startup failed
> 13:40:47at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.startAmbassadorContainers(DockerComposeContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:178)
> 13:40:47at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:85)
> 13:40:47at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 13:40:47at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 13:40:47at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
> 13:40:47at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
> 13:40:47at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
>
[jira] [Commented] (GEODE-9559) Demacroize clicache
[ https://issues.apache.org/jira/browse/GEODE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406924#comment-17406924 ] ASF GitHub Bot commented on GEODE-9559: --- mmartell commented on pull request #862: URL: https://github.com/apache/geode-native/pull/862#issuecomment-908649949 The procedure for this PR consisted of cutting/pasting the original macro invocations with the corresponding preprocessor output. Although there are quite a few files involved, the changes are basically all the same. For this reason it seemed prudent to submit this as a single PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Demacroize clicache > > > Key: GEODE-9559 > URL: https://issues.apache.org/jira/browse/GEODE-9559 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > Macros in C++ complicate debug efforts and code maintenance and are generally > considered old school ([https://stroustrup.com/icsm-2012-demacro.pdf).] This > PR is to remove all the complicated macros in the .NET Framework client, e.g. > the clicache module. > In addition to improving the maintainability of the clicache module, removing > the macros will greatly assist the creation of the .NET Core client. [dotPeek > |http://jetbrains.com/decompiler/] is proving to be a valuable tool in the > .NET Core project, but is currently limited by the extensive use of macros in > the clicache code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9460) add tests for multi-user mode when one user expires
[ https://issues.apache.org/jira/browse/GEODE-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406923#comment-17406923 ] ASF subversion and git services commented on GEODE-9460: Commit 4af2badab70b0321491b2ddc4e21b8551ea5a368 in geode's branch refs/heads/develop from Joris Melchior [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4af2bad ] GEODE-9458: function execution with expiring authentication (#6789) * GEODE-9456, GEODE-9452: Authentication Expiration (#6721) * Add tests and throw AuthenticationExpiredException Co-authored-by: Joris Melchior * GEODE-9460: Add testing for mutli-user scenarios (#6755) Co-Authored-By Jinmei Liao * review update * revert accidental change * GEODE-9458: function execution with expiring authentication * Changes based on review * Changes based on review, parameterization Co-authored-by: Jinmei Liao > add tests for multi-user mode when one user expires > --- > > Key: GEODE-9460 > URL: https://issues.apache.org/jira/browse/GEODE-9460 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Current state: > Currently an established client connection does not time out > New state: > Client connections can be subject to time out depending on the security > manager implementation and client code should be able to handle > re-authentication of client connections. > Things to test: > * Test multi-user connections and ensure that when one specific user times > out this user is forced to re-authenticate > * Confirm re-authentication on both new version and versions of the client > in pre 1.13.3 releases > * Confirm the behaviour in single and multi-server environments > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9452) The older version client should receive the AuthenticationRequiredException when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406922#comment-17406922 ] ASF subversion and git services commented on GEODE-9452: Commit 4af2badab70b0321491b2ddc4e21b8551ea5a368 in geode's branch refs/heads/develop from Joris Melchior [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4af2bad ] GEODE-9458: function execution with expiring authentication (#6789) * GEODE-9456, GEODE-9452: Authentication Expiration (#6721) * Add tests and throw AuthenticationExpiredException Co-authored-by: Joris Melchior * GEODE-9460: Add testing for mutli-user scenarios (#6755) Co-Authored-By Jinmei Liao * review update * revert accidental change * GEODE-9458: function execution with expiring authentication * Changes based on review * Changes based on review, parameterization Co-authored-by: Jinmei Liao > The older version client should receive the AuthenticationRequiredException > when authentication expires > --- > > Key: GEODE-9452 > URL: https://issues.apache.org/jira/browse/GEODE-9452 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.15.0 > > > Currently, for older client, it's receiving a ClassNotFoundException, we need > to add the serialization code to convert the AuthenticationExpiredException > into this old exception type(AuthenticationRequiredException) that the older > clients can understand. > > Note: when converting the exception, if we have the message to match what the > older client expects, it can do re-authentication automatically, but we lost > the original message that server has thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9458) Add tests for functions executions on servers when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406920#comment-17406920 ] ASF subversion and git services commented on GEODE-9458: Commit 4af2badab70b0321491b2ddc4e21b8551ea5a368 in geode's branch refs/heads/develop from Joris Melchior [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4af2bad ] GEODE-9458: function execution with expiring authentication (#6789) * GEODE-9456, GEODE-9452: Authentication Expiration (#6721) * Add tests and throw AuthenticationExpiredException Co-authored-by: Joris Melchior * GEODE-9460: Add testing for mutli-user scenarios (#6755) Co-Authored-By Jinmei Liao * review update * revert accidental change * GEODE-9458: function execution with expiring authentication * Changes based on review * Changes based on review, parameterization Co-authored-by: Jinmei Liao > Add tests for functions executions on servers when authentication expires > - > > Key: GEODE-9458 > URL: https://issues.apache.org/jira/browse/GEODE-9458 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The test should spin up multiple servers and test the functionService from > the client: > # function execution onServer/onMember > # function execution onServers/onMembers > # function execution onRegion > and make sure the expired user would re-authenticate and continue to execute > the functions in various cases > and make sure the the subsequent successful function execution is done by the > new user (not the expired one). > > test onServer, onServers, onRegions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9456) Create AuthenticationExpiredException and have the client handle that exception for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406921#comment-17406921 ] ASF subversion and git services commented on GEODE-9456: Commit 4af2badab70b0321491b2ddc4e21b8551ea5a368 in geode's branch refs/heads/develop from Joris Melchior [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4af2bad ] GEODE-9458: function execution with expiring authentication (#6789) * GEODE-9456, GEODE-9452: Authentication Expiration (#6721) * Add tests and throw AuthenticationExpiredException Co-authored-by: Joris Melchior * GEODE-9460: Add testing for mutli-user scenarios (#6755) Co-Authored-By Jinmei Liao * review update * revert accidental change * GEODE-9458: function execution with expiring authentication * Changes based on review * Changes based on review, parameterization Co-authored-by: Jinmei Liao > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > - > > Key: GEODE-9456 > URL: https://issues.apache.org/jira/browse/GEODE-9456 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > Current: Geode doesn't support any credential expiration > Desired: Optionally upon every authorization, Geode would check if the > credential has expired or not, if AuthenticationExpiredException is thrown by > the SecurityManager, Geode would throw the exception to the client. And the > client, after receiving the exception, would call "authInitialize" to get a > new set of credentials and try re-authenticating again. It should only try > this once. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9560) ECHO Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9560: -- Labels: pull-request-available (was: ) > ECHO Command Supported > -- > > Key: GEODE-9560 > URL: https://issues.apache.org/jira/browse/GEODE-9560 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers for the following command: > ECHO > +Acceptance Criteria+ > Unit/integration tests for both Geode and native Redis passing > DUNIT tests passing > README/redis_api_for_geode.html.md.erb updated to make command "supported" > or > Stories in the backlog to fix the identified issues (with JIRA tickets) and > problem tests that are ignored should be fixed and enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8970) CI failure: MicrometerBinderTest.jvmThreadMetricsBinderExists fails with NullPointerException during stopServer
[
https://issues.apache.org/jira/browse/GEODE-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406900#comment-17406900
]
Geode Integration commented on GEODE-8970:
--
Seen in [windows-acceptance-test-openjdk8
#151|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-acceptance-test-openjdk8/builds/151]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0447/test-results/acceptanceTest/1630111446/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0447/test-artifacts/1630111446/windows-acceptancetestfiles-openjdk8-1.15.0-build.0447.tgz].
> CI failure: MicrometerBinderTest.jvmThreadMetricsBinderExists fails with
> NullPointerException during stopServer
> ---
>
> Key: GEODE-8970
> URL: https://issues.apache.org/jira/browse/GEODE-8970
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.1
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.metrics.MicrometerBinderTest > jvmThreadMetricsBinderExists
> FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [5649fcaf482615ff: gfsh -e connect --jmx-manager=localhost[22864] -e deploy
> --jar=/tmp/junit654213865788865628/function.jar]] expected:<[0]> but was:<[1]>
> 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:139)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:150)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:114)
> at
> org.apache.geode.metrics.MicrometerBinderTest.startServer(MicrometerBinderTest.java:95)
> java.lang.NullPointerException
> at
> org.apache.geode.metrics.MicrometerBinderTest.stopServer(MicrometerBinderTest.java:111)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8970) CI failure: MicrometerBinderTest.jvmThreadMetricsBinderExists fails with NullPointerException during stopServer
[
https://issues.apache.org/jira/browse/GEODE-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406899#comment-17406899
]
Bill Burcham commented on GEODE-8970:
-
Seems to also happen in:
{code:java}
org.apache.geode.metrics.MicrometerBinderTest > processorMetricsBinderExists
{code}
> CI failure: MicrometerBinderTest.jvmThreadMetricsBinderExists fails with
> NullPointerException during stopServer
> ---
>
> Key: GEODE-8970
> URL: https://issues.apache.org/jira/browse/GEODE-8970
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.1
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.metrics.MicrometerBinderTest > jvmThreadMetricsBinderExists
> FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [5649fcaf482615ff: gfsh -e connect --jmx-manager=localhost[22864] -e deploy
> --jar=/tmp/junit654213865788865628/function.jar]] expected:<[0]> but was:<[1]>
> 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:139)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:150)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:114)
> at
> org.apache.geode.metrics.MicrometerBinderTest.startServer(MicrometerBinderTest.java:95)
> java.lang.NullPointerException
> at
> org.apache.geode.metrics.MicrometerBinderTest.stopServer(MicrometerBinderTest.java:111)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9551) New SNI proxy API does not conform to standards.
[
https://issues.apache.org/jira/browse/GEODE-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406842#comment-17406842
]
ASF subversion and git services commented on GEODE-9551:
Commit 74677ff51cb6612f0bbe375a694683b8ee877bde in geode-native's branch
refs/heads/support/1.14 from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=74677ff ]
GEODE-9551: Fixes API return and parameter types. (#860)
> New SNI proxy API does not conform to standards.
>
>
> Key: GEODE-9551
> URL: https://issues.apache.org/jira/browse/GEODE-9551
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> APIs should be consistent with other APIs:
> All class/struct properties should be returned {{const &}} in getters and
> copied in setters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby resolved GEODE-9528.
Resolution: Fixed
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> 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.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9554) Rebalancing a region with multiple redundancy zones can fail
[ https://issues.apache.org/jira/browse/GEODE-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson reassigned GEODE-9554: -- Assignee: Mark Hanson > Rebalancing a region with multiple redundancy zones can fail > > > Key: GEODE-9554 > URL: https://issues.apache.org/jira/browse/GEODE-9554 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.4, 1.13.4, 1.14.0, 1.15.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > > When attempting to rebalance a region with multiple redundancy zones, the > code does not distinguish between zones when deleting redundant bucket > copies. This can mean that a bucket from a different zone gets deleted > leaving the servers in a state of reduced redundancy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406829#comment-17406829
]
ASF subversion and git services commented on GEODE-9486:
Commit 3b2c5312d163f34701c3a01250491876942a6b48 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3b2c531 ]
GEODE-9486: Fix validate-serializable-objects (#6746)
Rename DistributedSystemService to SanctionedSerializablesService and
remove unused init(DistributedSystem).
Move SanctionedSerializablesService to geode-serialization.
Implement SanctionedSerializablesService in both geode-core and
geode-management to remove special case for each in
InternalDataSerializer.
Fix sanctioned serializables support in geode-management and
geode-apis-compatible-with-redis.
Add sanctioned serializables support to geode-serialization and
geode-pulse.
Add sanctioned serializables support to geode-junit and geode-dunit
to simplify writing tests for validate-serializable-objects and prevent
having to list out DUnit Rules and other test framework classes when
validate-serializable-objects is enabled.
Use ExecutorServiceRule and reformat json strings in
RestRegionAPIIntegrationTest.
Reorganize QueryCommandDUnitTestBase.
Use InvalidClassException instead of Exception in
ObjectInputStreamFilterWrapper fatal log message.
Improve assertion messages in ResourceUtils.
Move loadSanctionedSerializablesServices and loadClassNames to
new SanctionedSerializables in geode-serialization.
Exclude Pulse GemFireAuthentication from sanctioned serializables.
Add SerializationTest Category to all AnalyzeSerializables integration
tests.
Tidy up SANCTIONED_SERIALIZABLES_DEPENDENCIES_PATTERN.
Convert to AssertJ and use BeforeClass in
InternalDataSerializerSerializationAcceptlistTest.
Note: If Git or GitHub is showing invalid file renames in the diffs, you
may need to pull the branch locally and configure diff.renameLimit
to something lower than the default value of 50.
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
>
[jira] [Assigned] (GEODE-9347) Make Publish and Subscribe use Map data structures
[ https://issues.apache.org/jira/browse/GEODE-9347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-9347: --- Assignee: Darrel Schneider > Make Publish and Subscribe use Map data structures > -- > > Key: GEODE-9347 > URL: https://issues.apache.org/jira/browse/GEODE-9347 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Assignee: Darrel Schneider >Priority: Major > > our current implementation of Publish and Subscribe use a list of > Subscription objects to maintain state. > @doevans noticed that native redis is using 2 maps to maintain state > in an effort to mimic native redis data structures and hopefully improve > performance, our publish and subscribe commands should also use maps 1) > (channel -> all subscribers). 2) subsrciber(client) -> all subscribed channels > Updated 08/20/2021: > Redis handles subscriptions as follows: > * Each client object maintains a set of channels to which it is subscribed > * Each client object maintains a list of patterns to which it is subscribed > * The server maintains a map of channels -> subscribed clients > * The server maintains a list of all Pattern objects > * Each Pattern object knows which client is subscribed to it and the byte[] > pattern associated with it > On subscribe: > * Add the channel to the client's set of subscribed clients > * Add the channel to the server's map of channels -> subscribed clients > * Respond with the total number of subscribed channels and patterns for the > client (sum the sizes of the client's channel set and pattern list) > On psubscribe: > * Add the byte[] pattern to the client's list of patterns > * Create a Pattern object and add it to the server's list of Patterns > * Respond with the total number of subscribed channels and patterns for the > client (sum the sizes of the client's channel set and pattern list) > On publish: > * Notify all clients subscribed to the channel using the server's channels -> > subscribed clients map > * Notify all clients subscribed to matching channels by comparing the channel > to the server's list of all patterns using Glob-style matching > * Respond with the number of notifications sent > For our implementation, a similar approach can be used, but this will entail > significant refactoring of PubSub classes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9560) ECHO Command Supported
Wayne created GEODE-9560: Summary: ECHO Command Supported Key: GEODE-9560 URL: https://issues.apache.org/jira/browse/GEODE-9560 Project: Geode Issue Type: New Feature Components: redis Reporter: Wayne Write unit/integration tests that run against both Geode Redis and native Redis, and dunit tests which test multiple concurrent clients accessing different servers for the following command: ECHO +Acceptance Criteria+ Unit/integration tests for both Geode and native Redis passing DUNIT tests passing README/redis_api_for_geode.html.md.erb updated to make command "supported" or Stories in the backlog to fix the identified issues (with JIRA tickets) and problem tests that are ignored should be fixed and enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9368) Upgrade to lettuce library that fixes reconnection issues
[ https://issues.apache.org/jira/browse/GEODE-9368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9368. --- Resolution: Fixed > Upgrade to lettuce library that fixes reconnection issues > - > > Key: GEODE-9368 > URL: https://issues.apache.org/jira/browse/GEODE-9368 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > We found an issue with the lettuce library when doing failover testing: > https://github.com/lettuce-io/lettuce-core/discussions/1757 > Wait until this change is merged into a released version of lettuce and > update all tests disabled due to this problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9460) add tests for multi-user mode when one user expires
[ https://issues.apache.org/jira/browse/GEODE-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-9460: -- Description: Current state: Currently an established client connection does not time out New state: Client connections can be subject to time out depending on the security manager implementation and client code should be able to handle re-authentication of client connections. Things to test: * Test multi-user connections and ensure that when one specific user times out this user is forced to re-authenticate * Confirm re-authentication on both new version and versions of the client in pre 1.13.3 releases * Confirm the behaviour in single and multi-server environments was: make sure the behavior matches expectations make sure to include tests in multi-server cases > add tests for multi-user mode when one user expires > --- > > Key: GEODE-9460 > URL: https://issues.apache.org/jira/browse/GEODE-9460 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Current state: > Currently an established client connection does not time out > New state: > Client connections can be subject to time out depending on the security > manager implementation and client code should be able to handle > re-authentication of client connections. > Things to test: > * Test multi-user connections and ensure that when one specific user times > out this user is forced to re-authenticate > * Confirm re-authentication on both new version and versions of the client > in pre 1.13.3 releases > * Confirm the behaviour in single and multi-server environments > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9460) add tests for multi-user mode when one user expires
[ https://issues.apache.org/jira/browse/GEODE-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior reassigned GEODE-9460: - Assignee: Joris Melchior > add tests for multi-user mode when one user expires > --- > > Key: GEODE-9460 > URL: https://issues.apache.org/jira/browse/GEODE-9460 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > make sure the behavior matches expectations > > make sure to include tests in multi-server cases -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9459) add tests for wan connection when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406752#comment-17406752 ] Joris Melchior commented on GEODE-9459: --- Do we allow WAN connections of clusters with different versions? Do we handle upgrades of clusters on the fly? > add tests for wan connection when authentication expires > > > Key: GEODE-9459 > URL: https://issues.apache.org/jira/browse/GEODE-9459 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > Current state: > WAN connections do not time out and once established remain in place once > authenticated > New state: > WAN connections may be subject to timeout and when a WAN connection times out > it will receive a `AuthenticationExpiredException` exception in response to > an attempt to send a batch of events from a Gateway sender to a Gateway > receiver. > Testing tasks: > * Confirm the new state behaviour on both newer systems and systems of > version 1.13.3 and older. > * On newer systems the Gateway sender should automatically re-authenticate > when getting the `AuthenticationExpiredException` > * On older systems the Gateway sender should receive an > `AuthenticationRequiredException` as the `server` side recognizes an older > `client` and translates the `AuthenticationExpiredException`. The Gateway > sender should automatically authenticate in this case too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9459) add tests for wan connection when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-9459: -- Description: Current state: WAN connections do not time out and once established remain in place once authenticated New state: WAN connections may be subject to timeout and when a WAN connection times out it will receive a `AuthenticationExpiredException` exception in response to an attempt to send a batch of events from a Gateway sender to a Gateway receiver. Testing tasks: * Confirm the new state behaviour on both newer systems and systems of version 1.13.3 and older. * On newer systems the Gateway sender should automatically re-authenticate when getting the `AuthenticationExpiredException` * On older systems the Gateway sender should receive an `AuthenticationRequiredException` as the `server` side recognizes an older `client` and translates the `AuthenticationExpiredException`. The Gateway sender should automatically authenticate in this case too. was:make sure the behavior matches expections. > add tests for wan connection when authentication expires > > > Key: GEODE-9459 > URL: https://issues.apache.org/jira/browse/GEODE-9459 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > Current state: > WAN connections do not time out and once established remain in place once > authenticated > New state: > WAN connections may be subject to timeout and when a WAN connection times out > it will receive a `AuthenticationExpiredException` exception in response to > an attempt to send a batch of events from a Gateway sender to a Gateway > receiver. > Testing tasks: > * Confirm the new state behaviour on both newer systems and systems of > version 1.13.3 and older. > * On newer systems the Gateway sender should automatically re-authenticate > when getting the `AuthenticationExpiredException` > * On older systems the Gateway sender should receive an > `AuthenticationRequiredException` as the `server` side recognizes an older > `client` and translates the `AuthenticationExpiredException`. The Gateway > sender should automatically authenticate in this case too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
