[jira] [Commented] (GEODE-10227) Remove Redundant Calls to sendRequestForChunkedResponse
[
https://issues.apache.org/jira/browse/GEODE-10227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524716#comment-17524716
]
ASF GitHub Bot commented on GEODE-10227:
mmartell merged PR #957:
URL: https://github.com/apache/geode-native/pull/957
> Remove Redundant Calls to sendRequestForChunkedResponse
> ---
>
> Key: GEODE-10227
> URL: https://issues.apache.org/jira/browse/GEODE-10227
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> TcrEndpoint::sendRequestConn contains redundant calls to
> TcrConnection::sendRequestForChunkedResponse which should be removed. The
> current code is illustrated by the following:
> {code:java}
> if (messageType == a || messageType == b)
> sendRequestForChunkedResponse()
> else
> sendRequestForChunkedResponse(){code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10227) Remove Redundant Calls to sendRequestForChunkedResponse
[
https://issues.apache.org/jira/browse/GEODE-10227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524717#comment-17524717
]
ASF subversion and git services commented on GEODE-10227:
-
Commit 1d9a2cc5feb72f3c5d2caa97f3208a381c04afd6 in geode-native's branch
refs/heads/develop from Michael Martell
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=1d9a2cc5f ]
GEODE-10227: Remove redundant sendRequestForChunkedResponse (#957)
* Remove redundant sendRequestForChunkedResponse
* Remove vestigial comment
> Remove Redundant Calls to sendRequestForChunkedResponse
> ---
>
> Key: GEODE-10227
> URL: https://issues.apache.org/jira/browse/GEODE-10227
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> TcrEndpoint::sendRequestConn contains redundant calls to
> TcrConnection::sendRequestForChunkedResponse which should be removed. The
> current code is illustrated by the following:
> {code:java}
> if (messageType == a || messageType == b)
> sendRequestForChunkedResponse()
> else
> sendRequestForChunkedResponse(){code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10246) OutOfMemoryDUnitTest throws JedisDataException on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10246:
---
Labels: Java17 pull-request-available (was: Java17)
> OutOfMemoryDUnitTest throws JedisDataException on JDK17
> ---
>
> Key: GEODE-10246
> URL: https://issues.apache.org/jira/browse/GEODE-10246
> Project: Geode
> Issue Type: Improvement
> Components: redis, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
>
> These three OutOfMemoryDUnitTest tests fail on JDK17:
> * shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold
> * shouldReturnOOMError_forPublish_whenThresholdReached
> * shouldReturnOOMError_forSubscribe_whenThresholdReached
> The Concurrent Mark Sweep (CMS) garbage collector does not exist on JDK17.
> My hunch is that the test code relies on CMS-like behavior to establish "over
> the memory threshold" conditions for the test.
> Example test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7590/test-results/distributedTest/1650326807/
> Example stack trace:
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError:
> Expecting message to be:
> "OOM command not allowed when used memory > 'maxmemory'"
> but was:
> "ERR The server had an internal error please try again"
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisDataException: ERR The server had an
> internal error please try again
> at redis.clients.jedis.Protocol.processError(Protocol.java:96)
> at redis.clients.jedis.Protocol.process(Protocol.java:137)
> at redis.clients.jedis.Protocol.read(Protocol.java:192)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316)
> at redis.clients.jedis.Connection.getOne(Connection.java:298)
> at redis.clients.jedis.Connection.executeCommand(Connection.java:123)
> at
> redis.clients.jedis.executors.ClusterCommandExecutor.executeCommand(ClusterCommandExecutor.java:57)
> at
> redis.clients.jedis.UnifiedJedis.executeCommand(UnifiedJedis.java:139)
> at redis.clients.jedis.UnifiedJedis.set(UnifiedJedis.java:491)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$fillServer1Memory$39(OutOfMemoryDUnitTest.java:359)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:63)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:878)
> at org.assertj.core.api.Assertions.catchThrowable(Assertions.java:1337)
> at
> org.assertj.core.api.Assertions.assertThatThrownBy(Assertions.java:1181)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:352)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:289)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at
[jira] [Resolved] (GEODE-10246) OutOfMemoryDUnitTest throws JedisDataException on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10246.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> OutOfMemoryDUnitTest throws JedisDataException on JDK17
> ---
>
> Key: GEODE-10246
> URL: https://issues.apache.org/jira/browse/GEODE-10246
> Project: Geode
> Issue Type: Improvement
> Components: redis, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> These three OutOfMemoryDUnitTest tests fail on JDK17:
> * shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold
> * shouldReturnOOMError_forPublish_whenThresholdReached
> * shouldReturnOOMError_forSubscribe_whenThresholdReached
> The Concurrent Mark Sweep (CMS) garbage collector does not exist on JDK17.
> My hunch is that the test code relies on CMS-like behavior to establish "over
> the memory threshold" conditions for the test.
> Example test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7590/test-results/distributedTest/1650326807/
> Example stack trace:
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError:
> Expecting message to be:
> "OOM command not allowed when used memory > 'maxmemory'"
> but was:
> "ERR The server had an internal error please try again"
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisDataException: ERR The server had an
> internal error please try again
> at redis.clients.jedis.Protocol.processError(Protocol.java:96)
> at redis.clients.jedis.Protocol.process(Protocol.java:137)
> at redis.clients.jedis.Protocol.read(Protocol.java:192)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316)
> at redis.clients.jedis.Connection.getOne(Connection.java:298)
> at redis.clients.jedis.Connection.executeCommand(Connection.java:123)
> at
> redis.clients.jedis.executors.ClusterCommandExecutor.executeCommand(ClusterCommandExecutor.java:57)
> at
> redis.clients.jedis.UnifiedJedis.executeCommand(UnifiedJedis.java:139)
> at redis.clients.jedis.UnifiedJedis.set(UnifiedJedis.java:491)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$fillServer1Memory$39(OutOfMemoryDUnitTest.java:359)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:63)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:878)
> at org.assertj.core.api.Assertions.catchThrowable(Assertions.java:1337)
> at
> org.assertj.core.api.Assertions.assertThatThrownBy(Assertions.java:1181)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:352)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:289)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at
[jira] [Commented] (GEODE-10246) OutOfMemoryDUnitTest throws JedisDataException on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524668#comment-17524668
]
ASF subversion and git services commented on GEODE-10246:
-
Commit 89a6112844fdc07e85aa11ed67cbb1808b09569e in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=89a6112844 ]
GEODE-10246: fix OutOfMemoryDUnitTest for jdk17 (#7606)
* test now uses ZGC on jdk17
* product change: added ZHeap to the list of known memoryPoolMXBeans
> OutOfMemoryDUnitTest throws JedisDataException on JDK17
> ---
>
> Key: GEODE-10246
> URL: https://issues.apache.org/jira/browse/GEODE-10246
> Project: Geode
> Issue Type: Improvement
> Components: redis, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
>
> These three OutOfMemoryDUnitTest tests fail on JDK17:
> * shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold
> * shouldReturnOOMError_forPublish_whenThresholdReached
> * shouldReturnOOMError_forSubscribe_whenThresholdReached
> The Concurrent Mark Sweep (CMS) garbage collector does not exist on JDK17.
> My hunch is that the test code relies on CMS-like behavior to establish "over
> the memory threshold" conditions for the test.
> Example test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7590/test-results/distributedTest/1650326807/
> Example stack trace:
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError:
> Expecting message to be:
> "OOM command not allowed when used memory > 'maxmemory'"
> but was:
> "ERR The server had an internal error please try again"
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisDataException: ERR The server had an
> internal error please try again
> at redis.clients.jedis.Protocol.processError(Protocol.java:96)
> at redis.clients.jedis.Protocol.process(Protocol.java:137)
> at redis.clients.jedis.Protocol.read(Protocol.java:192)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316)
> at redis.clients.jedis.Connection.getOne(Connection.java:298)
> at redis.clients.jedis.Connection.executeCommand(Connection.java:123)
> at
> redis.clients.jedis.executors.ClusterCommandExecutor.executeCommand(ClusterCommandExecutor.java:57)
> at
> redis.clients.jedis.UnifiedJedis.executeCommand(UnifiedJedis.java:139)
> at redis.clients.jedis.UnifiedJedis.set(UnifiedJedis.java:491)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$fillServer1Memory$39(OutOfMemoryDUnitTest.java:359)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:63)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:878)
> at org.assertj.core.api.Assertions.catchThrowable(Assertions.java:1337)
> at
> org.assertj.core.api.Assertions.assertThatThrownBy(Assertions.java:1181)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:352)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:289)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
>
[jira] [Updated] (GEODE-10251) DescribedExternalResource hides test failure if after throws
[ https://issues.apache.org/jira/browse/GEODE-10251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-10251: --- Labels: Java17 pull-request-available (was: pull-request-available) > DescribedExternalResource hides test failure if after throws > > > Key: GEODE-10251 > URL: https://issues.apache.org/jira/browse/GEODE-10251 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > > If DescribedExternalResource.after() throws, any other exception thrown by > the statement is lost. This discards any exception thrown by a test or by a > rule further down the rule chain. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10247) CI: spring-compatibility-test compile failure
[ https://issues.apache.org/jira/browse/GEODE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10247: -- Labels: needsTriage redis-triage (was: needsTriage) > CI: spring-compatibility-test compile failure > - > > Key: GEODE-10247 > URL: https://issues.apache.org/jira/browse/GEODE-10247 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage, redis-triage > > It's found in > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14671910 > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293 > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643323 > ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (java-compile) > on project spring-data-geode: Compilation failure: Compilation failure: > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[103,43] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_BIND_ADDRESS > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[104,38] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_ENABLED > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[105,35] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_PORT > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[106,47] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_REDUNDANT_COPIES > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[107,39] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_USERNAME > [ERROR] location: interface ConfigurationProperties -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524636#comment-17524636
]
Donal Evans commented on GEODE-9880:
Some preliminary findings and questions following investigation of this issue
and talking with [~burcham], who knows membership code better than Patrick or
me:
On the client, if we have a locator with only an IP address defined and the
same locator is returned in the locator response with only a hostname defined,
then it is not possible to detect the duplicate without either a forward or
reverse lookup using DNS. Because of this, there is no way to prevent the
hostname-only locator from being added to the list of locators on the client
and then being used and causing the NPE first described.
If hostname-for-clients is configured and set to be an IP address, we follow
the code path shown in [the stack trace in this
comment|https://issues.apache.org/jira/browse/GEODE-9880?focusedCommentId=17460501=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17460501].
SNIHostName requires a valid domain name to be passed into the constructor in
SocketCreator. We attempt to resolve IP addresses to hostnames prior to
invoking the SNIHostName constructor, but if we can't, then we use the IP
address as a hostname. For IPv4, this succeeds, because the format of an IPv4
address is the same as the format of a valid domain name (characters separated
by periods), and so we're able to create the SNIHostName and set it (even
though we may not be using SNI). For IPv6, the constructor will throw, as seen
in the above stack trace.
>From 1.14 onward, the code in both these areas has been reworked
>significantly, so it appears that the originally described NPE may not be
>possible, although the client may still be unable to contact the locator or
>hit an exception elsewhere.
Questions:
Should we make the SNIHostName use conditional on whether you're actually using
SNI? This might allow the hostname-for-clients workaround to work for IPv6
environments, but might not solve the problem if the user wanted to use SNI
*and* could not resolve hostnames to IP addresses or vice versa on the client.
Should working name resolution be required in all cases? Is it a valid
configuration of Geode to allow clients to connect to a cluster without being
able to access the DNS used by members of the cluster?
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership,
> pull-request-available
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10251) DescribedExternalResource hides test failure if after throws
[ https://issues.apache.org/jira/browse/GEODE-10251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery reassigned GEODE-10251: -- Assignee: Dale Emery > DescribedExternalResource hides test failure if after throws > > > Key: GEODE-10251 > URL: https://issues.apache.org/jira/browse/GEODE-10251 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: pull-request-available > > If DescribedExternalResource.after() throws, any other exception thrown by > the statement is lost. This discards any exception thrown by a test or by a > rule further down the rule chain. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10250) The LockGrantor can grant a lock to a member that has left the distributed system
[ https://issues.apache.org/jira/browse/GEODE-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10250: --- Labels: needsTriage pull-request-available (was: needsTriage) > The LockGrantor can grant a lock to a member that has left the distributed > system > - > > Key: GEODE-10250 > URL: https://issues.apache.org/jira/browse/GEODE-10250 > Project: Geode > Issue Type: Bug > Components: distributed lock service >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: needsTriage, pull-request-available > > If a member requests a distributed lock and then leaves the distributed > system, the grantor may grant that request and leave itself in a state where > the lock has been granted but the member has left. > Here are the steps: > # The lock requesting server requests a lock > # The grantor server is delayed in granting that lock > # The lock requesting server shutsdown in the meantime > # The grantor server finally grants the lock after it has released all locks > and pending requests for the lock requesting server > # The lock requesting server receives the lock response but drops it since > the thread pool has been already shutdown -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9466) ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524629#comment-17524629
]
Darrel Schneider commented on GEODE-9466:
-
For this code to work on jdk17 in the 1.15 release "java.nio" needs to be
opened.
> ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
> --
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> ByteBufferInputStream.OffHeapByteSource has a method determineUnaligned that
> will always fail on java 16 and later. This is because it calls
> Method.setAccessible which is not allowed under normal conditions starting
> with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9466:
Labels: Java16 Java17 (was: Java16)
> ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
> --
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> ByteBufferInputStream.OffHeapByteSource has a method determineUnaligned that
> will always fail on java 16 and later. This is because it calls
> Method.setAccessible which is not allowed under normal conditions starting
> with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9467) pdx ReflectionBasedAutoSerializer will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9467: Labels: Java16 Java17 (was: Java16) > pdx ReflectionBasedAutoSerializer will fail on java 16 and later > > > Key: GEODE-9467 > URL: https://issues.apache.org/jira/browse/GEODE-9467 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The pdx ReflectionBasedAutoSerializer will not work on java 16 and later > because it calls Field.setAccessible which is not allowed under normal > conditions starting with java 16 (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16|https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/] > > [).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] > To workaround this failure set the JVM command line option: > --illegal-access=permit > The call is made in > org.apache.geode.pdx.internal.AutoSerializableManager#getClassInfo and is > required for the auto serializer to function correctly. > > > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524628#comment-17524628 ] Darrel Schneider commented on GEODE-9471: - For 1.15 the current implementation requires an add-opens of "java.lang" for the ThreadLocal class's privates. > gfsh show dead-locks will fail on java 16 and later > --- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9471: Labels: Java16 Java17 (was: Java16) > gfsh show dead-locks will fail on java 16 and later > --- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9470) Some geode queries will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522985#comment-17522985 ] Darrel Schneider edited comment on GEODE-9470 at 4/19/22 11:29 PM: --- These setAccessible calls should not be an issue with geode 1.15 since any domain classes added by the user to the server's class path will need to not be in named modules so they will automatically be open to geode since both will be in the unnamed module. But we need to decide if we want to support user classes that are in named modules for 1.15. If so then users will need to do an add-opens was (Author: dschneider): These setAccessible calls should not be an issue with geode 1.15 since any domain classes added by the user to the server's class path will need to not be in named modules so they will automatically be open to geode since both will be in the unnamed module. > Some geode queries will fail on java 16 and later > - > > Key: GEODE-9470 > URL: https://issues.apache.org/jira/browse/GEODE-9470 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In some cases a geode query uses reflection to read a field or call a > function. > If that happens on java 16 then the query will fail throwing a > RuntimeException that is an instance of > java.lang.reflect.InaccessibleObjectException. See: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16. > To workaround this failure set the JVM command line option: > --illegal-access=permit > The query code that calls setAccessible is in two places: > org.apache.geode.cache.query.internal.AttributeDescriptor#getReadMember > org.apache.geode.cache.query.internal.MethodDispatch#MethodDispatch -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9470) Some geode queries will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9470: Labels: Java16 Java17 (was: Java16) > Some geode queries will fail on java 16 and later > - > > Key: GEODE-9470 > URL: https://issues.apache.org/jira/browse/GEODE-9470 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In some cases a geode query uses reflection to read a field or call a > function. > If that happens on java 16 then the query will fail throwing a > RuntimeException that is an instance of > java.lang.reflect.InaccessibleObjectException. See: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16. > To workaround this failure set the JVM command line option: > --illegal-access=permit > The query code that calls setAccessible is in two places: > org.apache.geode.cache.query.internal.AttributeDescriptor#getReadMember > org.apache.geode.cache.query.internal.MethodDispatch#MethodDispatch -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9468) tomcat session state management will not work on java 16
[ https://issues.apache.org/jira/browse/GEODE-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9468. - Resolution: Not A Problem > tomcat session state management will not work on java 16 > > > Key: GEODE-9468 > URL: https://issues.apache.org/jira/browse/GEODE-9468 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > The class org.apache.geode.modules.session.catalina.DeltaSession calls > Field.setAccessible in a static block. It is getting access to a field in the > super class which was private in tomcat 7 (see GEODE-3434). Because of this > tomcat session state management will not work on java 16 (see > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/)] > unless jvm args are used to permit the call (for example > "--illegal-access=permit"). > If we can drop support for tomcat 7 then this reflection would no longer be > needed. It might also be possible to only call setAccessible if the field is > private which would mean only tomcat 7 would not work on java 16. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9469) CopyHelper.copy will fail on java 16 and later when copying instances of Clonable
[ https://issues.apache.org/jira/browse/GEODE-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9469: Labels: Java16 Java17 (was: Java16) > CopyHelper.copy will fail on java 16 and later when copying instances of > Clonable > - > > Key: GEODE-9469 > URL: https://issues.apache.org/jira/browse/GEODE-9469 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > CopyHelper.copy is an API that allows geode users to make copies of objects. > It is also used internally by a number of geode features. The copy-on-read > region attribute is one example. If the object being copied is an instance of > Cloneable then on java 16, copy will throw a RuntimeException which is an > instance of java.lang.reflect.InaccessibleObjectException. > The copy code tries to catch exceptions during the clone and instead use > serialization to make a copy but it does not catch RuntimeException which is > what java 16 throws from setAccessible. It would be pretty easy to fix this > exception handling. > The only work arounds are to not implement Cloneable or to start the jvm with > the command line option: --illegal-access=permit. > See: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16|https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/] > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10228:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9473) Geode deserialization will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9473: Labels: Java16 Java17 (was: Java16) > Geode deserialization will fail on java 16 > -- > > Key: GEODE-9473 > URL: https://issues.apache.org/jira/browse/GEODE-9473 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In three different places geode deserialization calls setAccessible in order > to make the constructor callable. This will not work on java 16 and later > because it calls Field.setAccessible which is not allowed under normal > conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls for deserialization are: > * org.apache.geode.internal.InternalDataSerializer#newInstance > * org.apache.geode.internal.InternalDataSerializer#readDataSerializable > * org.apache.geode.internal.InternalInstantiator#newInstance -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9475) ObjectSizer will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9475: Labels: Java16 Java17 (was: Java16) > ObjectSizer will fail on java 16 and later > -- > > Key: GEODE-9475 > URL: https://issues.apache.org/jira/browse/GEODE-9475 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The instances of org.apache.geode.cache.util.ObjectSizer, SIZE_CLASS_ONCE, > REFLECTION_SIZE, and DEFAULT will not work on java 16 and later because they > call Field.setAccessible which is not allowed under normal conditions > starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit > These ObjectSizer instances are used in a number of places internally by > geode and can also explicitly be configured by users. Internally they are > used by default for eviction (heap or mem), the wan gateway, and tombstone > gc. Most all regions produce tombstones so that is the most likely point of > failure. > The code that calls setAccessible is: > org.apache.geode.internal.size.ObjectTraverser#buildFieldSet and it is not > clear how this code can be changed to do its job without using setAccessible. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522983#comment-17522983 ] Darrel Schneider edited comment on GEODE-9474 at 4/19/22 11:25 PM: --- For Java17 we need the server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. was (Author: dschneider): For Java17 we need to server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10251) DescribedExternalResource hides test failure if after throws
[ https://issues.apache.org/jira/browse/GEODE-10251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10251: --- Labels: pull-request-available (was: ) > DescribedExternalResource hides test failure if after throws > > > Key: GEODE-10251 > URL: https://issues.apache.org/jira/browse/GEODE-10251 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Priority: Major > Labels: pull-request-available > > If DescribedExternalResource.after() throws, any other exception thrown by > the statement is lost. This discards any exception thrown by a test or by a > rule further down the rule chain. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9477) Geode membership will have issues on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9477. - Resolution: Not A Problem > Geode membership will have issues on java 16 and later > -- > > Key: GEODE-9477 > URL: https://issues.apache.org/jira/browse/GEODE-9477 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > Geode membership uses setAccessible in a number of places to access jgroups > internals. > This will not work on java 16 and later (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16). > A workaround for this bug is to start the jvm with --illegal-access=permit > The places that call setAccessible in membership are: > * > org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager#findPingDataMethod > (the catch in this method will not catch the RuntimeException thrown by > setAccessible) > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#setChannelReceiver > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#start > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#checkForIPv6 > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#establishLocalAddress -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10251) DescribedExternalResource hides test failure if after throws
Dale Emery created GEODE-10251: -- Summary: DescribedExternalResource hides test failure if after throws Key: GEODE-10251 URL: https://issues.apache.org/jira/browse/GEODE-10251 Project: Geode Issue Type: Improvement Components: tests Affects Versions: 1.15.0 Reporter: Dale Emery If DescribedExternalResource.after() throws, any other exception thrown by the statement is lost. This discards any exception thrown by a test or by a rule further down the rule chain. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10250) The LockGrantor can grant a lock to a member that has left the distributed system
[ https://issues.apache.org/jira/browse/GEODE-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10250: -- Labels: needsTriage (was: ) > The LockGrantor can grant a lock to a member that has left the distributed > system > - > > Key: GEODE-10250 > URL: https://issues.apache.org/jira/browse/GEODE-10250 > Project: Geode > Issue Type: Bug > Components: distributed lock service >Reporter: Barrett Oglesby >Priority: Major > Labels: needsTriage > > If a member requests a distributed lock and then leaves the distributed > system, the grantor may grant that request and leave itself in a state where > the lock has been granted but the member has left. > Here are the steps: > # The lock requesting server requests a lock > # The grantor server is delayed in granting that lock > # The lock requesting server shutsdown in the meantime > # The grantor server finally grants the lock after it has released all locks > and pending requests for the lock requesting server > # The lock requesting server receives the lock response but drops it since > the thread pool has been already shutdown -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10250) The LockGrantor can grant a lock to a member that has left the distributed system
[ https://issues.apache.org/jira/browse/GEODE-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrett Oglesby reassigned GEODE-10250: --- Assignee: Barrett Oglesby > The LockGrantor can grant a lock to a member that has left the distributed > system > - > > Key: GEODE-10250 > URL: https://issues.apache.org/jira/browse/GEODE-10250 > Project: Geode > Issue Type: Bug > Components: distributed lock service >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: needsTriage > > If a member requests a distributed lock and then leaves the distributed > system, the grantor may grant that request and leave itself in a state where > the lock has been granted but the member has left. > Here are the steps: > # The lock requesting server requests a lock > # The grantor server is delayed in granting that lock > # The lock requesting server shutsdown in the meantime > # The grantor server finally grants the lock after it has released all locks > and pending requests for the lock requesting server > # The lock requesting server receives the lock response but drops it since > the thread pool has been already shutdown -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10250) The LockGrantor can grant a lock to a member that has left the distributed system
Barrett Oglesby created GEODE-10250: --- Summary: The LockGrantor can grant a lock to a member that has left the distributed system Key: GEODE-10250 URL: https://issues.apache.org/jira/browse/GEODE-10250 Project: Geode Issue Type: Bug Components: distributed lock service Reporter: Barrett Oglesby If a member requests a distributed lock and then leaves the distributed system, the grantor may grant that request and leave itself in a state where the lock has been granted but the member has left. Here are the steps: # The lock requesting server requests a lock # The grantor server is delayed in granting that lock # The lock requesting server shutsdown in the meantime # The grantor server finally grants the lock after it has released all locks and pending requests for the lock requesting server # The lock requesting server receives the lock response but drops it since the thread pool has been already shutdown -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Apache Geode
provided, internal Web apps need to be updated as well (to use the new Jakarta
EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) itself, is highly useful and
valuable in certain configuration arrangements.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Apache Geode
provided, internal Web apps need to be updated as well (to use the new Jakarta
EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. A proper SPI affords any application, framework, tool or product a
> degree of extensibility and flexibility, applied by users without
> intervention by being able to "provide" a custom implementation or extension
> as needed by the application, framework, tool or product.
> 1 such example would be
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Apache Geode
provided, internal Web apps need to be updated as well (to use the new Jakarta
EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Web apps need to
be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. A proper SPI affords any application, framework, tool or product a
> degree of extensibility and flexibility, applied by users without
> intervention by being able to "provide" a custom implementation or extension
> as needed by the application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (specification)
> compliant implementation of an embedded HTTP
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (specification)
compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer REST
API) when external hosting is not an option. Of course, these Web apps need to
be updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. A proper SPI affords any application, framework, tool or product a
> degree of extensibility and flexibility, applied by users without
> intervention by being able to "provide" a custom implementation or extension
> as needed by the application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (specification)
> compliant implementation of an embedded HTTP server (e.g. Jetty, Tomcat or
> even
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. A proper SPI affords any application, framework, tool or product a
degree of extensibility and flexibility, applied by users without intervention
by being able to "provide" a custom implementation or extension as needed by
the application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. A proper SPI affords any application, framework, tool or product a
> degree of extensibility and flexibility, applied by users without
> intervention by being able to "provide" a custom implementation or extension
> as needed by the application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10007:
--
Description:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
was:
The {{HttpService}} interface is defined and used as a _Service Provider
Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
{{ServerLoader}}
([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
class in order to locate and load provider implementations.
An SPI is not much good if "providers" are not allowed to "provide" an
implementation of the service interfaces used to extend or customize Apache
Geode. This allows any application, framework, tool or product a degree of
extensibility and flexibility, afforded to users without intervention, by being
able to "provide" a custom implementation or extension as needed by the
application, framework, tool or product.
1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even Undertow)
used by Geode to bootstrap the embedded HTTP service hosting the Geode provided
Web apps (e.g. Pulse, Management/Admin REST API, Developer REST API) when
external hosting is not an option. Of course, these Web apps need to be
updated as well (to use the new Jakarta EE 9 specs).
There are other examples of SPIs used in Apache Geode, which are part of the
non-internal, public API.
For example, the
[ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
interface, with 1 such
[implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
provided by _Spring Data for Apache Geode_ (SDG) even.
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such with _Java's_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention, by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the
[jira] [Updated] (GEODE-8258) Cannot implement PdxInstance and store in a Region
[
https://issues.apache.org/jira/browse/GEODE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8258:
-
Priority: Major (was: Minor)
> Cannot implement PdxInstance and store in a Region
> --
>
> Key: GEODE-8258
> URL: https://issues.apache.org/jira/browse/GEODE-8258
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.9.2, 1.10.0, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
> registry, it is not currently possible to implement the
> [{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
> interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9397) Gfsh `deploy jar` should introspect, identify, and invoke/initialize all Declarable objects
[ https://issues.apache.org/jira/browse/GEODE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-9397: - Priority: Major (was: Minor) > Gfsh `deploy jar` should introspect, identify, and invoke/initialize all > Declarable objects > --- > > Key: GEODE-9397 > URL: https://issues.apache.org/jira/browse/GEODE-9397 > Project: Geode > Issue Type: New Feature > Components: core >Affects Versions: 1.13.2 >Reporter: John Blum >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524610#comment-17524610
]
John Blum edited comment on GEODE-10005 at 4/19/22 10:21 PM:
-
I am downgrading this Issue from "_Blocker_" to "_Major_" as I have provided a
[workaround|https://github.com/spring-projects/spring-boot-data-geode/issues/116]
in _*Spring Boot for Apache Geode*_ (SBDG) {{2.0}}, which successfully rebases
*Apache Geode* {{1.14.4}} on *Jetty* {{11}}, as declared and managed by _Spring
Boot_ {{3.0}}, upon which SBDG {{2.0}} is based.
was (Author: jblum):
I am downgrading this Issue from "_Blocker_" to "_Major_" as I have provided a
[workaround|https://github.com/spring-projects/spring-boot-data-geode/issues/116]
in _*Spring Boot for Apache Geode*_ (SBDG) `2.0`, which successfully rebases
*Apache Geode* `1.14.4` on *Jetty* `11`, as declared and managed by _Spring
Boot_ `3.0`, upon which SBDG `2.0` is based.
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Major
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524610#comment-17524610
]
John Blum commented on GEODE-10005:
---
I am downgrading this Issue from "_Blocker_" to "_Major_" as I have provided a
[workaround|https://github.com/spring-projects/spring-boot-data-geode/issues/116]
in _*Spring Boot for Apache Geode*_ (SBDG) `2.0`, which successfully rebases
*Apache Geode* `1.14.4` on *Jetty* `11`, as declared and managed by _Spring
Boot_ `3.0`, upon which SBDG `2.0` is based.
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Major
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10005:
--
Priority: Major (was: Blocker)
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Major
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum resolved GEODE-10045.
---
Resolution: Invalid
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum closed GEODE-10045.
-
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum reassigned GEODE-10045:
-
Assignee: John Blum
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Assignee: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum reassigned GEODE-10045:
-
Assignee: (was: John Blum)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Affects Version/s: 1.14.4
(was: 1.14.3)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.4
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524607#comment-17524607
]
John Blum commented on GEODE-10045:
---
No longer applicable now that Micrometer `2.0` is being reverted back to
Micrometer `1.10`.
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10246) OutOfMemoryDUnitTest throws JedisDataException on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10246:
Assignee: Darrel Schneider
> OutOfMemoryDUnitTest throws JedisDataException on JDK17
> ---
>
> Key: GEODE-10246
> URL: https://issues.apache.org/jira/browse/GEODE-10246
> Project: Geode
> Issue Type: Improvement
> Components: redis, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17
>
> These three OutOfMemoryDUnitTest tests fail on JDK17:
> * shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold
> * shouldReturnOOMError_forPublish_whenThresholdReached
> * shouldReturnOOMError_forSubscribe_whenThresholdReached
> The Concurrent Mark Sweep (CMS) garbage collector does not exist on JDK17.
> My hunch is that the test code relies on CMS-like behavior to establish "over
> the memory threshold" conditions for the test.
> Example test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7590/test-results/distributedTest/1650326807/
> Example stack trace:
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError:
> Expecting message to be:
> "OOM command not allowed when used memory > 'maxmemory'"
> but was:
> "ERR The server had an internal error please try again"
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisDataException: ERR The server had an
> internal error please try again
> at redis.clients.jedis.Protocol.processError(Protocol.java:96)
> at redis.clients.jedis.Protocol.process(Protocol.java:137)
> at redis.clients.jedis.Protocol.read(Protocol.java:192)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316)
> at redis.clients.jedis.Connection.getOne(Connection.java:298)
> at redis.clients.jedis.Connection.executeCommand(Connection.java:123)
> at
> redis.clients.jedis.executors.ClusterCommandExecutor.executeCommand(ClusterCommandExecutor.java:57)
> at
> redis.clients.jedis.UnifiedJedis.executeCommand(UnifiedJedis.java:139)
> at redis.clients.jedis.UnifiedJedis.set(UnifiedJedis.java:491)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$fillServer1Memory$39(OutOfMemoryDUnitTest.java:359)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:63)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:878)
> at org.assertj.core.api.Assertions.catchThrowable(Assertions.java:1337)
> at
> org.assertj.core.api.Assertions.assertThatThrownBy(Assertions.java:1181)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:352)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:289)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at
[jira] [Commented] (GEODE-10227) Remove Redundant Calls to sendRequestForChunkedResponse
[
https://issues.apache.org/jira/browse/GEODE-10227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524571#comment-17524571
]
ASF GitHub Bot commented on GEODE-10227:
pivotal-jbarrett commented on code in PR #957:
URL: https://github.com/apache/geode-native/pull/957#discussion_r853452024
##
cppcache/src/TcrEndpoint.cpp:
##
@@ -754,42 +754,36 @@ GfErrType TcrEndpoint::sendRequestConn(const TcrMessage&
request,
// TcrMessage * req = const_cast();
LOGDEBUG("TcrEndpoint::sendRequestConn = %p", m_baseDM);
if (m_baseDM != nullptr) m_baseDM->beforeSendingRequest(request, conn);
- if (((type == TcrMessage::EXECUTE_FUNCTION ||
-type == TcrMessage::EXECUTE_REGION_FUNCTION) &&
- (request.hasResult() & 2))) {
-conn->sendRequestForChunkedResponse(request, request.getMsgLength(), reply,
-request.getTimeout(),
-reply.getTimeout());
- } else if (type == TcrMessage::REGISTER_INTEREST_LIST ||
- type == TcrMessage::REGISTER_INTEREST ||
- type == TcrMessage::QUERY ||
- type == TcrMessage::QUERY_WITH_PARAMETERS ||
- type == TcrMessage::GET_ALL_70 ||
- type == TcrMessage::GET_ALL_WITH_CALLBACK ||
- type == TcrMessage::PUTALL ||
- type == TcrMessage::PUT_ALL_WITH_CALLBACK ||
- type == TcrMessage::REMOVE_ALL ||
- ((type == TcrMessage::EXECUTE_FUNCTION ||
- type == TcrMessage::EXECUTE_REGION_FUNCTION) &&
- (request.hasResult() & 2)) ||
- type ==
- TcrMessage::EXECUTE_REGION_FUNCTION_SINGLE_HOP || // This is
-// kept
-// aside as
-// server
-// always
-// sends
-// chunked
-//
response.
- type == TcrMessage::EXECUTECQ_MSG_TYPE ||
- type == TcrMessage::STOPCQ_MSG_TYPE ||
- type == TcrMessage::CLOSECQ_MSG_TYPE ||
- type == TcrMessage::KEY_SET ||
- type == TcrMessage::CLOSECLIENTCQS_MSG_TYPE ||
- type == TcrMessage::GETCQSTATS_MSG_TYPE ||
- type == TcrMessage::MONITORCQ_MSG_TYPE ||
- type == TcrMessage::EXECUTECQ_WITH_IR_MSG_TYPE ||
- type == TcrMessage::GETDURABLECQS_MSG_TYPE) {
+ if (type == TcrMessage::REGISTER_INTEREST_LIST ||
+type == TcrMessage::REGISTER_INTEREST ||
+type == TcrMessage::QUERY ||
+type == TcrMessage::QUERY_WITH_PARAMETERS ||
+type == TcrMessage::GET_ALL_70 ||
+type == TcrMessage::GET_ALL_WITH_CALLBACK ||
+type == TcrMessage::PUTALL ||
+type == TcrMessage::PUT_ALL_WITH_CALLBACK ||
+type == TcrMessage::REMOVE_ALL ||
+((type == TcrMessage::EXECUTE_FUNCTION ||
+ type == TcrMessage::EXECUTE_REGION_FUNCTION) &&
+ (request.hasResult() & 2)) ||
Review Comment:
Ahh... It hasn't left draft mode.
https://github.com/apache/geode-native/pull/930
> Remove Redundant Calls to sendRequestForChunkedResponse
> ---
>
> Key: GEODE-10227
> URL: https://issues.apache.org/jira/browse/GEODE-10227
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Minor
> Labels: pull-request-available
>
> TcrEndpoint::sendRequestConn contains redundant calls to
> TcrConnection::sendRequestForChunkedResponse which should be removed. The
> current code is illustrated by the following:
> {code:java}
> if (messageType == a || messageType == b)
> sendRequestForChunkedResponse()
> else
> sendRequestForChunkedResponse(){code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10249) Add stats for BufferPoolMXBean
[ https://issues.apache.org/jira/browse/GEODE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10249: --- Labels: pull-request-available (was: ) > Add stats for BufferPoolMXBean > -- > > Key: GEODE-10249 > URL: https://issues.apache.org/jira/browse/GEODE-10249 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > > Java provides information on buffer pools used in the JVM via > BufferPoolMXBean. Add the output of these to the basic set of platform stats > to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10249) Add stats for BufferPoolMXBean
[ https://issues.apache.org/jira/browse/GEODE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett reassigned GEODE-10249: - Assignee: Jacob Barrett > Add stats for BufferPoolMXBean > -- > > Key: GEODE-10249 > URL: https://issues.apache.org/jira/browse/GEODE-10249 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > > Java provides information on buffer pools used in the JVM via > BufferPoolMXBean. Add the output of these to the basic set of platform stats > to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10249) Add stats for BufferPoolMXBean
Jacob Barrett created GEODE-10249: - Summary: Add stats for BufferPoolMXBean Key: GEODE-10249 URL: https://issues.apache.org/jira/browse/GEODE-10249 Project: Geode Issue Type: Improvement Reporter: Jacob Barrett Java provides information on buffer pools used in the JVM via BufferPoolMXBean. Add the output of these to the basic set of platform stats to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9612) CI Hang in org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
[
https://issues.apache.org/jira/browse/GEODE-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524561#comment-17524561
]
Geode Integration commented on GEODE-9612:
--
Seen in [integration-test-openjdk8
#315|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/315]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1113/test-results/integrationTest/1650094814/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1113/test-artifacts/1650094814/integrationtestfiles-openjdk8-1.15.0-build.1113.tgz].
> CI Hang in
> org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
> --
>
> Key: GEODE-9612
> URL: https://issues.apache.org/jira/browse/GEODE-9612
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Priority: Major
>
> {noformat}
> progress -s started
> org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
> Iteration: 1
> Start: 2021-09-20 17:58:36.099 +
> End: 0001-01-01 00:00:00.000 +
> Duration: 0s
> Status:started {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9612) CI Hang in org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
[
https://issues.apache.org/jira/browse/GEODE-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524544#comment-17524544
]
Geode Integration commented on GEODE-9612:
--
Seen in [integration-test-openjdk8
#315|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/315]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1113/test-results/integrationTest/1650094814/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1113/test-artifacts/1650094814/integrationtestfiles-openjdk8-1.15.0-build.1113.tgz].
> CI Hang in
> org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
> --
>
> Key: GEODE-9612
> URL: https://issues.apache.org/jira/browse/GEODE-9612
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Priority: Major
>
> {noformat}
> progress -s started
> org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
> Iteration: 1
> Start: 2021-09-20 17:58:36.099 +
> End: 0001-01-01 00:00:00.000 +
> Duration: 0s
> Status:started {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10248:
--
Labels: needsTriage (was: )
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> Found in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError 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 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> 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:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 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.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Created] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
Xiaojian Zhou created GEODE-10248: - Summary: CI: DeployToMultiGroupDUnitTest encountered suspect string Key: GEODE-10248 URL: https://issues.apache.org/jira/browse/GEODE-10248 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou Found in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293 > Task :geode-assembly:distributedTest DeployToMultiGroupDUnitTest > executionError 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 571 $??http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650107916/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test report artifacts from this job are available at: http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650107916/distributedtestfiles-openjdk8-1.15.0-build..tgz -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524537#comment-17524537
]
Geode Integration commented on GEODE-10248:
---
Seen in [distributed-test-openjdk8
#1941|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1941]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650107916/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650107916/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> Found in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError 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 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> 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:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 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.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
>
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524534#comment-17524534
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-base
#295|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/295].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10147) CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception while trying to run ssl benchmarks
[
https://issues.apache.org/jira/browse/GEODE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524533#comment-17524533
]
Geode Integration commented on GEODE-10147:
---
Seen in [benchmark-with-security-manager
#295|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/295].
> CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception
> while trying to run ssl benchmarks
> --
>
> Key: GEODE-10147
> URL: https://issues.apache.org/jira/browse/GEODE-10147
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> P2pPartitionedPutBenchmark > run() FAILED
> net.schmizz.sshj.transport.TransportException: Connection reset
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.copyFromNode(SshInfrastructure.java:185)
> at
> org.apache.geode.perftest.jvms.RemoteJVMs.copyResults(RemoteJVMs.java:87)
> at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:112)
> at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> at
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark.run(P2pPartitionedPutBenchmark.java:52)
> Caused by:
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:186)
> at java.net.SocketInputStream.read(SocketInputStream.java:140)
> at java.net.SocketInputStream.read(SocketInputStream.java:200)
> at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> ... 8 more
> 4 tests completed, 1 failed
> This is ITERATION 2 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> ReplicatedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by:
> java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
> ... 6 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed
> connection during identification exchange
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> ... 7 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed
> connection during
[jira] [Commented] (GEODE-10173) CI failure: P2pPartitionedGetBenchmark > run()
[
https://issues.apache.org/jira/browse/GEODE-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524532#comment-17524532
]
Geode Integration commented on GEODE-10173:
---
Seen in [benchmark-base
#292|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/292].
> CI failure: P2pPartitionedGetBenchmark > run()
> --
>
> Key: GEODE-10173
> URL: https://issues.apache.org/jira/browse/GEODE-10173
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> org.apache.geode.benchmark.tests.P2pPartitionedGetBenchmark > run() FAILED
> 15:49:10net.schmizz.sshj.transport.TransportException: Connection reset
> 15:49:10at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:181)
> 15:49:10at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:771)
> 15:49:10at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:150)
> 15:49:10at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:75)
> 15:49:10at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.copyFromNode(SshInfrastructure.java:186)
> 15:49:10at
> org.apache.geode.perftest.jvms.RemoteJVMs.copyResults(RemoteJVMs.java:87)
> 15:49:10at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:136)
> 15:49:10at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:68)
> 15:49:10at
> org.apache.geode.benchmark.tests.P2pPartitionedGetBenchmark.run(P2pPartitionedGetBenchmark.java:44)
> 15:49:10
> 15:49:10Caused by:
> 15:49:10java.net.SocketException: Connection reset
> 15:49:10at
> java.net.SocketInputStream.read(SocketInputStream.java:210)
> 15:49:10at
> java.net.SocketInputStream.read(SocketInputStream.java:141)
> 15:49:10at
> java.net.SocketInputStream.read(SocketInputStream.java:224)
> 15:49:10at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:198)
> 15:49:10at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:174)
> 15:49:10... 8 more {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-6801) CI: AutoConnectionSourceImplJUnitTest.test_DiscoverLocators_whenOneLocatorWasShutdown failed on Windows
[ https://issues.apache.org/jira/browse/GEODE-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524531#comment-17524531 ] Geode Integration commented on GEODE-6801: -- Seen in [integration-test-openjdk8 #317|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/317] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1115/test-results/integrationTest/1650392746/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1115/test-artifacts/1650392746/integrationtestfiles-openjdk8-1.15.0-build.1115.tgz]. > CI: > AutoConnectionSourceImplJUnitTest.test_DiscoverLocators_whenOneLocatorWasShutdown > failed on Windows > > > Key: GEODE-6801 > URL: https://issues.apache.org/jira/browse/GEODE-6801 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Priority: Major > Labels: flaky > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/455 > org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to connect > to any locators in the list [LocatorAddress > [socketInetAddress=packer-5cd4b68b-ea62-1633-a97a-d526ad1b88a1/10.0.0.135:29249, > hostname=packer-5cd4b68b-ea62-1633-a97a-d526ad1b88a1, isIpString=false], > LocatorAddress > [socketInetAddress=packer-5cd4b68b-ea62-1633-a97a-d526ad1b88a1/10.0.0.135:29250, > hostname=packer-5cd4b68b-ea62-1633-a97a-d526ad1b88a1, isIpString=false]] > at > org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:159) > at > org.apache.geode.cache.client.internal.AutoConnectionSourceImplJUnitTest.test_DiscoverLocators_whenOneLocatorWasShutdown(AutoConnectionSourceImplJUnitTest.java:339) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java: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 >
[jira] [Created] (GEODE-10247) CI: spring-compatibility-test compile failure
Xiaojian Zhou created GEODE-10247: - Summary: CI: spring-compatibility-test compile failure Key: GEODE-10247 URL: https://issues.apache.org/jira/browse/GEODE-10247 Project: Geode Issue Type: Bug Components: redis Reporter: Xiaojian Zhou It's found in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14671910 https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293 https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643323 ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (java-compile) on project spring-data-geode: Compilation failure: Compilation failure: [ERROR] /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[103,43] error: cannot find symbol [ERROR] symbol: variable GEODE_FOR_REDIS_BIND_ADDRESS [ERROR] location: interface ConfigurationProperties [ERROR] /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[104,38] error: cannot find symbol [ERROR] symbol: variable GEODE_FOR_REDIS_ENABLED [ERROR] location: interface ConfigurationProperties [ERROR] /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[105,35] error: cannot find symbol [ERROR] symbol: variable GEODE_FOR_REDIS_PORT [ERROR] location: interface ConfigurationProperties [ERROR] /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[106,47] error: cannot find symbol [ERROR] symbol: variable GEODE_FOR_REDIS_REDUNDANT_COPIES [ERROR] location: interface ConfigurationProperties [ERROR] /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[107,39] error: cannot find symbol [ERROR] symbol: variable GEODE_FOR_REDIS_USERNAME [ERROR] location: interface ConfigurationProperties -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10247) CI: spring-compatibility-test compile failure
[ https://issues.apache.org/jira/browse/GEODE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10247: -- Labels: needsTriage (was: ) > CI: spring-compatibility-test compile failure > - > > Key: GEODE-10247 > URL: https://issues.apache.org/jira/browse/GEODE-10247 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > It's found in > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14671910 > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293 > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643323 > ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (java-compile) > on project spring-data-geode: Compilation failure: Compilation failure: > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[103,43] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_BIND_ADDRESS > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[104,38] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_ENABLED > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[105,35] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_PORT > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[106,47] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_REDUNDANT_COPIES > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[107,39] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_USERNAME > [ERROR] location: interface ConfigurationProperties -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10186) CI failure: RedundancyLevelPart1DUnitTest > testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU times out waiting for getClientProxies() to return more than 0 objec
[
https://issues.apache.org/jira/browse/GEODE-10186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524517#comment-17524517
]
Geode Integration commented on GEODE-10186:
---
Seen in [distributed-test-openjdk8
#1916|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1916]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650083918/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650083918/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI failure: RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU times out waiting for
> getClientProxies() to return more than 0 objects
> -
>
> Key: GEODE-10186
> URL: https://issues.apache.org/jira/browse/GEODE-10186
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14277358]
>
> {noformat}
> > Task :geode-core:distributedTest
> RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest$$Lambda$543/510122765.run
> in VM 2 running on Host
> heavy-lifter-f58561da-caf9-5bc0-a7fa-f938c3fd1e51.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU(RedundancyLevelPart1DUnitTest.java:284)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest
> that uses org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier
> Expecting actual:
> 0
> to be greater than:
> 0
> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.verifyInterestRegistration(RedundancyLevelPart1DUnitTest.java:505)
> Caused by:
> java.lang.AssertionError:
> Expecting actual:
> 0
> to be greater than:
> 0
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.lambda$verifyInterestRegistration$19(RedundancyLevelPart1DUnitTest.java:506)
> 8352 tests completed, 1 failed, 414 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1033/test-results/distributedTest/1648331031/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1033/test-artifacts/1648331031/distributedtestfiles-openjdk8-1.15.0-build.1033.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-7836) [CI Failure] JMXMBeanReconnectDUnitTest > serverHasMemberTypeMXBeans FAILED
[
https://issues.apache.org/jira/browse/GEODE-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524516#comment-17524516
]
Geode Integration commented on GEODE-7836:
--
Seen in [distributed-test-openjdk8
#1901|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1901]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650074968/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650074968/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> [CI Failure] JMXMBeanReconnectDUnitTest > serverHasMemberTypeMXBeans FAILED
> ---
>
> Key: GEODE-7836
> URL: https://issues.apache.org/jira/browse/GEODE-7836
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Owen Nichols
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
>
> Our JMX layer has a couple design flaws causing this and probably some other
> JMX tests to fail intermittently. I propose to make the creation and removal
> of mbeans synchronous with what's happening in Geode, such as
> creating/destroying of Regions or other Geode entities. In particular, any
> sort of reconnect or HA event can expose the design flaw.
> ---
> seen in
> [DistributedTestOpenJDK11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1592]:
> {noformat}
> > Task :geode-core:distributedTest
> 13:50:43
> 13:50:43org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverHasMemberTypeMXBeans FAILED
> 13:50:43org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.JMXMBeanReconnectDUnitTest$$Lambda$494/0x000840de0440.call
> in VM -1 running on Host 27968468c585 with 4 VMs
> 13:50:43at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 13:50:43at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> 13:50:43at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.setUp(JMXMBeanReconnectDUnitTest.java:189)
> 13:50:43
> 13:50:43Caused by:
> 13:50:43org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest [GemFire mbeans on
> locator2]
> 13:50:43Expecting:
> 13:50:43 <[GemFire:type=Member,member=locator1,
> 13:50:43
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
> 13:50:43GemFire:type=Member,member=server1,
> 13:50:43GemFire:service=Manager,type=Member,member=locator1,
> 13:50:43GemFire:service=Locator,type=Member,member=locator2,
> 13:50:43GemFire:type=Member,member=locator2,
> 13:50:43
> GemFire:service=Region,name=/region1,type=Member,member=server1,
> 13:50:43GemFire:service=FileUploader,type=Distributed,
> 13:50:43
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
> 13:50:43GemFire:service=Manager,type=Member,member=locator2,
> 13:50:43GemFire:service=Locator,type=Member,member=locator1,
> 13:50:43GemFire:service=System,type=Distributed,
> 13:50:43GemFire:service=AccessControl,type=Distributed,
> 13:50:43
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 13:50:43GemFire:service=Region,name=/region1,type=Distributed]>
> 13:50:43to contain:
> 13:50:43 <[GemFire:type=Member,member=locator1,
> 13:50:43GemFire:service=Locator,type=Member,member=locator1,
> 13:50:43GemFire:service=Manager,type=Member,member=locator1,
> 13:50:43
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
> 13:50:43
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> 13:50:43but could not find:
> 13:50:43
> <[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
> 13:50:43
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> 13:50:43 within 300 seconds.
> 13:50:43at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 13:50:43at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 13:50:43at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 13:50:43at
>
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524511#comment-17524511
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1912|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1912]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650083472/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650083472/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524512#comment-17524512
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1907|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1907]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650074865/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650074865/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524510#comment-17524510
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1922|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1922]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650093181/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650093181/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524507#comment-17524507
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1934|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1934]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650101490/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650101490/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524509#comment-17524509
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1927|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1927]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650093595/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650093595/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524508#comment-17524508
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1932|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1932]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650100276/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650100276/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524506#comment-17524506
]
Geode Integration commented on GEODE-6222:
--
Seen in [distributed-test-openjdk8
#1939|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1939]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650101789/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650101789/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.9.0, 1.14.0, 1.15.0
>Reporter: Ken Howe
>Priority: Major
> Labels: flaky
>
> Flaky test failure in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> 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:199)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524505#comment-17524505
]
Geode Integration commented on GEODE-10209:
---
Seen in [distributed-test-openjdk8
#1945|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1945]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650109977/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650109977/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
>
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
> in VM 0 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
> in VM 1 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
>
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524502#comment-17524502
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1964|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1964]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650141810/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650141810/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524503#comment-17524503
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1970|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1970]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650141704/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650141704/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524504#comment-17524504
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1971|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1971]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650141663/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650141663/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524501#comment-17524501
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1969|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1969]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650142434/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650142434/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524500#comment-17524500
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1975|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1975]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650148485/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650148485/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-6645) CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest > testDataStoreEntryCount FAILED
[
https://issues.apache.org/jira/browse/GEODE-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524499#comment-17524499
]
Geode Integration commented on GEODE-6645:
--
Seen in [distributed-test-openjdk8
#1978|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1978]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650149505/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650149505/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
>
>
> Key: GEODE-6645
> URL: https://issues.apache.org/jira/browse/GEODE-6645
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Priority: Major
> Labels: CI, GeodeOperationAPI
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/617
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac 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.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> Caused by:
> org.junit.ComparisonFailure: expected:<[3]L> but was:<[2]L>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.validateEntryCount(PartitionedRegionStatsDUnitTest.java:267)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.lambda$testDataStoreEntryCount$bb17a952$18(PartitionedRegionStatsDUnitTest.java:198)
> {noformat}
> Artifacts are available here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-results/distributedTest/1555097363/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-artifacts/1555097363/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0176.tgz
> {noformat}
> Looking at this test, it goes through several phases of entry creation,
> destroy, destroy + put and GII (after adding a new member) for a partitioned
> region with redundantCopies=2. After adding the new member and forcing
> tombstone expiration, the newly created vm ends up with 1 less entry than
> expected (but the original two vms appear to have the expected number of
> entries (3)).
> Full stack
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac 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.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
>
[jira] [Commented] (GEODE-7836) [CI Failure] JMXMBeanReconnectDUnitTest > serverHasMemberTypeMXBeans FAILED
[
https://issues.apache.org/jira/browse/GEODE-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524497#comment-17524497
]
Geode Integration commented on GEODE-7836:
--
Seen in [distributed-test-openjdk8
#1980|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1980]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650150628/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650150628/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> [CI Failure] JMXMBeanReconnectDUnitTest > serverHasMemberTypeMXBeans FAILED
> ---
>
> Key: GEODE-7836
> URL: https://issues.apache.org/jira/browse/GEODE-7836
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Owen Nichols
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
>
> Our JMX layer has a couple design flaws causing this and probably some other
> JMX tests to fail intermittently. I propose to make the creation and removal
> of mbeans synchronous with what's happening in Geode, such as
> creating/destroying of Regions or other Geode entities. In particular, any
> sort of reconnect or HA event can expose the design flaw.
> ---
> seen in
> [DistributedTestOpenJDK11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1592]:
> {noformat}
> > Task :geode-core:distributedTest
> 13:50:43
> 13:50:43org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverHasMemberTypeMXBeans FAILED
> 13:50:43org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.JMXMBeanReconnectDUnitTest$$Lambda$494/0x000840de0440.call
> in VM -1 running on Host 27968468c585 with 4 VMs
> 13:50:43at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 13:50:43at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> 13:50:43at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.setUp(JMXMBeanReconnectDUnitTest.java:189)
> 13:50:43
> 13:50:43Caused by:
> 13:50:43org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest [GemFire mbeans on
> locator2]
> 13:50:43Expecting:
> 13:50:43 <[GemFire:type=Member,member=locator1,
> 13:50:43
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
> 13:50:43GemFire:type=Member,member=server1,
> 13:50:43GemFire:service=Manager,type=Member,member=locator1,
> 13:50:43GemFire:service=Locator,type=Member,member=locator2,
> 13:50:43GemFire:type=Member,member=locator2,
> 13:50:43
> GemFire:service=Region,name=/region1,type=Member,member=server1,
> 13:50:43GemFire:service=FileUploader,type=Distributed,
> 13:50:43
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
> 13:50:43GemFire:service=Manager,type=Member,member=locator2,
> 13:50:43GemFire:service=Locator,type=Member,member=locator1,
> 13:50:43GemFire:service=System,type=Distributed,
> 13:50:43GemFire:service=AccessControl,type=Distributed,
> 13:50:43
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 13:50:43GemFire:service=Region,name=/region1,type=Distributed]>
> 13:50:43to contain:
> 13:50:43 <[GemFire:type=Member,member=locator1,
> 13:50:43GemFire:service=Locator,type=Member,member=locator1,
> 13:50:43GemFire:service=Manager,type=Member,member=locator1,
> 13:50:43
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
> 13:50:43
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> 13:50:43but could not find:
> 13:50:43
> <[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
> 13:50:43
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> 13:50:43 within 300 seconds.
> 13:50:43at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 13:50:43at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 13:50:43at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 13:50:43at
>
[jira] [Commented] (GEODE-6645) CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest > testDataStoreEntryCount FAILED
[
https://issues.apache.org/jira/browse/GEODE-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524491#comment-17524491
]
Geode Integration commented on GEODE-6645:
--
Seen in [distributed-test-openjdk8
#1992|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1992]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650158349/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650158349/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
>
>
> Key: GEODE-6645
> URL: https://issues.apache.org/jira/browse/GEODE-6645
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Priority: Major
> Labels: CI, GeodeOperationAPI
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/617
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac 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.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> Caused by:
> org.junit.ComparisonFailure: expected:<[3]L> but was:<[2]L>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.validateEntryCount(PartitionedRegionStatsDUnitTest.java:267)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.lambda$testDataStoreEntryCount$bb17a952$18(PartitionedRegionStatsDUnitTest.java:198)
> {noformat}
> Artifacts are available here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-results/distributedTest/1555097363/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-artifacts/1555097363/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0176.tgz
> {noformat}
> Looking at this test, it goes through several phases of entry creation,
> destroy, destroy + put and GII (after adding a new member) for a partitioned
> region with redundantCopies=2. After adding the new member and forcing
> tombstone expiration, the newly created vm ends up with 1 less entry than
> expected (but the original two vms appear to have the expected number of
> entries (3)).
> Full stack
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac 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.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
>
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524485#comment-17524485
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#1988|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1988]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650159038/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650159038/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-6645) CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest > testDataStoreEntryCount FAILED
[
https://issues.apache.org/jira/browse/GEODE-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524482#comment-17524482
]
Geode Integration commented on GEODE-6645:
--
Seen in [distributed-test-openjdk8
#1998|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1998]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650167147/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650167147/distributedtestfiles-openjdk8-1.15.0-build..tgz].
> CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
>
>
> Key: GEODE-6645
> URL: https://issues.apache.org/jira/browse/GEODE-6645
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Priority: Major
> Labels: CI, GeodeOperationAPI
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/617
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac 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.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> Caused by:
> org.junit.ComparisonFailure: expected:<[3]L> but was:<[2]L>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.validateEntryCount(PartitionedRegionStatsDUnitTest.java:267)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.lambda$testDataStoreEntryCount$bb17a952$18(PartitionedRegionStatsDUnitTest.java:198)
> {noformat}
> Artifacts are available here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-results/distributedTest/1555097363/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-artifacts/1555097363/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0176.tgz
> {noformat}
> Looking at this test, it goes through several phases of entry creation,
> destroy, destroy + put and GII (after adding a new member) for a partitioned
> region with redundantCopies=2. After adding the new member and forcing
> tombstone expiration, the newly created vm ends up with 1 less entry than
> expected (but the original two vms appear to have the expected number of
> entries (3)).
> Full stack
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac 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.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
>
[jira] [Commented] (GEODE-10161) Clean up synchronization in RedisList
[
https://issues.apache.org/jira/browse/GEODE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524469#comment-17524469
]
ASF subversion and git services commented on GEODE-10161:
-
Commit 39e3a89b9e1e313bea6b0449430f5cbdb9a7b327 in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=39e3a89b9e ]
GEODE-10161: Remove unnecessary synchronization from RedisList (#7579)
- Now, with the addition of versioning and synchronization at the
higher-level methods, all the synchronization can be removed from the
small, helper methods we have.
- We still need to ensure that there is synchronization between toData
and within methods that are mutating the list.
- Inline various helper methods in RedisList as they are not adding any
value.
- Use AvailablePortHelper to set up the port that the crashing VM will
use. Without this there is interference from other tests when running
multiple tests concurrently (in the stressTest job).
- Ran at least 1000 iterations of all list-related DUnit tests without
any failures.
> Clean up synchronization in RedisList
> -
>
> Key: GEODE-10161
> URL: https://issues.apache.org/jira/browse/GEODE-10161
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Prior to adding versioning, we needed {{synchronized}} on various helper
> methods that modified the internal list data structure. This was in order to
> ensure exclusive access in the event of a {{toData()}} call (during
> GII/bucket movement). {{toData()}} is also synchronized. However, now that
> we're synchronizing within more of the 'top-level' methods in RedisList,
> (because we're also changing the {{version}} value), I think that we should
> be able to remove all of the {{synchronized}} modifiers on the smaller helper
> methods.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524437#comment-17524437 ] ASF subversion and git services commented on GEODE-10074: - Commit 9b5b86ca90ae4a2338317450541ac984064dc64a in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=9b5b86ca9 ] GEODE-10074: Remove ACE remainings (#928) - Removed all the ACE includes along the repository - Removed ACE from CMake project. - Removed ACE dependency. - There were a couple of files in which ACE's strcmp was used. So, its usage was replaced to to std::string::operator== - Removed non-necessary ACE's getcwd calls. > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524436#comment-17524436 ] ASF GitHub Bot commented on GEODE-10074: pdxcodemonkey merged PR #928: URL: https://github.com/apache/geode-native/pull/928 > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10246) OutOfMemoryDUnitTest throws JedisDataException on JDK17
Dale Emery created GEODE-10246:
--
Summary: OutOfMemoryDUnitTest throws JedisDataException on JDK17
Key: GEODE-10246
URL: https://issues.apache.org/jira/browse/GEODE-10246
Project: Geode
Issue Type: Improvement
Components: redis, tests
Affects Versions: 1.15.0
Reporter: Dale Emery
These three OutOfMemoryDUnitTest tests fail on JDK17:
* shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold
* shouldReturnOOMError_forPublish_whenThresholdReached
* shouldReturnOOMError_forSubscribe_whenThresholdReached
The Concurrent Mark Sweep (CMS) garbage collector does not exist on JDK17.
My hunch is that the test code relies on CMS-like behavior to establish "over
the memory threshold" conditions for the test.
Example test results here:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7590/test-results/distributedTest/1650326807/
Example stack trace:
{noformat}
org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures (2
failures)
org.opentest4j.AssertionFailedError:
Expecting message to be:
"OOM command not allowed when used memory > 'maxmemory'"
but was:
"ERR The server had an internal error please try again"
Throwable that failed the check:
redis.clients.jedis.exceptions.JedisDataException: ERR The server had an
internal error please try again
at redis.clients.jedis.Protocol.processError(Protocol.java:96)
at redis.clients.jedis.Protocol.process(Protocol.java:137)
at redis.clients.jedis.Protocol.read(Protocol.java:192)
at
redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316)
at redis.clients.jedis.Connection.getOne(Connection.java:298)
at redis.clients.jedis.Connection.executeCommand(Connection.java:123)
at
redis.clients.jedis.executors.ClusterCommandExecutor.executeCommand(ClusterCommandExecutor.java:57)
at
redis.clients.jedis.UnifiedJedis.executeCommand(UnifiedJedis.java:139)
at redis.clients.jedis.UnifiedJedis.set(UnifiedJedis.java:491)
at
org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$fillServer1Memory$39(OutOfMemoryDUnitTest.java:359)
at
org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:63)
at
org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:878)
at org.assertj.core.api.Assertions.catchThrowable(Assertions.java:1337)
at
org.assertj.core.api.Assertions.assertThatThrownBy(Assertions.java:1181)
at
org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:352)
at
org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:289)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
[jira] [Updated] (GEODE-10246) OutOfMemoryDUnitTest throws JedisDataException on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10246:
---
Labels: Java17 (was: )
> OutOfMemoryDUnitTest throws JedisDataException on JDK17
> ---
>
> Key: GEODE-10246
> URL: https://issues.apache.org/jira/browse/GEODE-10246
> Project: Geode
> Issue Type: Improvement
> Components: redis, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> These three OutOfMemoryDUnitTest tests fail on JDK17:
> * shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold
> * shouldReturnOOMError_forPublish_whenThresholdReached
> * shouldReturnOOMError_forSubscribe_whenThresholdReached
> The Concurrent Mark Sweep (CMS) garbage collector does not exist on JDK17.
> My hunch is that the test code relies on CMS-like behavior to establish "over
> the memory threshold" conditions for the test.
> Example test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7590/test-results/distributedTest/1650326807/
> Example stack trace:
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError:
> Expecting message to be:
> "OOM command not allowed when used memory > 'maxmemory'"
> but was:
> "ERR The server had an internal error please try again"
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisDataException: ERR The server had an
> internal error please try again
> at redis.clients.jedis.Protocol.processError(Protocol.java:96)
> at redis.clients.jedis.Protocol.process(Protocol.java:137)
> at redis.clients.jedis.Protocol.read(Protocol.java:192)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316)
> at redis.clients.jedis.Connection.getOne(Connection.java:298)
> at redis.clients.jedis.Connection.executeCommand(Connection.java:123)
> at
> redis.clients.jedis.executors.ClusterCommandExecutor.executeCommand(ClusterCommandExecutor.java:57)
> at
> redis.clients.jedis.UnifiedJedis.executeCommand(UnifiedJedis.java:139)
> at redis.clients.jedis.UnifiedJedis.set(UnifiedJedis.java:491)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$fillServer1Memory$39(OutOfMemoryDUnitTest.java:359)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:63)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:878)
> at org.assertj.core.api.Assertions.catchThrowable(Assertions.java:1337)
> at
> org.assertj.core.api.Assertions.assertThatThrownBy(Assertions.java:1181)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:352)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:289)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at
[jira] [Updated] (GEODE-10231) Add configuration for suppressing FunctionException logging
[
https://issues.apache.org/jira/browse/GEODE-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleksii Sitnianskyi updated GEODE-10231:
Description:
According to Apache Geode function implementation, the following is stated in
[1]:
"To propagate an error condition or exception back to the caller of the
function, throw a FunctionException from the execute method. Geode transmits the
exception back to the caller as if it had been thrown on the calling side. See
the Java API documentation for
FunctionException<[https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionException.html]>
for more information."
And as per [2]:
"if a GemFire client executes a Function on a server, and the function's execute
method throws a FunctionException, the server logs the exception as a warning,
and transmits it back to the calling client, which throws it"
So, for every FunctionException thrown by a user Server Function, the server
logs the exception with the corresponding stack trace.
This could imply, depending on the logic implemented in the user Server
Function, that the log of the server is packed with these messages (which
probably are not providing extra useful information given that the exception
will reach the client), and making it difficult to analyze the logs to find
other relevant events.
Given that Apache Geode recommends the use of FunctionException as the means to
propagate an error condition or exception back to the caller, we could argue if
a FunctionException thrown by a user Function should have any reflection, at
all, in the server logs. Besides, as said before, depending on the amount of the
exceptions generated, this can complicate the analysis of log files, require
much more space for logs storage and have a negative impact in performance.
Solution:
Add Log4j markers for all FunctionException logs to be able to handle them by
Log4j filter configuration, eg. disable all function exception logs:
{code:java}
{code}
was:
According to Apache Geode function implementation, the following is stated in
[1]:
"To propagate an error condition or exception back to the caller of the
function, throw a FunctionException from the execute method. Geode transmits the
exception back to the caller as if it had been thrown on the calling side. See
the Java API documentation for
FunctionException
for more information."
And as per [2]:
"if a GemFire client executes a Function on a server, and the function's execute
method throws a FunctionException, the server logs the exception as a warning,
and transmits it back to the calling client, which throws it"
So, for every FunctionException thrown by a user Server Function, the server
logs the exception with the corresponding stack trace.
This could imply, depending on the logic implemented in the user Server
Function, that the log of the server is packed with these messages (which
probably are not providing extra useful information given that the exception
will reach the client), and making it difficult to analyze the logs to find
other relevant events.
Given that Apache Geode recommends the use of FunctionException as the means to
propagate an error condition or exception back to the caller, we could argue if
a FunctionException thrown by a user Function should have any reflection, at
all, in the server logs. Besides, as said before, depending on the amount of the
exceptions generated, this can complicate the analysis of log files, require
much more space for logs storage and have a negative impact in performance.
The improvement for server side logging is adding system property configuration
for surprising FunctionException logging.
Property example:
{code}
gemfire.logging.suppressFunctionExceptionLogging=true
{code}
> Add configuration for suppressing FunctionException logging
> ---
>
> Key: GEODE-10231
> URL: https://issues.apache.org/jira/browse/GEODE-10231
> Project: Geode
> Issue Type: Improvement
> Components: client/server, functions
>Reporter: Oleksii Sitnianskyi
>Assignee: Oleksii Sitnianskyi
>Priority: Major
> Labels: pull-request-available
>
> According to Apache Geode function implementation, the following is stated in
> [1]:
> "To propagate an error condition or exception back to the caller of the
> function, throw a FunctionException from the execute method. Geode transmits
> the
> exception back to the caller as if it had been thrown on the calling side. See
> the Java API documentation for
> FunctionException<[https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionException.html]>
> for more information."
> And as per [2]:
>
