[jira] [Created] (GEODE-10381) CI Failure: SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1] FAILED
Eric Shu created GEODE-10381:
Summary: CI Failure:
SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]
FAILED
Key: GEODE-10381
URL: https://issues.apache.org/jira/browse/GEODE-10381
Project: Geode
Issue Type: Bug
Reporter: Eric Shu
{noformat}
org.opentest4j.AssertionFailedError: [Exit value from process started by
[c4f0c1c64be0eb32: gfsh -e start locator --connect=false --http-service-port=0
--name=locator1
--bind-address=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal
--port=29435 --J=-Dgemfire.jmx-manager-port=29436
--security-properties-file=/home/geode/geode/geode-core/build/upgradeTest/test-worker-59/SocketCreatorUpgradeTest/upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]/newSecurity.properties
--locators=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal[29437]]]
expected: 0
but was: 1
at
jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown Source)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:146)
at
org.apache.geode.test.junit.rules.gfsh.GfshContext.doExecute(GfshContext.java:157)
at
org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:127)
at
org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:121)
at
org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties(SocketCreatorUpgradeTest.java:507)
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: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.RunBefores.evaluate(RunBefores.java:26)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75)
at
org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54)
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.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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)
[jira] [Assigned] (GEODE-10373) CI Failures: Windows geode-lucene:integrationTest hitting OOM cause CI test run to timeout
[ https://issues.apache.org/jira/browse/GEODE-10373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10373: Assignee: Robert Houghton > CI Failures: Windows geode-lucene:integrationTest hitting OOM cause CI test > run to timeout > -- > > Key: GEODE-10373 > URL: https://issues.apache.org/jira/browse/GEODE-10373 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Eric Shu >Assignee: Robert Houghton >Priority: Major > Labels: needsTriage > > LuceneIndexCommandsWithReindexAllowedIntegrationTest > > whenLuceneReindexingInProgressThenListIndexCommandMustExecuteSuccessfully > FAILED > java.lang.OutOfMemoryError: Java heap space -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10373) CI Failures: Windows geode-lucene:integrationTest hitting OOM cause CI test run to timeout
Eric Shu created GEODE-10373: Summary: CI Failures: Windows geode-lucene:integrationTest hitting OOM cause CI test run to timeout Key: GEODE-10373 URL: https://issues.apache.org/jira/browse/GEODE-10373 Project: Geode Issue Type: Bug Components: lucene Reporter: Eric Shu LuceneIndexCommandsWithReindexAllowedIntegrationTest > whenLuceneReindexingInProgressThenListIndexCommandMustExecuteSuccessfully FAILED java.lang.OutOfMemoryError: Java heap space -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10372) CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED
[ https://issues.apache.org/jira/browse/GEODE-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552368#comment-17552368 ] Eric Shu commented on GEODE-10372: -- Remove needs to triage label as this seems has the same cause of GEODE-10195 which is not targeted for 1.15 release. > CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED > -- > > Key: GEODE-10372 > URL: https://issues.apache.org/jira/browse/GEODE-10372 > Project: Geode > Issue Type: Bug >Reporter: Eric Shu >Priority: Major > > org.apache.geode.cache.client.ServerOperationException: remote server on > heavy-lifter-880ddf1e-8708-569e-aed8-b02a2ae3d5a6(6388:loner):58892:a17ee644: > Function named CheckIfMeterExistsFunction is not registered to FunctionService > at > org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394) > at > org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234) > at > org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209) > at > org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394) > 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:358) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151) > at > org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820) > at > org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377) > at > org.apache.geode.metrics.MicrometerBinderTest.uptimeMetricsBinderExists(MicrometerBinderTest.java:163) > 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: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.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75) > at > org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > 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.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
[jira] [Updated] (GEODE-10372) CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED
[ https://issues.apache.org/jira/browse/GEODE-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10372: - Labels: (was: needsTriage) > CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED > -- > > Key: GEODE-10372 > URL: https://issues.apache.org/jira/browse/GEODE-10372 > Project: Geode > Issue Type: Bug >Reporter: Eric Shu >Priority: Major > > org.apache.geode.cache.client.ServerOperationException: remote server on > heavy-lifter-880ddf1e-8708-569e-aed8-b02a2ae3d5a6(6388:loner):58892:a17ee644: > Function named CheckIfMeterExistsFunction is not registered to FunctionService > at > org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394) > at > org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234) > at > org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209) > at > org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394) > 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:358) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151) > at > org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820) > at > org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377) > at > org.apache.geode.metrics.MicrometerBinderTest.uptimeMetricsBinderExists(MicrometerBinderTest.java:163) > 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: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.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75) > at > org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > 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.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
[jira] [Commented] (GEODE-10372) CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED
[ https://issues.apache.org/jira/browse/GEODE-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552354#comment-17552354 ] Eric Shu commented on GEODE-10372: -- Possibly has the same cause of GEODE-10195. > CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED > -- > > Key: GEODE-10372 > URL: https://issues.apache.org/jira/browse/GEODE-10372 > Project: Geode > Issue Type: Bug >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.cache.client.ServerOperationException: remote server on > heavy-lifter-880ddf1e-8708-569e-aed8-b02a2ae3d5a6(6388:loner):58892:a17ee644: > Function named CheckIfMeterExistsFunction is not registered to FunctionService > at > org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394) > at > org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234) > at > org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209) > at > org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394) > 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:358) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151) > at > org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820) > at > org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377) > at > org.apache.geode.metrics.MicrometerBinderTest.uptimeMetricsBinderExists(MicrometerBinderTest.java:163) > 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: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.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75) > at > org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > 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.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 >
[jira] [Created] (GEODE-10372) CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED
Eric Shu created GEODE-10372: Summary: CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED Key: GEODE-10372 URL: https://issues.apache.org/jira/browse/GEODE-10372 Project: Geode Issue Type: Bug Reporter: Eric Shu org.apache.geode.cache.client.ServerOperationException: remote server on heavy-lifter-880ddf1e-8708-569e-aed8-b02a2ae3d5a6(6388:loner):58892:a17ee644: Function named CheckIfMeterExistsFunction is not registered to FunctionService at org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394) at org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234) at org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209) at org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394) 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:358) at org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760) at org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151) at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820) at org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100) at org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217) at org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104) at org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368) at org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377) at org.apache.geode.metrics.MicrometerBinderTest.uptimeMetricsBinderExists(MicrometerBinderTest.java:163) 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: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.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75) at org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) 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.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
[jira] [Resolved] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10294. -- Fix Version/s: 1.15.0 Resolution: Fixed > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0, 1.16.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10294: - Fix Version/s: 1.16.0 > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0, 1.16.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10294: - Fix Version/s: (was: 1.15.0) (was: 1.16.0) > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0, 1.16.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reopened GEODE-10294: -- > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0, 1.16.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10298) [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest > testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
[
https://issues.apache.org/jira/browse/GEODE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-10298:
-
Fix Version/s: (was: 1.16.0)
> [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
> -
>
> Key: GEODE-10298
> URL: https://issues.apache.org/jira/browse/GEODE-10298
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup 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 417
> [fatal 2022/05/10 18:57:14.216 UTC tid=226]
> Exception in processing request from 10.0.2.167
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> 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:750)
> 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.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:552)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:499)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:482)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.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
>
[jira] [Commented] (GEODE-10298) [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest > testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
[
https://issues.apache.org/jira/browse/GEODE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536946#comment-17536946
]
Eric Shu commented on GEODE-10298:
--
>From the test code and failed test run logs, this exception thrown is not
>caused by message sent by the failed test. As the locator is just being
>created.
{noformat}
The failed test run showing the logged exception thrown.
[vm0] [info 2022/05/10 18:57:14.088 UTC
tid=0x20] Reinitializing JarDeploymentService with new working directory:
/home/geode/geode/geode-wan/build/distributedTest/test-worker-000837/dunit/vm0
[vm0] [fatal 2022/05/10 18:57:14.216 UTC tid=0xe2]
Exception in processing request from 10.0.2.167
[vm0] java.lang.Exception: Improperly configured client detected - use
addPoolLocator to configure its locators instead of addPoolServer.
[vm0] at
org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
[vm0] at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
[vm0] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[vm0] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[vm0] at java.lang.Thread.run(Thread.java:750)
[vm0] [info 2022/05/10 18:57:14.468 UTC
tid=0x20] Initialized cache service
org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor
{noformat}
I have run the test with added logs and know that the locator is just being
started from the stack trace (logged from my own run of the test. There is no
peer or client being started in the test yet, and should not be able to send
any message at that time.
{noformat}
[vm0] [info 2022/05/11 16:39:21.759 PDT
tid=0x13] initializeServices stack
[vm0] java.lang.Exception
[vm0] at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeServices(GemFireCacheImpl.java:1499)
[vm0] at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1429)
[vm0] at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
[vm0] at
org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:780)
[vm0] at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:769)
[vm0] at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:400)
[vm0] at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:346)
[vm0] at org.apache.geode.distributed.Locator.startLocator(Locator.java:269)
[vm0] at
org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:213)
[vm0] at
org.apache.geode.cache.client.internal.LocatorTestBase.startLocator(LocatorTestBase.java:140)
[vm0] at
org.apache.geode.cache.client.internal.LocatorTestBase.lambda$startLocatorInVM$e4d36eca$1(LocatorTestBase.java:146)
[vm0] at
org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
[vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[vm0] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[vm0] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[vm0] at java.lang.reflect.Method.invoke(Method.java:498)
[vm0] at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
[vm0] at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
[vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[vm0] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[vm0] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[vm0] at java.lang.reflect.Method.invoke(Method.java:498)
[vm0] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
[vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
[vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
[vm0] at java.security.AccessController.doPrivileged(Native Method)
[vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
[vm0] at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
[vm0] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
[vm0] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
[vm0] at java.security.AccessController.doPrivileged(Native Method)
[vm0] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
[vm0] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[vm0] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[vm0] at
[jira] [Commented] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536943#comment-17536943 ] Eric Shu commented on GEODE-10294: -- This is a safe fix. I think this can be back-ported to 1.15 support branch. > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10294. -- Fix Version/s: 1.16.0 Resolution: Fixed > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10298) [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest > testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
[
https://issues.apache.org/jira/browse/GEODE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-10298.
--
Fix Version/s: 1.16.0
Resolution: Fixed
> [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
> -
>
> Key: GEODE-10298
> URL: https://issues.apache.org/jira/browse/GEODE-10298
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage
> Fix For: 1.16.0
>
>
> {noformat}
> GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup 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 417
> [fatal 2022/05/10 18:57:14.216 UTC tid=226]
> Exception in processing request from 10.0.2.167
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> 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:750)
> 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.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:552)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:499)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:482)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.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
>
[jira] [Reopened] (GEODE-10298) [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest > testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
[
https://issues.apache.org/jira/browse/GEODE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reopened GEODE-10298:
--
> [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
> -
>
> Key: GEODE-10298
> URL: https://issues.apache.org/jira/browse/GEODE-10298
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage
> Fix For: 1.16.0
>
>
> {noformat}
> GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup 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 417
> [fatal 2022/05/10 18:57:14.216 UTC tid=226]
> Exception in processing request from 10.0.2.167
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> 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:750)
> 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.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:552)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:499)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:482)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.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)
[jira] [Created] (GEODE-10308) CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
Eric Shu created GEODE-10308:
Summary: CI Failure:
Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
Key: GEODE-10308
URL: https://issues.apache.org/jira/browse/GEODE-10308
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Eric Shu
{noformat}
org.apache.geode.cache.CacheClosedException: The cache is closed.
at
org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5207)
at
org.apache.geode.internal.cache.LocalRegion$Stopper.generateCancelledException(LocalRegion.java:11342)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:87)
at
org.apache.geode.internal.cache.execute.InternalFunctionExecutionServiceImpl.onRegion(InternalFunctionExecutionServiceImpl.java:122)
at
org.apache.geode.cache.execute.FunctionService.onRegion(FunctionService.java:79)
at
org.apache.geode.modules.session.catalina.ClientServerSessionCache.getExecutionForFunctionOnRegionWithFilter(ClientServerSessionCache.java:283)
at
org.apache.geode.modules.session.catalina.ClientServerSessionCache.touchSessions(ClientServerSessionCache.java:101)
at
org.apache.geode.modules.session.catalina.DeltaSessionManager$1.run(DeltaSessionManager.java:534)
at java.util.TimerThread.mainLoop(Timer.java:556)
at java.util.TimerThread.run(Timer.java:506)
{noformat}
Artifacts can be found here:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/334
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10303) CI Failure: MemberMXBeanDistributedTest.testBucketCount failed due to insufficient memory
[
https://issues.apache.org/jira/browse/GEODE-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reassigned GEODE-10303:
Assignee: Robert Houghton
> CI Failure: MemberMXBeanDistributedTest.testBucketCount failed due to
> insufficient memory
> -
>
> Key: GEODE-10303
> URL: https://issues.apache.org/jira/browse/GEODE-10303
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Assignee: Robert Houghton
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.MemberMXBeanDistributedTest$$Lambda$354/1215689932.run
> in VM 1 running on Host
> heavy-lifter-7c5d091b-f00d-537f-882b-ff4e244a22ad.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:680)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> 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] [Created] (GEODE-10305) CI Failure: TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest failed
Eric Shu created GEODE-10305:
Summary: CI Failure:
TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
failed
Key: GEODE-10305
URL: https://issues.apache.org/jira/browse/GEODE-10305
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Eric Shu
{noformat}
org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures (2
failures)
org.opentest4j.AssertionFailedError: [The Cache Server process
terminated unexpectedly with exit status 1. Please refer to the log file in
/tmp/junit439159077415808630/server for full details.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/tmp/geode_container_install8549633813411705254/cargo_containers/Tomcat8AndCurrentModules/tomcat-8.5.66/apache-tomcat-8.5.66/lib/slf4j-jdk14-1.7.32.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/geode/geode/geode-assembly/build/install/apache-geode/lib/log4j-slf4j-impl-2.17.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]
{noformat}
This is caused by ForcedDisconnectException during cache creation.
{noformat}
Exception in thread "main"
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on
heavy-lifter-e2fd6dd2-c530-54ef-ab7c-b95e0e8cca34(server:240126):41036
started at Thu May 05 21:36:30 UTC 2022: Member isn't responding to heartbeat
requests, caused by org.apache.geode.ForcedDisconnectException: Member isn't
responding to heartbeat requests
at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2899)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1183)
at
org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5201)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.cache.query.cq.internal.CqServiceImpl.(CqServiceImpl.java:166)
at
org.apache.geode.cache.query.cq.internal.CqServiceFactoryImpl.create(CqServiceFactoryImpl.java:59)
at
org.apache.geode.cache.query.internal.cq.CqServiceProvider.create(CqServiceProvider.java:63)
at
org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:1004)
at
org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:864)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:913)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:814)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:740)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:259)
Caused by: org.apache.geode.ForcedDisconnectException: Member isn't responding
to heartbeat requests
at
org.apache.geode.distributed.internal.DistributionImpl$LifecycleListenerImpl.forcedDisconnect(DistributionImpl.java:941)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1792)
at java.lang.Thread.run(Thread.java:750)
{noformat}
Artifacts can be found here:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/331
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10304) CI Failure: ReconnectDUnitTest.testReconnectALocator
Eric Shu created GEODE-10304:
Summary: CI Failure: ReconnectDUnitTest.testReconnectALocator
Key: GEODE-10304
URL: https://issues.apache.org/jira/browse/GEODE-10304
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Eric Shu
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache30.ReconnectDUnitTest$14.run in VM 0 running on Host
heavy-lifter-2ef8f049-b612-51d7-862a-3722e231b1de.c.apachegeode-ci.internal
with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:676)
at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
at
org.apache.geode.cache30.ReconnectDUnitTest.assertGfshWaitingThreadAlive(ReconnectDUnitTest.java:646)
at
org.apache.geode.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:587)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.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-10303) CI Failure: MemberMXBeanDistributedTest.testBucketCount failed due to insufficient memory
Eric Shu created GEODE-10303:
Summary: CI Failure: MemberMXBeanDistributedTest.testBucketCount
failed due to insufficient memory
Key: GEODE-10303
URL: https://issues.apache.org/jira/browse/GEODE-10303
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Eric Shu
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.management.MemberMXBeanDistributedTest$$Lambda$354/1215689932.run
in VM 1 running on Host
heavy-lifter-7c5d091b-f00d-537f-882b-ff4e244a22ad.c.apachegeode-ci.internal
with 5 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:680)
at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
at
org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
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
[jira] [Assigned] (GEODE-10298) [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest > testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
[
https://issues.apache.org/jira/browse/GEODE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reassigned GEODE-10298:
Assignee: Eric Shu
> [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
> -
>
> Key: GEODE-10298
> URL: https://issues.apache.org/jira/browse/GEODE-10298
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup 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 417
> [fatal 2022/05/10 18:57:14.216 UTC tid=226]
> Exception in processing request from 10.0.2.167
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> 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:750)
> 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.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:552)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:499)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:482)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.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)
>
[jira] [Assigned] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10294: Assignee: Eric Shu > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
Eric Shu created GEODE-10294: Summary: Need to consider invalid token when comparing value during putIfAbsent Key: GEODE-10294 URL: https://issues.apache.org/jira/browse/GEODE-10294 Project: Geode Issue Type: Bug Components: regions Reporter: Eric Shu During retry of putIfAbsent, there is a possibility that value has been created by the initial operation. Geode treats this as a successful operation, so that client initiated the operation will also create the entry in its local cache. However, putIfAbsent of null is a special case, as an Invalid Token is created instead of null value being put into the region entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10294: - Labels: blocks-1.15.0 (was: needsTriage) > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0 > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10272) CI failure: SerialGatewaySenderEventProcessor throws RejectedExecutionException in handlePrimaryDestroy
[
https://issues.apache.org/jira/browse/GEODE-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-10272.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> CI failure: SerialGatewaySenderEventProcessor throws
> RejectedExecutionException in handlePrimaryDestroy
>
>
> Key: GEODE-10272
> URL: https://issues.apache.org/jira/browse/GEODE-10272
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14917007]
>
> {noformat}
> > Task :geode-wan:distributedTest
> SerialWANPropagationOffHeapDUnitTest >
> testReplicatedSerialPropagationWithRemoteReceiverRestarted_SenderReceiverPersistent
> 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-vm5.log' at line 578
> [error 2022/04/30 17:54:20.129 UTC heavy-lifter-85578c19-4fe0-5ec7-80ff-b9bbbad743e3(875001):51004 unshared
> ordered sender uid=22 dom #1 local port=51185 remote port=59364> tid=172]
> Exception occurred in CacheListener
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor$$Lambda$419/1037103054@1aae2bfe
> rejected from java.util.concurrent.ThreadPoolExecutor@7d2e5a91[Shutting
> down, pool size = 1, active threads = 0, queued tasks = 0, completed tasks =
> 8478]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.handlePrimaryDestroy(SerialGatewaySenderEventProcessor.java:592)
> at
> org.apache.geode.internal.cache.wan.serial.SerialSecondaryGatewayListener.afterDestroy(SerialSecondaryGatewayListener.java:92)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_DESTROY.dispatchEvent(EnumListenerEvent.java:183)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8313)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7021)
> at
> org.apache.geode.internal.cache.LocalRegion.invokeDestroyCallbacks(LocalRegion.java:6822)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2454)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:164)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyPart2(LocalRegion.java:6763)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:420)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:244)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:152)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:940)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6552)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6526)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:59)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6477)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroy(DistributedRegion.java:1745)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue$SerialGatewaySenderQueueMetaRegion.basicDestroy(SerialGatewaySenderQueue.java:1372)
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroy(LocalRegion.java:2261)
> at
> org.apache.geode.internal.cache.DistributedRegion.localDestroy(DistributedRegion.java:981)
> at
> org.apache.geode.internal.cache.wan.serial.BatchDestroyOperation$DestroyMessage.operateOnRegion(BatchDestroyOperation.java:121)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1196)
> at
>
[jira] [Resolved] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10242. -- Fix Version/s: 1.15.0 Resolution: Fixed > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10272) CI failure: SerialGatewaySenderEventProcessor throws RejectedExecutionException in handlePrimaryDestroy
[
https://issues.apache.org/jira/browse/GEODE-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reassigned GEODE-10272:
Assignee: Eric Shu
> CI failure: SerialGatewaySenderEventProcessor throws
> RejectedExecutionException in handlePrimaryDestroy
>
>
> Key: GEODE-10272
> URL: https://issues.apache.org/jira/browse/GEODE-10272
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14917007]
>
> {noformat}
> > Task :geode-wan:distributedTest
> SerialWANPropagationOffHeapDUnitTest >
> testReplicatedSerialPropagationWithRemoteReceiverRestarted_SenderReceiverPersistent
> 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-vm5.log' at line 578
> [error 2022/04/30 17:54:20.129 UTC heavy-lifter-85578c19-4fe0-5ec7-80ff-b9bbbad743e3(875001):51004 unshared
> ordered sender uid=22 dom #1 local port=51185 remote port=59364> tid=172]
> Exception occurred in CacheListener
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor$$Lambda$419/1037103054@1aae2bfe
> rejected from java.util.concurrent.ThreadPoolExecutor@7d2e5a91[Shutting
> down, pool size = 1, active threads = 0, queued tasks = 0, completed tasks =
> 8478]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.handlePrimaryDestroy(SerialGatewaySenderEventProcessor.java:592)
> at
> org.apache.geode.internal.cache.wan.serial.SerialSecondaryGatewayListener.afterDestroy(SerialSecondaryGatewayListener.java:92)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_DESTROY.dispatchEvent(EnumListenerEvent.java:183)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8313)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7021)
> at
> org.apache.geode.internal.cache.LocalRegion.invokeDestroyCallbacks(LocalRegion.java:6822)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2454)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:164)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyPart2(LocalRegion.java:6763)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:420)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:244)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:152)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:940)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6552)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6526)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:59)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6477)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroy(DistributedRegion.java:1745)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue$SerialGatewaySenderQueueMetaRegion.basicDestroy(SerialGatewaySenderQueue.java:1372)
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroy(LocalRegion.java:2261)
> at
> org.apache.geode.internal.cache.DistributedRegion.localDestroy(DistributedRegion.java:981)
> at
> org.apache.geode.internal.cache.wan.serial.BatchDestroyOperation$DestroyMessage.operateOnRegion(BatchDestroyOperation.java:121)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1196)
> at
>
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10242: - Labels: GeodeOperationAPI blocks-1.15.0 needsTriage (was: blocks-1.15.0 needsTriage) > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10242: Assignee: Eric Shu > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10242: - Labels: blocks-1.15.0 needsTriage (was: needsTriage) > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Eric Shu >Priority: Major > Labels: blocks-1.15.0, needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
Eric Shu created GEODE-10242: Summary: Same tail key can be generated for different events on (different colocated regions) from different servers Key: GEODE-10242 URL: https://issues.apache.org/jira/browse/GEODE-10242 Project: Geode Issue Type: Bug Components: wan Reporter: Eric Shu For colocated partition regions with parallel wan queue, rebalance could cause primary to be moved. This can lead to a case that one server has the primary bucket for the parent region, but another has the primary bucket for the child region. As colocated regions show the same parallel wan queue, both server will generate next tail key for different events. This will cause some event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10242: - Affects Version/s: 1.12.0 > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Priority: Major > Labels: blocks-1.15.0, needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled
[ https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10234: - Labels: blocks-1.15.0 pull-request-available (was: pull-request-available) > No need to generate tailKey for transaction if there is no parallel wan > enabled > --- > > Key: GEODE-10234 > URL: https://issues.apache.org/jira/browse/GEODE-10234 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > There is no need to generate a tailKey, if there is no parallel wan enabled. > However, currently every operation on a partitioned region would generate > such key and will be ignored anyway. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled
[ https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10234. -- Fix Version/s: 1.15.0 Resolution: Fixed > No need to generate tailKey for transaction if there is no parallel wan > enabled > --- > > Key: GEODE-10234 > URL: https://issues.apache.org/jira/browse/GEODE-10234 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > There is no need to generate a tailKey, if there is no parallel wan enabled. > However, currently every operation on a partitioned region would generate > such key and will be ignored anyway. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled
[ https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10234: - Affects Version/s: 1.12.0 > No need to generate tailKey for transaction if there is no parallel wan > enabled > --- > > Key: GEODE-10234 > URL: https://issues.apache.org/jira/browse/GEODE-10234 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > There is no need to generate a tailKey, if there is no parallel wan enabled. > However, currently every operation on a partitioned region would generate > such key and will be ignored anyway. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled
[ https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10234: - Labels: (was: needsTriage) > No need to generate tailKey for transaction if there is no parallel wan > enabled > --- > > Key: GEODE-10234 > URL: https://issues.apache.org/jira/browse/GEODE-10234 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > There is no need to generate a tailKey, if there is no parallel wan enabled. > However, currently every operation on a partitioned region would generate > such key and will be ignored anyway. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled
[ https://issues.apache.org/jira/browse/GEODE-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10234: Assignee: Eric Shu > No need to generate tailKey for transaction if there is no parallel wan > enabled > --- > > Key: GEODE-10234 > URL: https://issues.apache.org/jira/browse/GEODE-10234 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > There is no need to generate a tailKey, if there is no parallel wan enabled. > However, currently every operation on a partitioned region would generate > such key and will be ignored anyway. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10234) No need to generate tailKey for transaction if there is no parallel wan enabled
Eric Shu created GEODE-10234: Summary: No need to generate tailKey for transaction if there is no parallel wan enabled Key: GEODE-10234 URL: https://issues.apache.org/jira/browse/GEODE-10234 Project: Geode Issue Type: Bug Components: transactions Reporter: Eric Shu There is no need to generate a tailKey, if there is no parallel wan enabled. However, currently every operation on a partitioned region would generate such key and will be ignored anyway. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10211) A retried operation does not set possible duplicate in the event if retried on an accessor
[ https://issues.apache.org/jira/browse/GEODE-10211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10211. -- Fix Version/s: 1.15.0 Resolution: Fixed > A retried operation does not set possible duplicate in the event if retried > on an accessor > -- > > Key: GEODE-10211 > URL: https://issues.apache.org/jira/browse/GEODE-10211 > Project: Geode > Issue Type: Bug > Components: persistence, regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > In geode, or persistent region, it is possible that all persistent copies > went offline. So possible duplicate should be set in the event, even though > no members has the event in the event tracker. > Currently, the code handling this will miss the setting if the retry occurs > on an accessor (localMaxMemory set to 0) case. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10211) A retried operation does not set possible duplicate in the event if retried on an accessor
[ https://issues.apache.org/jira/browse/GEODE-10211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10211: - Labels: GeodeOperationAPI blocks-1.15.0 (was: needsTriage) > A retried operation does not set possible duplicate in the event if retried > on an accessor > -- > > Key: GEODE-10211 > URL: https://issues.apache.org/jira/browse/GEODE-10211 > Project: Geode > Issue Type: Bug > Components: persistence, regions >Reporter: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > In geode, or persistent region, it is possible that all persistent copies > went offline. So possible duplicate should be set in the event, even though > no members has the event in the event tracker. > Currently, the code handling this will miss the setting if the retry occurs > on an accessor (localMaxMemory set to 0) case. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10211) A retried operation does not set possible duplicate in the event if retried on an accessor
[ https://issues.apache.org/jira/browse/GEODE-10211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10211: Assignee: Eric Shu > A retried operation does not set possible duplicate in the event if retried > on an accessor > -- > > Key: GEODE-10211 > URL: https://issues.apache.org/jira/browse/GEODE-10211 > Project: Geode > Issue Type: Bug > Components: persistence, regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > In geode, or persistent region, it is possible that all persistent copies > went offline. So possible duplicate should be set in the event, even though > no members has the event in the event tracker. > Currently, the code handling this will miss the setting if the retry occurs > on an accessor (localMaxMemory set to 0) case. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10211) A retried operation does not set possible duplicate in the event if retried on an accessor
Eric Shu created GEODE-10211: Summary: A retried operation does not set possible duplicate in the event if retried on an accessor Key: GEODE-10211 URL: https://issues.apache.org/jira/browse/GEODE-10211 Project: Geode Issue Type: Bug Components: persistence, regions Reporter: Eric Shu In geode, or persistent region, it is possible that all persistent copies went offline. So possible duplicate should be set in the event, even though no members has the event in the event tracker. Currently, the code handling this will miss the setting if the retry occurs on an accessor (localMaxMemory set to 0) case. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10199) A retried putIfAbsent operation may not be distributed to peer and its client
[
https://issues.apache.org/jira/browse/GEODE-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-10199.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> A retried putIfAbsent operation may not be distributed to peer and its client
> -
>
> Key: GEODE-10199
> URL: https://issues.apache.org/jira/browse/GEODE-10199
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> In creating bucket regions, region event state from the current bucket hosts
> was sent to the node creating the bucket, and later the node with newly
> created bucket will request GII from one of the current host. There is a race
> that gii can send an entry but does not have the corresponding event state in
> the provider when sending the state.
> If the node just created bucket received the retried putIfAbsent event, it
> will not find the event in its event tracker (has not seen the event), even
> though the entry exists in its cache, and it tries to find and set the
> version tag from other peers.
> Later, due to the following condition check, the event will not be processed
> after this check and will not be distributed to peers.
> {code:java}
> if (getOwner().getConcurrencyChecksEnabled() &&
> event.getOperation() == Operation.PUT_IF_ABSENT &&
> !event.hasValidVersionTag() &&
> event.isPossibleDuplicate()) {
> Object retainedValue = getRegionEntry().getValueRetain(getOwner());
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10162) A retried operation may sometimes not set valid tag
[ https://issues.apache.org/jira/browse/GEODE-10162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10162: - Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was: GeodeOperationAPI pull-request-available) > A retried operation may sometimes not set valid tag > --- > > Key: GEODE-10162 > URL: https://issues.apache.org/jira/browse/GEODE-10162 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > In geode, gii is performed when a bucket is created. However, version tags > are not sent to the gii receiver. In some cases, a retried event can come to > the server just created bucket. In this case, we still need to set the valid > version tag, so this operation can be distributed to other servers/peers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10199) A retried putIfAbsent operation may not be distributed to peer and its client
[
https://issues.apache.org/jira/browse/GEODE-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-10199:
-
Labels: GeodeOperationAPI blocks-1.15.0 (was: GeodeOperationAPI)
> A retried putIfAbsent operation may not be distributed to peer and its client
> -
>
> Key: GEODE-10199
> URL: https://issues.apache.org/jira/browse/GEODE-10199
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0
>
> In creating bucket regions, region event state from the current bucket hosts
> was sent to the node creating the bucket, and later the node with newly
> created bucket will request GII from one of the current host. There is a race
> that gii can send an entry but does not have the corresponding event state in
> the provider when sending the state.
> If the node just created bucket received the retried putIfAbsent event, it
> will not find the event in its event tracker (has not seen the event), even
> though the entry exists in its cache, and it tries to find and set the
> version tag from other peers.
> Later, due to the following condition check, the event will not be processed
> after this check and will not be distributed to peers.
> {code:java}
> if (getOwner().getConcurrencyChecksEnabled() &&
> event.getOperation() == Operation.PUT_IF_ABSENT &&
> !event.hasValidVersionTag() &&
> event.isPossibleDuplicate()) {
> Object retainedValue = getRegionEntry().getValueRetain(getOwner());
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10199) A retried putIfAbsent operation may not be distributed to peer and its client
[
https://issues.apache.org/jira/browse/GEODE-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-10199:
-
Labels: GeodeOperationAPI (was: needsTriage)
> A retried putIfAbsent operation may not be distributed to peer and its client
> -
>
> Key: GEODE-10199
> URL: https://issues.apache.org/jira/browse/GEODE-10199
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI
>
> In creating bucket regions, region event state from the current bucket hosts
> was sent to the node creating the bucket, and later the node with newly
> created bucket will request GII from one of the current host. There is a race
> that gii can send an entry but does not have the corresponding event state in
> the provider when sending the state.
> If the node just created bucket received the retried putIfAbsent event, it
> will not find the event in its event tracker (has not seen the event), even
> though the entry exists in its cache, and it tries to find and set the
> version tag from other peers.
> Later, due to the following condition check, the event will not be processed
> after this check and will not be distributed to peers.
> {code:java}
> if (getOwner().getConcurrencyChecksEnabled() &&
> event.getOperation() == Operation.PUT_IF_ABSENT &&
> !event.hasValidVersionTag() &&
> event.isPossibleDuplicate()) {
> Object retainedValue = getRegionEntry().getValueRetain(getOwner());
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10162) A retried operation may sometimes not set valid tag
[ https://issues.apache.org/jira/browse/GEODE-10162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10162. -- Fix Version/s: 1.15.0 Resolution: Fixed > A retried operation may sometimes not set valid tag > --- > > Key: GEODE-10162 > URL: https://issues.apache.org/jira/browse/GEODE-10162 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > In geode, gii is performed when a bucket is created. However, version tags > are not sent to the gii receiver. In some cases, a retried event can come to > the server just created bucket. In this case, we still need to set the valid > version tag, so this operation can be distributed to other servers/peers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10199) A retried putIfAbsent operation may not be distributed to peer and its client
[
https://issues.apache.org/jira/browse/GEODE-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reassigned GEODE-10199:
Assignee: Eric Shu
> A retried putIfAbsent operation may not be distributed to peer and its client
> -
>
> Key: GEODE-10199
> URL: https://issues.apache.org/jira/browse/GEODE-10199
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> In creating bucket regions, region event state from the current bucket hosts
> was sent to the node creating the bucket, and later the node with newly
> created bucket will request GII from one of the current host. There is a race
> that gii can send an entry but does not have the corresponding event state in
> the provider when sending the state.
> If the node just created bucket received the retried putIfAbsent event, it
> will not find the event in its event tracker (has not seen the event), even
> though the entry exists in its cache, and it tries to find and set the
> version tag from other peers.
> Later, due to the following condition check, the event will not be processed
> after this check and will not be distributed to peers.
> {code:java}
> if (getOwner().getConcurrencyChecksEnabled() &&
> event.getOperation() == Operation.PUT_IF_ABSENT &&
> !event.hasValidVersionTag() &&
> event.isPossibleDuplicate()) {
> Object retainedValue = getRegionEntry().getValueRetain(getOwner());
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10199) A retried putIfAbsent operation may not be distributed to peer and its client
Eric Shu created GEODE-10199:
Summary: A retried putIfAbsent operation may not be distributed to
peer and its client
Key: GEODE-10199
URL: https://issues.apache.org/jira/browse/GEODE-10199
Project: Geode
Issue Type: Bug
Components: regions
Reporter: Eric Shu
In creating bucket regions, region event state from the current bucket hosts
was sent to the node creating the bucket, and later the node with newly created
bucket will request GII from one of the current host. There is a race that gii
can send an entry but does not have the corresponding event state in the
provider when sending the state.
If the node just created bucket received the retried putIfAbsent event, it will
not find the event in its event tracker (has not seen the event), even though
the entry exists in its cache, and it tries to find and set the version tag
from other peers.
Later, due to the following condition check, the event will not be processed
after this check and will not be distributed to peers.
{code:java}
if (getOwner().getConcurrencyChecksEnabled() &&
event.getOperation() == Operation.PUT_IF_ABSENT &&
!event.hasValidVersionTag() &&
event.isPossibleDuplicate()) {
Object retainedValue = getRegionEntry().getValueRetain(getOwner());
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10182) A null check due to detecting read conflict is no longer necessary
[ https://issues.apache.org/jira/browse/GEODE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10182. -- Fix Version/s: 1.15.0 Resolution: Fixed > A null check due to detecting read conflict is no longer necessary > --- > > Key: GEODE-10182 > URL: https://issues.apache.org/jira/browse/GEODE-10182 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.12.2 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > The null check is introduced in fixing GEODE-6955, however, this check is no > long necessary after GEODE-8926 when transaction is applied to cache first > and handled it in attachFilterProfileInformation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10182) A null check due to detecting read conflict is no longer necessary
[ https://issues.apache.org/jira/browse/GEODE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10182: - Labels: GeodeOperationAPI (was: needsTriage) > A null check due to detecting read conflict is no longer necessary > --- > > Key: GEODE-10182 > URL: https://issues.apache.org/jira/browse/GEODE-10182 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.12.2 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > The null check is introduced in fixing GEODE-6955, however, this check is no > long necessary after GEODE-8926 when transaction is applied to cache first > and handled it in attachFilterProfileInformation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10182) A null check due to detecting read conflict is no longer necessary
[ https://issues.apache.org/jira/browse/GEODE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10182: - Affects Version/s: 1.12.2 > A null check due to detecting read conflict is no longer necessary > --- > > Key: GEODE-10182 > URL: https://issues.apache.org/jira/browse/GEODE-10182 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.12.2 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > The null check is introduced in fixing GEODE-6955, however, this check is no > long necessary after GEODE-8926 when transaction is applied to cache first > and handled it in attachFilterProfileInformation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10182) A null check due to detecting read conflict is no longer necessary
[ https://issues.apache.org/jira/browse/GEODE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10182: Assignee: Eric Shu > A null check due to detecting read conflict is no longer necessary > --- > > Key: GEODE-10182 > URL: https://issues.apache.org/jira/browse/GEODE-10182 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > The null check is introduced in fixing GEODE-6955, however, this check is no > long necessary after GEODE-8926 when transaction is applied to cache first > and handled it in attachFilterProfileInformation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10182) A null check due to detecting read conflict is no longer necessary
Eric Shu created GEODE-10182: Summary: A null check due to detecting read conflict is no longer necessary Key: GEODE-10182 URL: https://issues.apache.org/jira/browse/GEODE-10182 Project: Geode Issue Type: Bug Components: transactions Reporter: Eric Shu The null check is introduced in fixing GEODE-6955, however, this check is no long necessary after GEODE-8926 when transaction is applied to cache first and handled it in attachFilterProfileInformation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10162) A retried operation may sometimes not set valid tag
[ https://issues.apache.org/jira/browse/GEODE-10162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10162: - Labels: GeodeOperationAPI (was: needsTriage) > A retried operation may sometimes not set valid tag > --- > > Key: GEODE-10162 > URL: https://issues.apache.org/jira/browse/GEODE-10162 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > In geode, gii is performed when a bucket is created. However, version tags > are not sent to the gii receiver. In some cases, a retried event can come to > the server just created bucket. In this case, we still need to set the valid > version tag, so this operation can be distributed to other servers/peers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10162) A retried operation may sometimes not set valid tag
[ https://issues.apache.org/jira/browse/GEODE-10162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10162: Assignee: Eric Shu > A retried operation may sometimes not set valid tag > --- > > Key: GEODE-10162 > URL: https://issues.apache.org/jira/browse/GEODE-10162 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > In geode, gii is performed when a bucket is created. However, version tags > are not sent to the gii receiver. In some cases, a retried event can come to > the server just created bucket. In this case, we still need to set the valid > version tag, so this operation can be distributed to other servers/peers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10162) A retried operation may sometimes not set valid tag
Eric Shu created GEODE-10162: Summary: A retried operation may sometimes not set valid tag Key: GEODE-10162 URL: https://issues.apache.org/jira/browse/GEODE-10162 Project: Geode Issue Type: Bug Components: regions Reporter: Eric Shu In geode, gii is performed when a bucket is created. However, version tags are not sent to the gii receiver. In some cases, a retried event can come to the server just created bucket. In this case, we still need to set the valid version tag, so this operation can be distributed to other servers/peers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10156) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED
Eric Shu created GEODE-10156: Summary: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED Key: GEODE-10156 URL: https://issues.apache.org/jira/browse/GEODE-10156 Project: Geode Issue Type: Bug Components: tests Reporter: Eric Shu org.opentest4j.AssertionFailedError: [Exit value from process started by [4f44cb7de3b710f1: gfsh -e start locator --name=loc1 --port=20846 --http-service-port=0 --J=-Dgemfire.jmx-manager-port=20847 -e start locator --name=loc2 --port=20848 --http-service-port=0 --locators=localhost[20846] --J=-Dgemfire.jmx-manager-port=20849 -e start server --name=server1 --server-port=20850 --locators=localhost[20846] -e start server --name=server2 --server-port=20851 --locators=localhost[20846] -e deploy --dir=/tmp/junit4947263696282150978/junit6257623670577599443]] expected: 0 but was: 1 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) at org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153) at org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) 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.rules.ExternalResource$1.evaluate(ExternalResource.java:54) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) 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.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) 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
[jira] [Updated] (GEODE-10130) cq destroy event in replicate region can be missing
[ https://issues.apache.org/jira/browse/GEODE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10130: - Affects Version/s: 1.14.0 (was: 1.15.0) (was: 1.14.4) > cq destroy event in replicate region can be missing > > > Key: GEODE-10130 > URL: https://issues.apache.org/jira/browse/GEODE-10130 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.0, 1.13.0, 1.14.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > In geode, cq event for replicated region are cached so that when destroy > event comes in, we can just use cached value to determine if a client need > the cq event (instead of evaluate the query again for performance). > However, there is a synchronization issue in > ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find > the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10130) cq destroy event in replicate region can be missing
[ https://issues.apache.org/jira/browse/GEODE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10130. -- Fix Version/s: 1.15.0 Resolution: Fixed > cq destroy event in replicate region can be missing > > > Key: GEODE-10130 > URL: https://issues.apache.org/jira/browse/GEODE-10130 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.0, 1.13.0, 1.14.4, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > In geode, cq event for replicated region are cached so that when destroy > event comes in, we can just use cached value to determine if a client need > the cq event (instead of evaluate the query again for performance). > However, there is a synchronization issue in > ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find > the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10132) org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest Failed
[ https://issues.apache.org/jira/browse/GEODE-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508364#comment-17508364 ] Eric Shu commented on GEODE-10132: -- GEODE-5603 was closed as duplicate of https://issues.apache.org/jira/browse/GEODE-5601 (AcceptanceTests are run in parallel without using containers, resulting in port conflicts) which has been addressed already -- so open a new ticket. > org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest > Failed > - > > Key: GEODE-10132 > URL: https://issues.apache.org/jira/browse/GEODE-10132 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > cannotStopServerByNameWhenNotConnected > org.opentest4j.AssertionFailedError: [Exit value from process started by > [fcdfe561432081bf: gfsh -e start locator --name=locator -e start server > --name=server --server-port=0]] > expected: 0 > but was: 1 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:129) > at > org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:32) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > 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.RunBefores.invokeMethod(RunBefores.java:33) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > 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.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
[jira] [Created] (GEODE-10132) org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest Failed
Eric Shu created GEODE-10132: Summary: org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest Failed Key: GEODE-10132 URL: https://issues.apache.org/jira/browse/GEODE-10132 Project: Geode Issue Type: Bug Components: tests Reporter: Eric Shu cannotStopServerByNameWhenNotConnected org.opentest4j.AssertionFailedError: [Exit value from process started by [fcdfe561432081bf: gfsh -e start locator --name=locator -e start server --name=server --server-port=0]] expected: 0 but was: 1 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:129) at org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:32) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) 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.RunBefores.invokeMethod(RunBefores.java:33) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) 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.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
[jira] [Updated] (GEODE-10130) cq destroy event in replicate region can be missing
[ https://issues.apache.org/jira/browse/GEODE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10130: - Labels: GeodeOperationAPI (was: needsTriage) > cq destroy event in replicate region can be missing > > > Key: GEODE-10130 > URL: https://issues.apache.org/jira/browse/GEODE-10130 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.0, 1.13.0, 1.14.4, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > In geode, cq event for replicated region are cached so that when destroy > event comes in, we can just use cached value to determine if a client need > the cq event (instead of evaluate the query again for performance). > However, there is a synchronization issue in > ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find > the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10130) cq destroy event in replicate region can be missing
[ https://issues.apache.org/jira/browse/GEODE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10130: Assignee: Eric Shu > cq destroy event in replicate region can be missing > > > Key: GEODE-10130 > URL: https://issues.apache.org/jira/browse/GEODE-10130 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.0, 1.13.0, 1.14.4, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > In geode, cq event for replicated region are cached so that when destroy > event comes in, we can just use cached value to determine if a client need > the cq event (instead of evaluate the query again for performance). > However, there is a synchronization issue in > ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find > the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10130) cq destroy event in replicate region can be missing
Eric Shu created GEODE-10130: Summary: cq destroy event in replicate region can be missing Key: GEODE-10130 URL: https://issues.apache.org/jira/browse/GEODE-10130 Project: Geode Issue Type: Bug Components: cq Affects Versions: 1.13.0, 1.12.0, 1.14.4, 1.15.0 Reporter: Eric Shu In geode, cq event for replicated region are cached so that when destroy event comes in, we can just use cached value to determine if a client need the cq event (instead of evaluate the query again for performance). However, there is a synchronization issue in ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10114) NullPointerException is logged if create index when cache is closing.
[ https://issues.apache.org/jira/browse/GEODE-10114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10114. -- Fix Version/s: 1.16.0 Resolution: Fixed > NullPointerException is logged if create index when cache is closing. > - > > Key: GEODE-10114 > URL: https://issues.apache.org/jira/browse/GEODE-10114 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.16.0 > > > The following NPE is logged when creating index if cache is closing at the > same time. > [info 2020/02/19 02:28:46.140 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index idRangeEntryIndex on > region /__PR/_B__QueryRegion0_46 with exception: > java.lang.NullPointerException > [info 2020/02/19 02:28:46.198 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index > statusCompactRangeEntryIndex on region /__PR/_B__QueryRegion0_46 with > exception: java.lang.NullPointerException -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10114) NullPointerException is logged if create index when cache is closing.
[ https://issues.apache.org/jira/browse/GEODE-10114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10114: - Labels: GeodeOperationAPI (was: needsTriage) > NullPointerException is logged if create index when cache is closing. > - > > Key: GEODE-10114 > URL: https://issues.apache.org/jira/browse/GEODE-10114 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > The following NPE is logged when creating index if cache is closing at the > same time. > [info 2020/02/19 02:28:46.140 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index idRangeEntryIndex on > region /__PR/_B__QueryRegion0_46 with exception: > java.lang.NullPointerException > [info 2020/02/19 02:28:46.198 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index > statusCompactRangeEntryIndex on region /__PR/_B__QueryRegion0_46 with > exception: java.lang.NullPointerException -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10114) NullPointerException is logged if create index when cache is closing.
Eric Shu created GEODE-10114: Summary: NullPointerException is logged if create index when cache is closing. Key: GEODE-10114 URL: https://issues.apache.org/jira/browse/GEODE-10114 Project: Geode Issue Type: Bug Components: querying Affects Versions: 1.14.0, 1.13.0, 1.12.0, 1.15.0 Reporter: Eric Shu The following NPE is logged when creating index if cache is closing at the same time. [info 2020/02/19 02:28:46.140 PST bridgegemfire3_host1_29240 tid=0x2e] Failed to create index idRangeEntryIndex on region /__PR/_B__QueryRegion0_46 with exception: java.lang.NullPointerException [info 2020/02/19 02:28:46.198 PST bridgegemfire3_host1_29240 tid=0x2e] Failed to create index statusCompactRangeEntryIndex on region /__PR/_B__QueryRegion0_46 with exception: java.lang.NullPointerException -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10114) NullPointerException is logged if create index when cache is closing.
[ https://issues.apache.org/jira/browse/GEODE-10114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10114: Assignee: Eric Shu > NullPointerException is logged if create index when cache is closing. > - > > Key: GEODE-10114 > URL: https://issues.apache.org/jira/browse/GEODE-10114 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > The following NPE is logged when creating index if cache is closing at the > same time. > [info 2020/02/19 02:28:46.140 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index idRangeEntryIndex on > region /__PR/_B__QueryRegion0_46 with exception: > java.lang.NullPointerException > [info 2020/02/19 02:28:46.198 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index > statusCompactRangeEntryIndex on region /__PR/_B__QueryRegion0_46 with > exception: java.lang.NullPointerException -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10110. -- Fix Version/s: 1.16.0 Resolution: Fixed > When creating index in geode, InternalGemFireException should not be thrown > to user if hitting CacheClosedException > --- > > Key: GEODE-10110 > URL: https://issues.apache.org/jira/browse/GEODE-10110 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.16.0 > > > Here is the exception thrown to the user: > org.apache.geode.InternalGemFireException: unexpected exception on member > rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) > Caused by: Creation of index: statusIndex failed due to: > org.apache.geode.cache.CacheClosedException: The cache is closed. > at > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10110: Assignee: Eric Shu > When creating index in geode, InternalGemFireException should not be thrown > to user if hitting CacheClosedException > --- > > Key: GEODE-10110 > URL: https://issues.apache.org/jira/browse/GEODE-10110 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > Here is the exception thrown to the user: > org.apache.geode.InternalGemFireException: unexpected exception on member > rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) > Caused by: Creation of index: statusIndex failed due to: > org.apache.geode.cache.CacheClosedException: The cache is closed. > at > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10110: - Description: Here is the exception thrown to the user: org.apache.geode.InternalGemFireException: unexpected exception on member rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 at org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) at org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) Caused by: Creation of index: statusIndex failed due to: org.apache.geode.cache.CacheClosedException: The cache is closed. at org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) at org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) at org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at java.lang.Thread.run(Thread.java:748) was: org.apache.geode.InternalGemFireException: unexpected exception on member rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 at org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) at org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) Caused by: Creation of index: statusIndex failed due to: org.apache.geode.cache.CacheClosedException: The cache is closed. at org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) at
[jira] [Updated] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10110: - Labels: GeodeOperationAPI (was: needsTriage) > When creating index in geode, InternalGemFireException should not be thrown > to user if hitting CacheClosedException > --- > > Key: GEODE-10110 > URL: https://issues.apache.org/jira/browse/GEODE-10110 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > Here is the exception thrown to the user: > org.apache.geode.InternalGemFireException: unexpected exception on member > rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) > Caused by: Creation of index: statusIndex failed due to: > org.apache.geode.cache.CacheClosedException: The cache is closed. > at > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
Eric Shu created GEODE-10110: Summary: When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException Key: GEODE-10110 URL: https://issues.apache.org/jira/browse/GEODE-10110 Project: Geode Issue Type: Bug Components: querying Affects Versions: 1.14.0, 1.13.0, 1.12.0, 1.15.0 Reporter: Eric Shu org.apache.geode.InternalGemFireException: unexpected exception on member rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 at org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) at org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) Caused by: Creation of index: statusIndex failed due to: org.apache.geode.cache.CacheClosedException: The cache is closed. at org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) at org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) at org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10094. -- Fix Version/s: 1.16.0 Resolution: Fixed > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.16.0 > > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10094: - Labels: GeodeOperationAPI (was: needsTriage) > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10094: Assignee: Eric Shu > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
Eric Shu created GEODE-10094: Summary: NPE could be encountered when accessing index manager if cache is closing Key: GEODE-10094 URL: https://issues.apache.org/jira/browse/GEODE-10094 Project: Geode Issue Type: Bug Components: querying Reporter: Eric Shu The following NPE can be seen when creating index on a partitioned region. java.lang.NullPointerException at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in java.lang.Thread.run(Thread.java:750) at org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) at org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10063) A closed/destroyed connection can be set as a primary queueConnection in QueueManager
[ https://issues.apache.org/jira/browse/GEODE-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10063. -- Fix Version/s: 1.15.0 1.16.0 Resolution: Fixed > A closed/destroyed connection can be set as a primary queueConnection in > QueueManager > - > > Key: GEODE-10063 > URL: https://issues.apache.org/jira/browse/GEODE-10063 > Project: Geode > Issue Type: Bug > Components: client queues, security >Affects Versions: 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > In certain race cases, a destroyed connection is set to be the primary queue > connection connected to servers. If re-auth is enabled, and server pauses the > primary queue waiting for the re-auth token, there will be no client to > server connection available to send the valid re-auth token for server to > unpause the queue. And the said client can not receive any events afterwards. > The situation should be detected during RedundancySatisfierTask, but it could > not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10063) A closed/destroyed connection can be set as a primary queueConnection in QueueManager
[ https://issues.apache.org/jira/browse/GEODE-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10063: - Labels: GeodeOperationAPI blocks-1.15.0 (was: blocks-1.15.0) > A closed/destroyed connection can be set as a primary queueConnection in > QueueManager > - > > Key: GEODE-10063 > URL: https://issues.apache.org/jira/browse/GEODE-10063 > Project: Geode > Issue Type: Bug > Components: client queues, security >Affects Versions: 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > In certain race cases, a destroyed connection is set to be the primary queue > connection connected to servers. If re-auth is enabled, and server pauses the > primary queue waiting for the re-auth token, there will be no client to > server connection available to send the valid re-auth token for server to > unpause the queue. And the said client can not receive any events afterwards. > The situation should be detected during RedundancySatisfierTask, but it could > not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10063) A closed/destroyed connection can be set as a primary queueConnection in QueueManager
[ https://issues.apache.org/jira/browse/GEODE-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10063: - Description: In certain race cases, a destroyed connection is set to be the primary queue connection connected to servers. If re-auth is enabled, and server pauses the primary queue waiting for the re-auth token, there will be no client to server connection available to send the valid re-auth token for server to unpause the queue. And the said client can not receive any events afterwards. The situation should be detected during RedundancySatisfierTask, but it could not. was: In certain race cases, a destroyed connection is set to be the primary queue connection connected to servers. If re-auth is enabled, and server pauses the primary queue waiting for the re-auth token, there will be no client to server connection available to send the valid re-auth token for server to unpause the queue. And said client can not receive any events. The situation should be detected during RedundancySatisfierTask, but it could not. > A closed/destroyed connection can be set as a primary queueConnection in > QueueManager > - > > Key: GEODE-10063 > URL: https://issues.apache.org/jira/browse/GEODE-10063 > Project: Geode > Issue Type: Bug > Components: client queues, security >Affects Versions: 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0 > > In certain race cases, a destroyed connection is set to be the primary queue > connection connected to servers. If re-auth is enabled, and server pauses the > primary queue waiting for the re-auth token, there will be no client to > server connection available to send the valid re-auth token for server to > unpause the queue. And the said client can not receive any events afterwards. > The situation should be detected during RedundancySatisfierTask, but it could > not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10063) A closed/destroyed connection can be set as a primary queueConnection in QueueManager
[ https://issues.apache.org/jira/browse/GEODE-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10063: - Labels: blocks-1.15.0 (was: needsTriage) > A closed/destroyed connection can be set as a primary queueConnection in > QueueManager > - > > Key: GEODE-10063 > URL: https://issues.apache.org/jira/browse/GEODE-10063 > Project: Geode > Issue Type: Bug > Components: client queues, security >Affects Versions: 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0 > > In certain race cases, a destroyed connection is set to be the primary queue > connection connected to servers. If re-auth is enabled, and server pauses the > primary queue waiting for the re-auth token, there will be no client to > server connection available to send the valid re-auth token for server to > unpause the queue. And said client can not receive any events. > The situation should be detected during RedundancySatisfierTask, but it could > not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10063) A closed/destroyed connection can be set as a primary queueConnection in QueueManager
[ https://issues.apache.org/jira/browse/GEODE-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10063: Assignee: Eric Shu > A closed/destroyed connection can be set as a primary queueConnection in > QueueManager > - > > Key: GEODE-10063 > URL: https://issues.apache.org/jira/browse/GEODE-10063 > Project: Geode > Issue Type: Bug > Components: client queues, security >Affects Versions: 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > In certain race cases, a destroyed connection is set to be the primary queue > connection connected to servers. If re-auth is enabled, and server pauses the > primary queue waiting for the re-auth token, there will be no client to > server connection available to send the valid re-auth token for server to > unpause the queue. And said client can not receive any events. > The situation should be detected during RedundancySatisfierTask, but it could > not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10063) A closed/destroyed connection can be set as a primary queueConnection in QueueManager
Eric Shu created GEODE-10063: Summary: A closed/destroyed connection can be set as a primary queueConnection in QueueManager Key: GEODE-10063 URL: https://issues.apache.org/jira/browse/GEODE-10063 Project: Geode Issue Type: Bug Components: client queues Affects Versions: 1.15.0 Reporter: Eric Shu In certain race cases, a destroyed connection is set to be the primary queue connection connected to servers. If re-auth is enabled, and server pauses the primary queue waiting for the re-auth token, there will be no client to server connection available to send the valid re-auth token for server to unpause the queue. And said client can not receive any events. The situation should be detected during RedundancySatisfierTask, but it could not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10063) A closed/destroyed connection can be set as a primary queueConnection in QueueManager
[ https://issues.apache.org/jira/browse/GEODE-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10063: - Component/s: security > A closed/destroyed connection can be set as a primary queueConnection in > QueueManager > - > > Key: GEODE-10063 > URL: https://issues.apache.org/jira/browse/GEODE-10063 > Project: Geode > Issue Type: Bug > Components: client queues, security >Affects Versions: 1.15.0 >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > In certain race cases, a destroyed connection is set to be the primary queue > connection connected to servers. If re-auth is enabled, and server pauses the > primary queue waiting for the re-auth token, there will be no client to > server connection available to send the valid re-auth token for server to > unpause the queue. And said client can not receive any events. > The situation should be detected during RedundancySatisfierTask, but it could > not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket
[
https://issues.apache.org/jira/browse/GEODE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-9990:
Affects Version/s: 1.15.0
> Geode should handle certain DiskAccessException due to CacheClosedException
> when creating bucket
>
>
> Key: GEODE-9990
> URL: https://issues.apache.org/jira/browse/GEODE-9990
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> This exception is thrown to the node that tries to create the bucket to
> prevent it trying to create the bucket to next available server and fail the
> entry operation.
> {noformat}
> org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The
> disk store is closed
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
>
[jira] [Created] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket
Eric Shu created GEODE-9990:
---
Summary: Geode should handle certain DiskAccessException due to
CacheClosedException when creating bucket
Key: GEODE-9990
URL: https://issues.apache.org/jira/browse/GEODE-9990
Project: Geode
Issue Type: Bug
Components: persistence
Reporter: Eric Shu
This exception is thrown to the node that tries to create the bucket to prevent
it trying to create the bucket to next available server and fail the entry
operation.
{noformat}
org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The disk
store is closed
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:413)
at Remote Member
'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
in
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
[jira] [Resolved] (GEODE-9944) NPE could occur if HARegion is being created again but not fully initialized
[
https://issues.apache.org/jira/browse/GEODE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-9944.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> NPE could occur if HARegion is being created again but not fully initialized
> -
>
> Key: GEODE-9944
> URL: https://issues.apache.org/jira/browse/GEODE-9944
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> The stack trace for the NPE is:
> {noformat}
> fatal 2022/01/08 12:45:33.175 PST bridgegemfire7_host1_25026 Processor 7> tid=0x148] Uncaught exception processing
> QueueSynchronizationProcessor$QueueSynchronizationMessage@340d586b
> processorId=4029
> sender=rs-FullRegression15142100a3i3large-hydra-client-18(bridgegemfire6_host1_25009:25009):41006
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.getDispatchedEvents(QueueSynchronizationProcessor.java:160)
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.process(QueueSynchronizationProcessor.java:127)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:391)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This could occur when a client is not able to re-auth in time, and the server
> removes the HARegionQueue to the client. When the client is able to re-auth
> later, the new HARegionQueue is created again. There is a race that when the
> server process the above message, the HARegionQueue is not fully initialized
> and cause this NPE.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9944) NPE could occur if HARegion is being created again but not fully initialized
[
https://issues.apache.org/jira/browse/GEODE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-9944:
Labels: GeodeOperationAPI needsTriage (was: needsTriage)
> NPE could occur if HARegion is being created again but not fully initialized
> -
>
> Key: GEODE-9944
> URL: https://issues.apache.org/jira/browse/GEODE-9944
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> The stack trace for the NPE is:
> {noformat}
> fatal 2022/01/08 12:45:33.175 PST bridgegemfire7_host1_25026 Processor 7> tid=0x148] Uncaught exception processing
> QueueSynchronizationProcessor$QueueSynchronizationMessage@340d586b
> processorId=4029
> sender=rs-FullRegression15142100a3i3large-hydra-client-18(bridgegemfire6_host1_25009:25009):41006
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.getDispatchedEvents(QueueSynchronizationProcessor.java:160)
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.process(QueueSynchronizationProcessor.java:127)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:391)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This could occur when a client is not able to re-auth in time, and the server
> removes the HARegionQueue to the client. When the client is able to re-auth
> later, the new HARegionQueue is created again. There is a race that when the
> server process the above message, the HARegionQueue is not fully initialized
> and cause this NPE.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9944) NPE could occur if HARegion is being created again but not fully initialized
[
https://issues.apache.org/jira/browse/GEODE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu reassigned GEODE-9944:
---
Assignee: Eric Shu
> NPE could occur if HARegion is being created again but not fully initialized
> -
>
> Key: GEODE-9944
> URL: https://issues.apache.org/jira/browse/GEODE-9944
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> The stack trace for the NPE is:
> {noformat}
> fatal 2022/01/08 12:45:33.175 PST bridgegemfire7_host1_25026 Processor 7> tid=0x148] Uncaught exception processing
> QueueSynchronizationProcessor$QueueSynchronizationMessage@340d586b
> processorId=4029
> sender=rs-FullRegression15142100a3i3large-hydra-client-18(bridgegemfire6_host1_25009:25009):41006
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.getDispatchedEvents(QueueSynchronizationProcessor.java:160)
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.process(QueueSynchronizationProcessor.java:127)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:391)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This could occur when a client is not able to re-auth in time, and the server
> removes the HARegionQueue to the client. When the client is able to re-auth
> later, the new HARegionQueue is created again. There is a race that when the
> server process the above message, the HARegionQueue is not fully initialized
> and cause this NPE.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9944) NPE could occur if HARegion is being created again but not fully initialized
[
https://issues.apache.org/jira/browse/GEODE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-9944:
Affects Version/s: 1.15.0
> NPE could occur if HARegion is being created again but not fully initialized
> -
>
> Key: GEODE-9944
> URL: https://issues.apache.org/jira/browse/GEODE-9944
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> The stack trace for the NPE is:
> {noformat}
> fatal 2022/01/08 12:45:33.175 PST bridgegemfire7_host1_25026 Processor 7> tid=0x148] Uncaught exception processing
> QueueSynchronizationProcessor$QueueSynchronizationMessage@340d586b
> processorId=4029
> sender=rs-FullRegression15142100a3i3large-hydra-client-18(bridgegemfire6_host1_25009:25009):41006
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.getDispatchedEvents(QueueSynchronizationProcessor.java:160)
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.process(QueueSynchronizationProcessor.java:127)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:391)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This could occur when a client is not able to re-auth in time, and the server
> removes the HARegionQueue to the client. When the client is able to re-auth
> later, the new HARegionQueue is created again. There is a race that when the
> server process the above message, the HARegionQueue is not fully initialized
> and cause this NPE.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9944) NPE could occur if HARegion is being created again but not fully initialized
Eric Shu created GEODE-9944:
---
Summary: NPE could occur if HARegion is being created again but
not fully initialized
Key: GEODE-9944
URL: https://issues.apache.org/jira/browse/GEODE-9944
Project: Geode
Issue Type: Bug
Components: client queues
Reporter: Eric Shu
The stack trace for the NPE is:
{noformat}
fatal 2022/01/08 12:45:33.175 PST bridgegemfire7_host1_25026 tid=0x148] Uncaught exception processing
QueueSynchronizationProcessor$QueueSynchronizationMessage@340d586b
processorId=4029
sender=rs-FullRegression15142100a3i3large-hydra-client-18(bridgegemfire6_host1_25009:25009):41006
java.lang.NullPointerException
at
org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.getDispatchedEvents(QueueSynchronizationProcessor.java:160)
at
org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.process(QueueSynchronizationProcessor.java:127)
at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
at
org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:391)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
This could occur when a client is not able to re-auth in time, and the server
removes the HARegionQueue to the client. When the client is able to re-auth
later, the new HARegionQueue is created again. There is a race that when the
server process the above message, the HARegionQueue is not fully initialized
and cause this NPE.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9918) Distributed transaction is not a supported feature in geode
Eric Shu created GEODE-9918: --- Summary: Distributed transaction is not a supported feature in geode Key: GEODE-9918 URL: https://issues.apache.org/jira/browse/GEODE-9918 Project: Geode Issue Type: Bug Components: transactions Reporter: Eric Shu Geode should throw UnsupportedOperationException when CacheTransactionManager.setDistributed(true) is invoked. As the feature is currently not supported. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9918) Distributed transaction is not a supported feature in geode
[ https://issues.apache.org/jira/browse/GEODE-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-9918: Labels: GeodeOperationAPI (was: ) > Distributed transaction is not a supported feature in geode > --- > > Key: GEODE-9918 > URL: https://issues.apache.org/jira/browse/GEODE-9918 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > Geode should throw UnsupportedOperationException when > CacheTransactionManager.setDistributed(true) is invoked. As the feature is > currently not supported. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails FAILED
Eric Shu created GEODE-9785:
---
Summary: CI Failure:
RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails FAILED
Key: GEODE-9785
URL: https://issues.apache.org/jira/browse/GEODE-9785
Project: Geode
Issue Type: Bug
Components: regions
Reporter: Eric Shu
{noformat}
org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
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 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
at
[jira] [Created] (GEODE-9729) CI Failure: PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED
Eric Shu created GEODE-9729: --- Summary: CI Failure: PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED Key: GEODE-9729 URL: https://issues.apache.org/jira/browse/GEODE-9729 Project: Geode Issue Type: Bug Components: client/server Reporter: Eric Shu org.apache.geode.cache.client.AllConnectionsInUseException at org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:304) at org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:137) at org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120) at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805) at org.apache.geode.cache.client.internal.GetClientPRMetaDataOp.execute(GetClientPRMetaDataOp.java:53) at org.apache.geode.cache.client.internal.ClientMetadataService.getClientPRMetadata(ClientMetadataService.java:574) at org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testClientMetadataForPersistentPrs$26(PartitionedRegionSingleHopDUnitTest.java:972) at org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:234) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:221) at java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9724) CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED
Eric Shu created GEODE-9724: --- Summary: CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED Key: GEODE-9724 URL: https://issues.apache.org/jira/browse/GEODE-9724 Project: Geode Issue Type: Bug Reporter: Eric Shu org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$1.run in VM 2 running on Host 05a785bb07ad 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.rollingupgrade.RollingUpgradeDUnitTest.rollLocatorToCurrent(RollingUpgradeDUnitTest.java:370) at org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206) at org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable(RollingUpgradeRollServersOnReplicatedRegion_dataserializable.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) 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.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) 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.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) 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.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at
[jira] [Resolved] (GEODE-9640) When cluster shut down completely and restarted, new operations may be lost on client
[ https://issues.apache.org/jira/browse/GEODE-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-9640. - Fix Version/s: 1.15.0 1.14.1 1.13.5 1.12.5 Resolution: Fixed > When cluster shut down completely and restarted, new operations may be lost > on client > - > > Key: GEODE-9640 > URL: https://issues.apache.org/jira/browse/GEODE-9640 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > Fix For: 1.12.5, 1.13.5, 1.14.1, 1.15.0 > > > In Geode, client keeps track of events received based on EventID. If > duplicate events received from server, they are thrown away. > The current EventID takes parts of membership ID information, and it seems > not adequate enough if whole cluster is down. (The coordinator is down and > member viewId will start from 0 again.) This can lead to same event ids are > generated, and cause client miss CQ events, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
