[jira] [Created] (GEODE-9121) Regression Introduced Through GEODE-8905
Juan Ramos created GEODE-9121:
-
Summary: Regression Introduced Through GEODE-8905
Key: GEODE-9121
URL: https://issues.apache.org/jira/browse/GEODE-9121
Project: Geode
Issue Type: Bug
Components: client/server
Affects Versions: 1.15.0
Reporter: Juan Ramos
The new implementation of the {{JarDeploymentService}} seems to be deleting
resources when a member is gracefully shutdown, which in turns generates a race
condition if there are functions being executed on the member during that time.
In previous versions, a client application would simply retry the operation
and no exception or loss of availability would be seen, right now the following
exception is thrown on the client instead:
{noformat}
Exception in thread "main" org.apache.geode.cache.execute.FunctionException:
org.apache.geode.cache.client.ServerOperationException: remote server on
192.168.0.73(3985:loner):49836:c9f57ea7: The function, , has not been
registered
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:237)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:184)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:388)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
at test.TestClient.main(TestClient.java:20)
Caused by: org.apache.geode.cache.client.ServerOperationException: remote
server on 192.168.0.73(3985:loner):49836:c9f57ea7: The function, , has
not been registered
at
org.apache.geode.cache.client.internal.ExecuteRegionFunctionSingleHopOp$ExecuteRegionFunctionSingleHopOpImpl.processResponse(ExecuteRegionFunctionSingleHopOp.java:370)
at
org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:224)
at
org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:197)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:384)
at
org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:355)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:756)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:335)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:304)
at
org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:840)
at
org.apache.geode.cache.client.internal.SingleHopOperationCallable.call(SingleHopOperationCallable.java:49)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
{noformat}
This seems to be a regression introduced through GEODE-8905. I've tested the
same scenario with version {{1.13.2}} (released), branch {{support/1.14}} and
commit [b80094ec5e|https://github.com/apache/geode/commit/b80094ec5e] with no
problems at all. When testing using commit
[6f764a7046|https://github.com/apache/geode/commit/6f764a7046], on the other
hand, the problem is easily reproducible.
—
How to reproduce the issue:
1. Download and extract {{workspace.zip}}.
2. Execute the {{reproduce.sh}} script and follow the instructions on screen.
The version of {{Geode}} to use on server side can be changed through the
{{GEMFIRE}} variable within the {{reproduce.sh}} script.
The version of {{Geode}} to use on client side can be changed through the
{{GEODE_VERSION}} variable within the {{launch_client.sh}} script.
The client application simply executes the {{TestFunction}} forever. When
running the scenario using a version of {{Geode}} that doesn't include commit
[b80094ec5e|https://github.com/apache/geode/commit/b80094ec5e], the client
simply retries under the hood and no exception is thrown. When using the
current {{develop}} branch, however, an exception is thrown and the client
application terminates as soon as a server is restarted.
[~ukohlmeyer], [~pjohnson]: I'm tagging you both as you were both working on
this feature, feel free to assign the ticket to however you consider necessary.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9121) Regression Introduced Through GEODE-8905
[
https://issues.apache.org/jira/browse/GEODE-9121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-9121:
--
Description:
The new implementation of the {{JarDeploymentService}} seems to be deleting
resources when a member is gracefully shutdown, which in turns generates a race
condition if there are functions being executed on the member during that time.
In previous versions, a client application would simply retry the operation
and no exception or loss of availability would be seen, right now the following
exception is thrown on the client instead:
{noformat}
Exception in thread "main" org.apache.geode.cache.execute.FunctionException:
org.apache.geode.cache.client.ServerOperationException: remote server on
192.168.0.73(3985:loner):49836:c9f57ea7: The function, , has not been
registered
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:237)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:184)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:388)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
at test.TestClient.main(TestClient.java:20)
Caused by: org.apache.geode.cache.client.ServerOperationException: remote
server on 192.168.0.73(3985:loner):49836:c9f57ea7: The function, , has
not been registered
at
org.apache.geode.cache.client.internal.ExecuteRegionFunctionSingleHopOp$ExecuteRegionFunctionSingleHopOpImpl.processResponse(ExecuteRegionFunctionSingleHopOp.java:370)
at
org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:224)
at
org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:197)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:384)
at
org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:355)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:756)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:335)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:304)
at
org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:840)
at
org.apache.geode.cache.client.internal.SingleHopOperationCallable.call(SingleHopOperationCallable.java:49)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
{noformat}
This seems to be a regression introduced through GEODE-8905. I've tested the
same scenario with version {{1.13.2}} (released), branch {{support/1.14}} and
commit [b80094ec5e|https://github.com/apache/geode/commit/b80094ec5e] with no
problems at all. When testing using commit
[6f764a7046|https://github.com/apache/geode/commit/6f764a7046], on the other
hand, the problem is easily reproducible.
—
How to reproduce the issue:
1. Download and extract {{workspace.zip}}.
2. Execute the {{reproduce.sh}} script and follow the instructions on screen.
The version of {{Geode}} to use on server side can be changed through the
{{GEMFIRE}} variable within the {{reproduce.sh}} script.
The version of {{Geode}} to use on client side can be changed through the
{{GEODE_VERSION}} variable within the {{launch_client.sh}} script.
The client application simply executes the {{TestFunction}} forever. When
running the scenario using a version of {{Geode}} that doesn't include commit
[6f764a7046|https://github.com/apache/geode/commit/6f764a7046], the client
simply retries under the hood and no exception is thrown. When using the
current {{develop}} branch, however, an exception is thrown and the client
application terminates as soon as a server is restarted.
[~ukohlmeyer], [~pjohnson]: I'm tagging you both as you were both working on
this feature, feel free to assign the ticket to however you consider necessary.
was:
The new implementation of the {{JarDeploymentService}} seems to be deleting
resources when a member is gracefully shutdown, which in turns generates a race
condition if there are functions being executed on the member during that time.
In previous versi
[jira] [Updated] (GEODE-9121) Regression Introduced Through GEODE-8905
[
https://issues.apache.org/jira/browse/GEODE-9121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-9121:
--
Attachment: workspace.zip
> Regression Introduced Through GEODE-8905
>
>
> Key: GEODE-9121
> URL: https://issues.apache.org/jira/browse/GEODE-9121
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Priority: Major
> Attachments: workspace.zip
>
>
> The new implementation of the {{JarDeploymentService}} seems to be deleting
> resources when a member is gracefully shutdown, which in turns generates a
> race condition if there are functions being executed on the member during
> that time.
> In previous versions, a client application would simply retry the operation
> and no exception or loss of availability would be seen, right now the
> following exception is thrown on the client instead:
> {noformat}
> Exception in thread "main" org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerOperationException: remote server on
> 192.168.0.73(3985:loner):49836:c9f57ea7: The function, , has not been
> registered
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:237)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:184)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:388)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
> at test.TestClient.main(TestClient.java:20)
> Caused by: org.apache.geode.cache.client.ServerOperationException: remote
> server on 192.168.0.73(3985:loner):49836:c9f57ea7: The function, ,
> has not been registered
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionSingleHopOp$ExecuteRegionFunctionSingleHopOpImpl.processResponse(ExecuteRegionFunctionSingleHopOp.java:370)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:224)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:197)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:384)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:355)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:756)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:335)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:304)
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:840)
> at
> org.apache.geode.cache.client.internal.SingleHopOperationCallable.call(SingleHopOperationCallable.java:49)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {noformat}
> This seems to be a regression introduced through GEODE-8905. I've tested the
> same scenario with version {{1.13.2}} (released), branch {{support/1.14}} and
> commit [b80094ec5e|https://github.com/apache/geode/commit/b80094ec5e] with no
> problems at all. When testing using commit
> [6f764a7046|https://github.com/apache/geode/commit/6f764a7046], on the other
> hand, the problem is easily reproducible.
> —
> How to reproduce the issue:
> 1. Download and extract {{workspace.zip}}.
> 2. Execute the {{reproduce.sh}} script and follow the instructions on screen.
> The version of {{Geode}} to use on server side can be changed through the
> {{GEMFIRE}} variable within the {{reproduce.sh}} script.
> The version of {{Geode}} to use on client side can be changed through the
> {{GEODE_VERSION}} variable within the {{launch_client.sh}} script.
> The client application simply executes the {{TestFunction}} forever. When
> running the scenario using a version of {{Geode}} that doesn't include commit
> [6f764a7046|https://github.com/apache/geode/commit/6f764a7046], the client
> simply retries under the hood and no exception is thro
[jira] [Commented] (GEODE-9064) Configure serialization filtering for JMX/RMI by default on Java 11
[ https://issues.apache.org/jira/browse/GEODE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315714#comment-17315714 ] ASF subversion and git services commented on GEODE-9064: Commit c43dbc59dd54df3538598e85243698840f8b6541 in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c43dbc5 ] GEODE-9064: Configure serial filter during ManagementAgent start (#6196) The Geode JMX layer will configure the system property “jmx.remote.rmi.server.serial.filter.pattern" to only accept JDK classes identified as open-types required for JMX. If the system property already has a value then Geode will log a statement and leave the system property alone. > Configure serialization filtering for JMX/RMI by default on Java 11 > --- > > Key: GEODE-9064 > URL: https://issues.apache.org/jira/browse/GEODE-9064 > Project: Geode > Issue Type: Improvement > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The Geode JMX layer should configure the > “jmx.remote.rmi.server.serial.filter.pattern” system property on Java 11 to > accept only JDK classes identified as open-types for JMX. If the user or > another library has already set this system property, then Geode will log a > statement and leave it alone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9120) CI: ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException FAILED
[
https://issues.apache.org/jira/browse/GEODE-9120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315718#comment-17315718
]
Geode Integration commented on GEODE-9120:
--
Seen in [DistributedTestOpenJDK8
#131.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/131.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0116/test-results/distributedTest/1617652711/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0116/test-artifacts/1617652711/distributedtestfiles-OpenJDK8-1.15.0-build.0116.tgz].
> CI: ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> -
>
> Key: GEODE-9120
> URL: https://issues.apache.org/jira/browse/GEODE-9120
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Nabarun Nag
>Priority: Major
>
>
> {noformat}
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$69/1107577048.run
> in VM 2 running on Host b3fa8968947d 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.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:118)
> Caused by:
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to
> connect to any locators in the list [HostAndPort[b3fa8968947d:34777],
> HostAndPort[localhost:34777]]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:174)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:198)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:276)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:129)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:112)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:797)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:114)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2802)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1469)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1442)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:197)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1379)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1318)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1303)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:439)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:121){noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0116/test-results/distributedTest/1617652711/*]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0116/test-artifacts/1617652711/distributedtestfiles-OpenJDK8-1.15.0-build.0116.tgz*]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315719#comment-17315719
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#132.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/132.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0117/test-results/distributedTest/1617660921/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0117/test-artifacts/1617660921/distributedtestfiles-OpenJDK8-1.15.0-build.0117.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9122) Setting group-transaction-events=true can cause ConcurrentModificationExceptions
Barrett Oglesby created GEODE-9122:
--
Summary: Setting group-transaction-events=true can cause
ConcurrentModificationExceptions
Key: GEODE-9122
URL: https://issues.apache.org/jira/browse/GEODE-9122
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Barrett Oglesby
The
SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
test can throw a ConcurrentModificationException like:
{noformat}
[warn 2021/04/04 02:55:53.253 GMT
tid=0x15d] An Exception occurred. The dispatcher will continue.
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1445)
at java.util.HashMap$KeyIterator.next(HashMap.java:1469)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue.peekEventsFromIncompleteTransactions(SerialGatewaySenderQueue.java:476)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue.peek(SerialGatewaySenderQueue.java:453)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:518)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:223)
{noformat}
If the SerialGatewaySenderQueue.peekEventsFromIncompleteTransactions contains
more than one TransactionId, and one of them is removed, the
ConcurrentModificationException will occur.
Both the SerialGatewaySenderQueue and ParallelGatewaySenderQueue
peekEventsFromIncompleteTransactions have the same implementation.
These methods do:
{noformat}
while (true) {
1. ->for (TransactionId transactionId : incompleteTransactionIdsInBatch) {
...
if (...) {
...
2. -> incompleteTransactionIdsInBatch.remove(transactionId);
}
}
}
{noformat}
The for-each loop (1) cannot be paired with the remove from the
incompleteTransactionIdsInBatch set (2). As soon as the remove is called, the
ConcurrentModificationException will be thrown the next time through the loop.
Since this for loop is in a while (true) loop, it is an infinite loop.
One way to address this would be to use an Iterator and call remove on the
Iterator like:
{noformat}
1. ->for (Iterator i =
incompleteTransactionIdsInBatch.iterator(); i.hasNext();) {
TransactionId transactionId = i.next();
...
2. -> i.remove();
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9122) Setting group-transaction-events=true can cause ConcurrentModificationExceptions
[
https://issues.apache.org/jira/browse/GEODE-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby reassigned GEODE-9122:
--
Assignee: Alberto Gomez
> Setting group-transaction-events=true can cause
> ConcurrentModificationExceptions
>
>
> Key: GEODE-9122
> URL: https://issues.apache.org/jira/browse/GEODE-9122
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Alberto Gomez
>Priority: Major
>
> The
> SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
> test can throw a ConcurrentModificationException like:
> {noformat}
> [warn 2021/04/04 02:55:53.253 GMT
> tid=0x15d] An Exception occurred. The dispatcher will continue.
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1445)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1469)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue.peekEventsFromIncompleteTransactions(SerialGatewaySenderQueue.java:476)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue.peek(SerialGatewaySenderQueue.java:453)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:518)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:223)
> {noformat}
> If the SerialGatewaySenderQueue.peekEventsFromIncompleteTransactions contains
> more than one TransactionId, and one of them is removed, the
> ConcurrentModificationException will occur.
> Both the SerialGatewaySenderQueue and ParallelGatewaySenderQueue
> peekEventsFromIncompleteTransactions have the same implementation.
> These methods do:
> {noformat}
>while (true) {
> 1. ->for (TransactionId transactionId : incompleteTransactionIdsInBatch) {
>...
>if (...) {
> ...
> 2. -> incompleteTransactionIdsInBatch.remove(transactionId);
>}
> }
>}
> {noformat}
> The for-each loop (1) cannot be paired with the remove from the
> incompleteTransactionIdsInBatch set (2). As soon as the remove is called, the
> ConcurrentModificationException will be thrown the next time through the
> loop. Since this for loop is in a while (true) loop, it is an infinite loop.
> One way to address this would be to use an Iterator and call remove on the
> Iterator like:
> {noformat}
> 1. ->for (Iterator i =
> incompleteTransactionIdsInBatch.iterator(); i.hasNext();) {
>TransactionId transactionId = i.next();
>...
> 2. -> i.remove();
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9024) Geode Cache Server stops accepting client connections
[
https://issues.apache.org/jira/browse/GEODE-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315729#comment-17315729
]
Kirk Lund commented on GEODE-9024:
--
[~leonfin] Hi Leon, I recommend asking detailed questions about this on the
geode dev-list: d...@geode.apache.org.
> Geode Cache Server stops accepting client connections
> -
>
> Key: GEODE-9024
> URL: https://issues.apache.org/jira/browse/GEODE-9024
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.1
>Reporter: Leon Finker
>Priority: Critical
>
> We are encountering the following deadlock (pretty often) on 1.13.1:
> 1. Client (bridge) acceptor thread is locked up in this stack
> {noformat}
> "Handshaker 0.0.0.0/0.0.0.0:40011 Thread 2" #219 daemon prio=5
> os_prio=0 tid=0x7f755c007000 nid=0x44a2 runnable
> [0x7f75847c7000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.net.SocketInputStream.read(SocketInputStream.java:223)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.getCommunicationModeForNonSelector(AcceptorImpl.java:1559)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.handleNewClientConnection(AcceptorImpl.java:1430)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$handOffNewClientConnection$4(AcceptorImpl.java:1341)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$407/2146094985.run(Unknown
> Source)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> 2. The 4 Handshaker threads for that pool are stuck in this stack
> {noformat}
> "Handshaker 0.0.0.0/0.0.0.0:40011 Thread 2" #219 daemon prio=5
> os_prio=0 tid=0x7f755c007000 nid=0x44a2 runnable
> [0x7f75847c7000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.net.SocketInputStream.read(SocketInputStream.java:223)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.getCommunicationModeForNonSelector(AcceptorImpl.java:1559)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.handleNewClientConnection(AcceptorImpl.java:1430)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$handOffNewClientConnection$4(AcceptorImpl.java:1341)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$407/2146094985.run(Unknown
> Source)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Is there any reason there is no socket read timeout set here:
> private CommunicationMode getCommunicationModeForNonSelector(Socket
> socket) throws IOException {
> socket.setSoTimeout(0);
> socketCreator.forCluster().handshakeIfSocketIsSSL(socket, acceptTimeout);
> byte communicationModeByte = (byte) socket.getInputStream().read();
> This blocks any new client connections to the server. Why not set read
> timeout? For some reason it's explicitly set to 0 (infinite)...This seems to
> have changed here:
> https://github.com/apache/geode/commit/e423cd8fa24329baf11fd6871a5ea6dc0f362b6c
> Before that change, the socket.setSoTimeout(0); was after the socket read.
> The cache server can be brought to a complete stop by just opening 4 telnet
> sessions to the cache server port. This is kind of denial of service...
> This is when using default CacheServer.MaxThreads=0. Maybe the work around is
> to use CacheServer.MaxThreads=N because then the code goes into a selector
> based logic with timeout it seems?
> Thank you
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9123) Notify clients when partitioned region is cleared
[ https://issues.apache.org/jira/browse/GEODE-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-9123: - Labels: GeodeOperationAPI (was: ) > Notify clients when partitioned region is cleared > - > > Key: GEODE-9123 > URL: https://issues.apache.org/jira/browse/GEODE-9123 > Project: Geode > Issue Type: New Feature > Components: client queues, client/server, regions >Reporter: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI > > Notify clients when partitioned region is cleared. Clients require > notifications for cache listeners and subscriptions. > On the server subscription data goes to the client through a server side > CacheClientNotifier. On the client we have a single CacheClientUpdater thread > that receives it. We also have CQs (continuous queries) that should be told > of the clear (need to research how CQs get events). If a client does not have > any subscriptions then the server will not have a subscription queue so in > that case the clear does not need to be sent to it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9123) Notify clients when partitioned region is cleared
Kirk Lund created GEODE-9123: Summary: Notify clients when partitioned region is cleared Key: GEODE-9123 URL: https://issues.apache.org/jira/browse/GEODE-9123 Project: Geode Issue Type: New Feature Components: client queues, client/server, regions Reporter: Kirk Lund Notify clients when partitioned region is cleared. Clients require notifications for cache listeners and subscriptions. On the server subscription data goes to the client through a server side CacheClientNotifier. On the client we have a single CacheClientUpdater thread that receives it. We also have CQs (continuous queries) that should be told of the clear (need to research how CQs get events). If a client does not have any subscriptions then the server will not have a subscription queue so in that case the clear does not need to be sent to it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9123) Notify clients when partitioned region is cleared
[ https://issues.apache.org/jira/browse/GEODE-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-9123: Assignee: Kirk Lund > Notify clients when partitioned region is cleared > - > > Key: GEODE-9123 > URL: https://issues.apache.org/jira/browse/GEODE-9123 > Project: Geode > Issue Type: New Feature > Components: client queues, client/server, regions >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI > > Notify clients when partitioned region is cleared. Clients require > notifications for cache listeners and subscriptions. > On the server subscription data goes to the client through a server side > CacheClientNotifier. On the client we have a single CacheClientUpdater thread > that receives it. We also have CQs (continuous queries) that should be told > of the clear (need to research how CQs get events). If a client does not have > any subscriptions then the server will not have a subscription queue so in > that case the clear does not need to be sent to it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9124) org.apache.geode.management.internal.function.RebalanceFunction logging needs improvement
Lynn Gallinat created GEODE-9124:
Summary:
org.apache.geode.management.internal.function.RebalanceFunction logging needs
improvement
Key: GEODE-9124
URL: https://issues.apache.org/jira/browse/GEODE-9124
Project: Geode
Issue Type: Bug
Components: functions
Affects Versions: 1.15.0
Reporter: Lynn Gallinat
The output from the RebalanceFunction is confusing. Two "Starting
RebalanceFunction..." messages are logged.
The first logged message provides results from the rebalance implying it's
complete, then we log a second time saying rebalance is starting.
Starting RebalanceFunction got results = \{totalBucketCreateBytes=0,
totalBucketCreateTimeInMilliseconds=0, totalBucketCreatesCompleted=0,
totalBucketTransferBytes=163831, totalBucketTransferTimeInMilliseconds=2836,
totalBucketTransfersCompleted=85, totalPrimaryTransferTimeInMilliseconds=139,
totalPrimaryTransfersCompleted=5, totalTimeInMilliseconds=3301,
totalNumOfMembers=7}
Starting RebalanceFunction str1=0,0,0,163831,2836,85,139,5,3301,7,/testRegion
By the time both of these are logged rebalance is in fact completed so it
shouldn't say "Starting..."
{code:java}
if (simulate.equals("true")) {
op = rbFactory.simulate();
} else {
op = rbFactory.start();<=== starting
}
try {
results = op.getResults();< completed
logger.info("Starting RebalanceFunction got results = {}", results);
StringBuilder str1 = new StringBuilder();
str1.append(results.getTotalBucketCreateBytes()).append(",")
.append(results.getTotalBucketCreateTime()).append(",")
.append(results.getTotalBucketCreatesCompleted()).append(",")
.append(results.getTotalBucketTransferBytes()).append(",")
.append(results.getTotalBucketTransferTime()).append(",")
.append(results.getTotalBucketTransfersCompleted()).append(",")
.append(results.getTotalPrimaryTransferTime()).append(",")
.append(results.getTotalPrimaryTransfersCompleted()).append(",")
.append(results.getTotalTime()).append(",").append(results.getTotalMembersExecutedOn())
.append(",").append(String.join(",", includeRegionNames));
logger.info("Starting RebalanceFunction str1={}", str1);
context.getResultSender().lastResult(str1.toString());
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9125) For a server with no default cache server turned on, the management rest getMember information would return wrong information
Jinmei Liao created GEODE-9125: -- Summary: For a server with no default cache server turned on, the management rest getMember information would return wrong information Key: GEODE-9125 URL: https://issues.apache.org/jira/browse/GEODE-9125 Project: Geode Issue Type: Bug Components: management Reporter: Jinmei Liao When a server launcher is launched with no default server, the GetMemberInformationFunction would return wrong member info: with isServer to be false and no status field. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9125) For a server with no default cache server turned on, the management rest getMember information would return wrong information
[ https://issues.apache.org/jira/browse/GEODE-9125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-9125: -- Assignee: Jinmei Liao > For a server with no default cache server turned on, the management rest > getMember information would return wrong information > - > > Key: GEODE-9125 > URL: https://issues.apache.org/jira/browse/GEODE-9125 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > > When a server launcher is launched with no default server, the > GetMemberInformationFunction would return wrong member info: with isServer to > be false and no status field. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9125) For a server with no default cache server turned on, the management rest getMember information would return wrong information
[ https://issues.apache.org/jira/browse/GEODE-9125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9125: -- Labels: pull-request-available (was: ) > For a server with no default cache server turned on, the management rest > getMember information would return wrong information > - > > Key: GEODE-9125 > URL: https://issues.apache.org/jira/browse/GEODE-9125 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > > When a server launcher is launched with no default server, the > GetMemberInformationFunction would return wrong member info: with isServer to > be false and no status field. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9064) Configure serialization filtering for JMX/RMI by default on Java 11
[ https://issues.apache.org/jira/browse/GEODE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315800#comment-17315800 ] ASF subversion and git services commented on GEODE-9064: Commit 69c30a25008e0aa7b0c51c00bedd97c3cc68037e in geode's branch refs/heads/GEODE-9064-support-1.12 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=69c30a2 ] GEODE-9064: Configure serial filter during ManagementAgent start (#6196) The Geode JMX layer will configure the system property “jmx.remote.rmi.server.serial.filter.pattern" to only accept JDK classes identified as open-types required for JMX. If the system property already has a value then Geode will log a statement and leave the system property alone. (cherry picked from commit c43dbc59dd54df3538598e85243698840f8b6541) > Configure serialization filtering for JMX/RMI by default on Java 11 > --- > > Key: GEODE-9064 > URL: https://issues.apache.org/jira/browse/GEODE-9064 > Project: Geode > Issue Type: Improvement > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The Geode JMX layer should configure the > “jmx.remote.rmi.server.serial.filter.pattern” system property on Java 11 to > accept only JDK classes identified as open-types for JMX. If the user or > another library has already set this system property, then Geode will log a > statement and leave it alone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8926) CQ events can be missed while executing with initial results simultaneously with transactions
[ https://issues.apache.org/jira/browse/GEODE-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315807#comment-17315807 ] Wayne commented on GEODE-8926: -- Waiting for results of regression run. > CQ events can be missed while executing with initial results simultaneously > with transactions > - > > Key: GEODE-8926 > URL: https://issues.apache.org/jira/browse/GEODE-8926 > Project: Geode > Issue Type: Bug > Components: cq >Reporter: Barrett Oglesby >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Attachments: cq_with_transaction_behavior.png > > > In this case, the event is not in either the initial results or received in > the CqListener. > A test that shows the behavior is: > - 2 servers with: > - a root PR > - a colocated child PR > In a client, asynchronously: > - start a transaction that: > - does N puts into the root PR > - does 1 put into the child PR > - commit the transaction > In the client: > create N CQs with initial results with: 'select * from /childPR' > When the test succeeds, all the CQs either get the 1 event in their initial > results or in their CqListener. > When the test fails, one or more CQs don't see the event either way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9064) Configure serialization filtering for JMX/RMI by default on Java 11
[ https://issues.apache.org/jira/browse/GEODE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315847#comment-17315847 ] ASF subversion and git services commented on GEODE-9064: Commit 5a3de7823e310ab8427d52b1d00780c92c99507a in geode's branch refs/heads/support/1.13 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5a3de78 ] GEODE-9064: Configure serial filter during ManagementAgent start (#6196) The Geode JMX layer will configure the system property “jmx.remote.rmi.server.serial.filter.pattern" to only accept JDK classes identified as open-types required for JMX. If the system property already has a value then Geode will log a statement and leave the system property alone. (cherry picked from commit c43dbc59dd54df3538598e85243698840f8b6541) > Configure serialization filtering for JMX/RMI by default on Java 11 > --- > > Key: GEODE-9064 > URL: https://issues.apache.org/jira/browse/GEODE-9064 > Project: Geode > Issue Type: Improvement > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The Geode JMX layer should configure the > “jmx.remote.rmi.server.serial.filter.pattern” system property on Java 11 to > accept only JDK classes identified as open-types for JMX. If the user or > another library has already set this system property, then Geode will log a > statement and leave it alone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9084) Remove Redis GFSH command
[ https://issues.apache.org/jira/browse/GEODE-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315852#comment-17315852 ] ASF subversion and git services commented on GEODE-9084: Commit c1b8e52321aa204912357a706a0faea1444f913f in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c1b8e52 ] GEODE-9084: Removed the redis gfsh command. (#6271) * This command is not needed as per the new design of geode compatible with redis module. > Remove Redis GFSH command > - > > Key: GEODE-9084 > URL: https://issues.apache.org/jira/browse/GEODE-9084 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > Things have changed since we first introduced the concept of Unsupported vs > Unimplemented. > _Original Idea:_ Allow users to use the unsupported commands, log which one's > were being used. Use this information to help drive future iterations. > Given: > * new direction of the product (Tanzu Cache) > * Safety for customers not to get into a bad situation > * Confusion for support, our team, the field > We should remove the ability to use the unsupported commands unless the > system property 'enable-unsupported-commands' is set. > > End result: > * The 'redis' gfsh command is no longer present > * Remove the documentation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9064) Configure serialization filtering for JMX/RMI by default on Java 11
[ https://issues.apache.org/jira/browse/GEODE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315866#comment-17315866 ] ASF subversion and git services commented on GEODE-9064: Commit 74e55649e4fb28fcecc1cdf1a6375eaba5742720 in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=74e5564 ] GEODE-9064: Configure serial filter during ManagementAgent start (#6196) The Geode JMX layer will configure the system property “jmx.remote.rmi.server.serial.filter.pattern" to only accept JDK classes identified as open-types required for JMX. If the system property already has a value then Geode will log a statement and leave the system property alone. (cherry picked from commit c43dbc59dd54df3538598e85243698840f8b6541) > Configure serialization filtering for JMX/RMI by default on Java 11 > --- > > Key: GEODE-9064 > URL: https://issues.apache.org/jira/browse/GEODE-9064 > Project: Geode > Issue Type: Improvement > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The Geode JMX layer should configure the > “jmx.remote.rmi.server.serial.filter.pattern” system property on Java 11 to > accept only JDK classes identified as open-types for JMX. If the user or > another library has already set this system property, then Geode will log a > statement and leave it alone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9121) Regression Introduced Through GEODE-8905
[
https://issues.apache.org/jira/browse/GEODE-9121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-9121:
Assignee: Udo Kohlmeyer
> Regression Introduced Through GEODE-8905
>
>
> Key: GEODE-9121
> URL: https://issues.apache.org/jira/browse/GEODE-9121
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Udo Kohlmeyer
>Priority: Major
> Attachments: workspace.zip
>
>
> The new implementation of the {{JarDeploymentService}} seems to be deleting
> resources when a member is gracefully shutdown, which in turns generates a
> race condition if there are functions being executed on the member during
> that time.
> In previous versions, a client application would simply retry the operation
> and no exception or loss of availability would be seen, right now the
> following exception is thrown on the client instead:
> {noformat}
> Exception in thread "main" org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerOperationException: remote server on
> 192.168.0.73(3985:loner):49836:c9f57ea7: The function, , has not been
> registered
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:237)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:184)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:388)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
> at test.TestClient.main(TestClient.java:20)
> Caused by: org.apache.geode.cache.client.ServerOperationException: remote
> server on 192.168.0.73(3985:loner):49836:c9f57ea7: The function, ,
> has not been registered
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionSingleHopOp$ExecuteRegionFunctionSingleHopOpImpl.processResponse(ExecuteRegionFunctionSingleHopOp.java:370)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:224)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:197)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:384)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:355)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:756)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:335)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:304)
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:840)
> at
> org.apache.geode.cache.client.internal.SingleHopOperationCallable.call(SingleHopOperationCallable.java:49)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {noformat}
> This seems to be a regression introduced through GEODE-8905. I've tested the
> same scenario with version {{1.13.2}} (released), branch {{support/1.14}} and
> commit [b80094ec5e|https://github.com/apache/geode/commit/b80094ec5e] with no
> problems at all. When testing using commit
> [6f764a7046|https://github.com/apache/geode/commit/6f764a7046], on the other
> hand, the problem is easily reproducible.
> —
> How to reproduce the issue:
> 1. Download and extract {{workspace.zip}}.
> 2. Execute the {{reproduce.sh}} script and follow the instructions on screen.
> The version of {{Geode}} to use on server side can be changed through the
> {{GEMFIRE}} variable within the {{reproduce.sh}} script.
> The version of {{Geode}} to use on client side can be changed through the
> {{GEODE_VERSION}} variable within the {{launch_client.sh}} script.
> The client application simply executes the {{TestFunction}} forever. When
> running the scenario using a version of {{Geode}} that doesn't include commit
> [6f764a7046|https://github.com/apache/geode/commit/6f764a7046], the client
> simply
[jira] [Commented] (GEODE-9064) Configure serialization filtering for JMX/RMI by default on Java 11
[ https://issues.apache.org/jira/browse/GEODE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315873#comment-17315873 ] ASF subversion and git services commented on GEODE-9064: Commit 6bb9ba0a0100221d8ea2f139622ce11227f08c68 in geode's branch refs/heads/support/1.12 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6bb9ba0 ] GEODE-9064: Configure serial filter during ManagementAgent start (#6196) The Geode JMX layer will configure the system property “jmx.remote.rmi.server.serial.filter.pattern" to only accept JDK classes identified as open-types required for JMX. If the system property already has a value then Geode will log a statement and leave the system property alone. (cherry picked from commit c43dbc59dd54df3538598e85243698840f8b6541) > Configure serialization filtering for JMX/RMI by default on Java 11 > --- > > Key: GEODE-9064 > URL: https://issues.apache.org/jira/browse/GEODE-9064 > Project: Geode > Issue Type: Improvement > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The Geode JMX layer should configure the > “jmx.remote.rmi.server.serial.filter.pattern” system property on Java 11 to > accept only JDK classes identified as open-types for JMX. If the user or > another library has already set this system property, then Geode will log a > statement and leave it alone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9064) Configure serialization filtering for JMX/RMI by default on Java 11
[ https://issues.apache.org/jira/browse/GEODE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315890#comment-17315890 ] ASF subversion and git services commented on GEODE-9064: Commit 7316a50ffa03f0472ab111b1a8940214eb86a4de in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7316a50 ] Revert "GEODE-9064: Configure serial filter during ManagementAgent start (#6196)" This reverts commit 6bb9ba0a0100221d8ea2f139622ce11227f08c68. reason: compile failed > Configure serialization filtering for JMX/RMI by default on Java 11 > --- > > Key: GEODE-9064 > URL: https://issues.apache.org/jira/browse/GEODE-9064 > Project: Geode > Issue Type: Improvement > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The Geode JMX layer should configure the > “jmx.remote.rmi.server.serial.filter.pattern” system property on Java 11 to > accept only JDK classes identified as open-types for JMX. If the user or > another library has already set this system property, then Geode will log a > statement and leave it alone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8833) client event.setPossibleDuplicate sometimes is not set correctly
[ https://issues.apache.org/jira/browse/GEODE-8833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315893#comment-17315893 ] ASF subversion and git services commented on GEODE-8833: Commit ced9d7bd05df61402978044aa3c062cdfb039f43 in geode's branch refs/heads/support/1.12 from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ced9d7b ] GEODE-8833: Set possible dupliate flag for persistent region (#5904) For persistent region, even though a version tag is not recovered, the possibleDuplicate flag is still needed to be set for the client retry message. (cherry picked from commit 69ba7dd3f3053bd773c2737f32c3b90f6aba51b3) > client event.setPossibleDuplicate sometimes is not set correctly > > > Key: GEODE-8833 > URL: https://issues.apache.org/jira/browse/GEODE-8833 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.13.2, 1.14.0 > > > In Put command, geode sets event possibleDuplicate flag to true if the event > is a retry. However, it could then set to false if it can not successfully > find the version tag. In persistence case, this is incorrect as there is a > case that data can be recovered from persistence. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9084) Remove Redis GFSH command
[ https://issues.apache.org/jira/browse/GEODE-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag updated GEODE-9084: --- Fix Version/s: 1.15.0 1.14.0 > Remove Redis GFSH command > - > > Key: GEODE-9084 > URL: https://issues.apache.org/jira/browse/GEODE-9084 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Things have changed since we first introduced the concept of Unsupported vs > Unimplemented. > _Original Idea:_ Allow users to use the unsupported commands, log which one's > were being used. Use this information to help drive future iterations. > Given: > * new direction of the product (Tanzu Cache) > * Safety for customers not to get into a bad situation > * Confusion for support, our team, the field > We should remove the ability to use the unsupported commands unless the > system property 'enable-unsupported-commands' is set. > > End result: > * The 'redis' gfsh command is no longer present > * Remove the documentation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9084) Remove Redis GFSH command
[ https://issues.apache.org/jira/browse/GEODE-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-9084. Resolution: Fixed > Remove Redis GFSH command > - > > Key: GEODE-9084 > URL: https://issues.apache.org/jira/browse/GEODE-9084 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Things have changed since we first introduced the concept of Unsupported vs > Unimplemented. > _Original Idea:_ Allow users to use the unsupported commands, log which one's > were being used. Use this information to help drive future iterations. > Given: > * new direction of the product (Tanzu Cache) > * Safety for customers not to get into a bad situation > * Confusion for support, our team, the field > We should remove the ability to use the unsupported commands unless the > system property 'enable-unsupported-commands' is set. > > End result: > * The 'redis' gfsh command is no longer present > * Remove the documentation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9084) Remove Redis GFSH command
[ https://issues.apache.org/jira/browse/GEODE-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315896#comment-17315896 ] ASF subversion and git services commented on GEODE-9084: Commit d3f3a0908edea4f552684b322b2eb8119565ec0a in geode's branch refs/heads/support/1.14 from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d3f3a09 ] GEODE-9084: Removed the redis gfsh command. (#6271) (#6274) * This command is not needed as per the new design of geode compatible with redis module. (cherry picked from commit c1b8e52321aa204912357a706a0faea1444f913f) > Remove Redis GFSH command > - > > Key: GEODE-9084 > URL: https://issues.apache.org/jira/browse/GEODE-9084 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Things have changed since we first introduced the concept of Unsupported vs > Unimplemented. > _Original Idea:_ Allow users to use the unsupported commands, log which one's > were being used. Use this information to help drive future iterations. > Given: > * new direction of the product (Tanzu Cache) > * Safety for customers not to get into a bad situation > * Confusion for support, our team, the field > We should remove the ability to use the unsupported commands unless the > system property 'enable-unsupported-commands' is set. > > End result: > * The 'redis' gfsh command is no longer present > * Remove the documentation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9126) bump jetty to recommended version
Owen Nichols created GEODE-9126: --- Summary: bump jetty to recommended version Key: GEODE-9126 URL: https://issues.apache.org/jira/browse/GEODE-9126 Project: Geode Issue Type: Improvement Components: rest (admin), rest (dev) Reporter: Owen Nichols 9.4.38 -> 9.4.39 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9126) bump jetty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9126: -- Labels: pull-request-available (was: ) > bump jetty to recommended version > - > > Key: GEODE-9126 > URL: https://issues.apache.org/jira/browse/GEODE-9126 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > 9.4.38 -> 9.4.39 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9126) bump jetty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315904#comment-17315904 ] ASF subversion and git services commented on GEODE-9126: Commit 890106ac28f1d0cf4740ff35ce5c068bf86f4051 in geode's branch refs/heads/support/1.14 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=890106a ] GEODE-9126: Bump jetty from 9.4.38.v20210224 to 9.4.39.v20210325 > bump jetty to recommended version > - > > Key: GEODE-9126 > URL: https://issues.apache.org/jira/browse/GEODE-9126 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > 9.4.38 -> 9.4.39 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9126) bump jetty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315905#comment-17315905 ] ASF subversion and git services commented on GEODE-9126: Commit c16641c2ed26969793a1969cfbc8875589a76342 in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c16641c ] GEODE-9126: Bump jetty from 9.4.38.v20210224 to 9.4.39.v20210325 > bump jetty to recommended version > - > > Key: GEODE-9126 > URL: https://issues.apache.org/jira/browse/GEODE-9126 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > 9.4.38 -> 9.4.39 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9126) bump jetty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315906#comment-17315906 ] ASF subversion and git services commented on GEODE-9126: Commit 553b2676f6a0b14814280eca5339d10c80bbf496 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=553b267 ] GEODE-9126: Bump jetty from 9.4.38.v20210224 to 9.4.39.v20210325 > bump jetty to recommended version > - > > Key: GEODE-9126 > URL: https://issues.apache.org/jira/browse/GEODE-9126 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > 9.4.38 -> 9.4.39 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9126) bump jetty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9126. - Fix Version/s: 1.15.0 1.14.0 1.13.3 1.12.2 Resolution: Fixed > bump jetty to recommended version > - > > Key: GEODE-9126 > URL: https://issues.apache.org/jira/browse/GEODE-9126 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.2, 1.13.3, 1.14.0, 1.15.0 > > > 9.4.38 -> 9.4.39 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9070) CI Failure: ClientServerSessionCacheDUnitTest > addServerToExistingClusterCreatesSessionRegion
[
https://issues.apache.org/jira/browse/GEODE-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315911#comment-17315911
]
Geode Integration commented on GEODE-9070:
--
Seen in [DistributedTestOpenJDK8
#134.2|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/134.2]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0119/test-results/distributedTest/1617691918/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0119/test-artifacts/1617691918/distributedtestfiles-OpenJDK8-1.15.0-build.0119.tgz].
> CI Failure: ClientServerSessionCacheDUnitTest >
> addServerToExistingClusterCreatesSessionRegion
> --
>
> Key: GEODE-9070
> URL: https://issues.apache.org/jira/browse/GEODE-9070
> Project: Geode
> Issue Type: Bug
> Components: ci, http session
>Reporter: Jens Deppe
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest >
> addServerToExistingClusterCreatesSessionRegion FAILED
> 00:47:45org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest$$Lambda$84/1299235653.run
> in VM 1 running on Host 51208612ea94 with 4 VMs
> 00:47:45at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 00:47:45at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.addServerToExistingClusterCreatesSessionRegion(ClientServerSessionCacheDUnitTest.java:100)
> 00:47:45
> 00:47:45Caused by:
> 00:47:45org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest
> 00:47:45Expected size: 1 but was: 0 in:
> 00:47:45[] within 5 minutes.
> 00:47:45at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 00:47:45at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 00:47:45at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 00:47:45at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 00:47:45at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.lambda$addServerToExistingClusterCreatesSessionRegion$bb17a952$1(ClientServerSessionCacheDUnitTest.java:100)
> 00:47:45
> 00:47:45Caused by:
> 00:47:45java.lang.AssertionError:
> 00:47:45Expected size: 1 but was: 0 in:
> 00:47:45[]
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateBootstrapped(ClientServerSessionCacheDUnitTest.java:258)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateServer(ClientServerSessionCacheDUnitTest.java:245)
> 00:47:53{noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161716/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161716/distributedtestfiles-OpenJDK8-1.15.0-build.0081.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315912#comment-17315912
]
Geode Integration commented on GEODE-7710:
--
Seen in [DistributedTestOpenJDK8
#135|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/135]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0120/test-results/distributedTest/1617737186/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0120/test-artifacts/1617737186/distributedtestfiles-OpenJDK8-1.15.0-build.0120.tgz].
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9122) Setting group-transaction-events=true can cause ConcurrentModificationExceptions
[
https://issues.apache.org/jira/browse/GEODE-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9122:
--
Labels: pull-request-available (was: )
> Setting group-transaction-events=true can cause
> ConcurrentModificationExceptions
>
>
> Key: GEODE-9122
> URL: https://issues.apache.org/jira/browse/GEODE-9122
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> The
> SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
> test can throw a ConcurrentModificationException like:
> {noformat}
> [warn 2021/04/04 02:55:53.253 GMT
> tid=0x15d] An Exception occurred. The dispatcher will continue.
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1445)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1469)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue.peekEventsFromIncompleteTransactions(SerialGatewaySenderQueue.java:476)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue.peek(SerialGatewaySenderQueue.java:453)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:518)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:223)
> {noformat}
> If the SerialGatewaySenderQueue.peekEventsFromIncompleteTransactions contains
> more than one TransactionId, and one of them is removed, the
> ConcurrentModificationException will occur.
> Both the SerialGatewaySenderQueue and ParallelGatewaySenderQueue
> peekEventsFromIncompleteTransactions have the same implementation.
> These methods do:
> {noformat}
>while (true) {
> 1. ->for (TransactionId transactionId : incompleteTransactionIdsInBatch) {
>...
>if (...) {
> ...
> 2. -> incompleteTransactionIdsInBatch.remove(transactionId);
>}
> }
>}
> {noformat}
> The for-each loop (1) cannot be paired with the remove from the
> incompleteTransactionIdsInBatch set (2). As soon as the remove is called, the
> ConcurrentModificationException will be thrown the next time through the
> loop. Since this for loop is in a while (true) loop, it is an infinite loop.
> One way to address this would be to use an Iterator and call remove on the
> Iterator like:
> {noformat}
> 1. ->for (Iterator i =
> incompleteTransactionIdsInBatch.iterator(); i.hasNext();) {
>TransactionId transactionId = i.next();
>...
> 2. -> i.remove();
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
