[jira] [Resolved] (GEODE-9937) Add convenience methods to FileWatchingX509Extended*Manager
[ https://issues.apache.org/jira/browse/GEODE-9937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9937. --- Fix Version/s: 1.15.0 Resolution: Fixed > Add convenience methods to FileWatchingX509Extended*Manager > --- > > Key: GEODE-9937 > URL: https://issues.apache.org/jira/browse/GEODE-9937 > Project: Geode > Issue Type: Improvement > Components: security >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10284) Add partition-listener option to gfsh create region command
[
https://issues.apache.org/jira/browse/GEODE-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-10284.
Fix Version/s: 1.15.0
1.16.0
Resolution: Fixed
> Add partition-listener option to gfsh create region command
> ---
>
> Key: GEODE-10284
> URL: https://issues.apache.org/jira/browse/GEODE-10284
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> This adds a {{--partition-listener}} option to the {{create region}} gfsh
> command. I'm not sure why this was not added in the first place since all the
> plumbing to support it already seems to exist.
--
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] [Updated] (GEODE-10302) Increase upgrade test timeouts
[ https://issues.apache.org/jira/browse/GEODE-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-10302: --- Fix Version/s: 1.15.0 1.16.0 > Increase upgrade test timeouts > -- > > Key: GEODE-10302 > URL: https://issues.apache.org/jira/browse/GEODE-10302 > Project: Geode > Issue Type: Improvement > Components: ci >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Upgrade test durations are approaching the 3h limit set by CI. > An imminent PR changes most upgrade tests to increase the number of > configurations to upgrade from. These changes push the `upgradeTest` task > over the 3h limit. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10302) Increase upgrade test timeouts
[ https://issues.apache.org/jira/browse/GEODE-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-10302. Resolution: Fixed > Increase upgrade test timeouts > -- > > Key: GEODE-10302 > URL: https://issues.apache.org/jira/browse/GEODE-10302 > Project: Geode > Issue Type: Improvement > Components: ci >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Upgrade test durations are approaching the 3h limit set by CI. > An imminent PR changes most upgrade tests to increase the number of > configurations to upgrade from. These changes push the `upgradeTest` task > over the 3h limit. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10288) Identify multiple JDK versions for upgrade tests
[ https://issues.apache.org/jira/browse/GEODE-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery reassigned GEODE-10288: -- Assignee: Dale Emery > Identify multiple JDK versions for upgrade tests > > > Key: GEODE-10288 > URL: https://issues.apache.org/jira/browse/GEODE-10288 > Project: Geode > Issue Type: Improvement > Components: ci, tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > An upcoming PR enhances most upgrade tests to upgrade a Geode client, > locator, or server from one JDK version to another. That functionality > requires CI to define environment variables to identify the installed paths > to JDKs for Java 8, 11, and 17 when launching each test JVM. The proposed > environment variables are: > - TEST_JAVA_8_HOME > - TEST_JAVA_11_HOME > - TEST_JAVA_17_HOME -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10288) Identify multiple JDK versions for upgrade tests
[ https://issues.apache.org/jira/browse/GEODE-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-10288: --- Fix Version/s: 1.15.0 > Identify multiple JDK versions for upgrade tests > > > Key: GEODE-10288 > URL: https://issues.apache.org/jira/browse/GEODE-10288 > Project: Geode > Issue Type: Improvement > Components: ci, tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > An upcoming PR enhances most upgrade tests to upgrade a Geode client, > locator, or server from one JDK version to another. That functionality > requires CI to define environment variables to identify the installed paths > to JDKs for Java 8, 11, and 17 when launching each test JVM. The proposed > environment variables are: > - TEST_JAVA_8_HOME > - TEST_JAVA_11_HOME > - TEST_JAVA_17_HOME -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10289) Add an argument file that opens all JDK packages to all unnamed modules
[
https://issues.apache.org/jira/browse/GEODE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10289:
---
Fix Version/s: 1.15.0
> Add an argument file that opens all JDK packages to all unnamed modules
> ---
>
> Key: GEODE-10289
> URL: https://issues.apache.org/jira/browse/GEODE-10289
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Certain Geode functionality requires user-defined objects to be accessible
> for reflection. It can be difficult for users to identify non-opened JDK
> packages that are included in their objects.
> Add an argument file that opens all JDK packages to all unnamed modules.
> Adding this argument file when launching a client, locator, or server on JDK
> 17 essentially mimics the {{--illegal-access=permit}} option from JDK 11 (at
> least for JDK packages).
> The supplied argument file will open all packages that come with the Linux
> version of OpenJDK.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10302) Increase upgrade test timeouts
[ https://issues.apache.org/jira/browse/GEODE-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536936#comment-17536936 ] ASF subversion and git services commented on GEODE-10302: - Commit 6851ebedb3dd2fb98a9b6ec3a1f4a742c5360f69 in geode's branch refs/heads/support/1.15 from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6851ebedb3 ] backport/geode 10302/upgrade test timeouts (#7695) * GEODE-10302: Increase upgrade test timeout to 4h (#7683) * GEODE-10302: Increase call stack timeout for upgrade tests (#7691) To be 3h45m, 15 minutes shy of the newly increased task timeout. > Increase upgrade test timeouts > -- > > Key: GEODE-10302 > URL: https://issues.apache.org/jira/browse/GEODE-10302 > Project: Geode > Issue Type: Improvement > Components: ci >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > > Upgrade test durations are approaching the 3h limit set by CI. > An imminent PR changes most upgrade tests to increase the number of > configurations to upgrade from. These changes push the `upgradeTest` task > over the 3h limit. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10288) Identify multiple JDK versions for upgrade tests
[ https://issues.apache.org/jira/browse/GEODE-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536935#comment-17536935 ] ASF subversion and git services commented on GEODE-10288: - Commit ff3c806e1960f6abeb2be6982e01c713e03d97f1 in geode's branch refs/heads/support/1.15 from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ff3c806e19 ] backport/geode 10288/java homes (#7694) * GEODE-10288: Define JDK 8, 11, 17 homes for upgrade tests (#7675) * GEODE-10288: Fix property assignment syntax (#7678) > Identify multiple JDK versions for upgrade tests > > > Key: GEODE-10288 > URL: https://issues.apache.org/jira/browse/GEODE-10288 > Project: Geode > Issue Type: Improvement > Components: ci, tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.16.0 > > > An upcoming PR enhances most upgrade tests to upgrade a Geode client, > locator, or server from one JDK version to another. That functionality > requires CI to define environment variables to identify the installed paths > to JDKs for Java 8, 11, and 17 when launching each test JVM. The proposed > environment variables are: > - TEST_JAVA_8_HOME > - TEST_JAVA_11_HOME > - TEST_JAVA_17_HOME -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10289) Add an argument file that opens all JDK packages to all unnamed modules
[
https://issues.apache.org/jira/browse/GEODE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536934#comment-17536934
]
ASF subversion and git services commented on GEODE-10289:
-
Commit c9c5c2984aef4b4847ace1c221d2c30b1f617c2c in geode's branch
refs/heads/support/1.15 from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c9c5c2984a ]
GEODE-10289: Argument file for JDK 17 (#7673) (#7693)
* GEODE-10289: Argument file for JDK 17
The argument file was generated on Linux using OpenJDK 17.0.2
* Add arg file to assembly_content.txt
> Add an argument file that opens all JDK packages to all unnamed modules
> ---
>
> Key: GEODE-10289
> URL: https://issues.apache.org/jira/browse/GEODE-10289
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.16.0
>
>
> Certain Geode functionality requires user-defined objects to be accessible
> for reflection. It can be difficult for users to identify non-opened JDK
> packages that are included in their objects.
> Add an argument file that opens all JDK packages to all unnamed modules.
> Adding this argument file when launching a client, locator, or server on JDK
> 17 essentially mimics the {{--illegal-access=permit}} option from JDK 11 (at
> least for JDK packages).
> The supplied argument file will open all packages that come with the Linux
> version of OpenJDK.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[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=17536932#comment-17536932 ] ASF subversion and git services commented on GEODE-10294: - Commit 4f4af2a303142729708a951cc8a93f562c3de8bc in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f4af2a303 ] GEODE-10294: Compare invalid token during putIfAbsent retry. (#7679) * During putIfAbsent retry, comparing invalid token value when putIfAbsent of a null value instead. > 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 > > 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-9161) No gradle 7 deprecation warnings [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-9161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales resolved GEODE-9161. --- Resolution: Fixed Resolving since all linked PRs are merged > No gradle 7 deprecation warnings [PERMANENT] > > > Key: GEODE-9161 > URL: https://issues.apache.org/jira/browse/GEODE-9161 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Why this is important: At some point this project will update to gradle 7, > and it is better to stay on top of things then behind > Given I have cloned the geode repository > When I run ./gradlew build --warning-mode=all > Then I see no output about "This will fail in gradle 7.0" or "This is > scheduled to be removed in Gradle 7.0" > Notes: > Not all warnings appear at first, you'll likely have to run with several > times as you clean up > There are some gradle 8.0 warnings. If you happen to clean those up nice! > Otherwise ok to skip for now. > There's some oddities with properties being hardcoded in other places to > their deprecated name which probably requires real work. > The following types of errors are in the project > The testRuntime configuration has been deprecated for dependency declaration. > This will fail with an error in Gradle 7.0. Please use the testRuntimeOnly > configuration instead. Consult the upgrading guide for further information: > https://docs.gradle.org/6.8.3/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations > The compile configuration has been deprecated for dependency declaration. > This will fail with an error in Gradle 7.0. Please use the implementation or > api configuration instead. Consult the upgrading guide for further > information: > https://docs.gradle.org/6.8.3/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations > The AbstractArchiveTask.baseName property has been deprecated. This is > scheduled to be removed in Gradle 7.0. Please use the archiveBaseName > property instead. See > https://docs.gradle.org/6.8.3/dsl/org.gradle.api.tasks.bundling.AbstractArchiveTask.html#org.gradle.api.tasks.bundling.AbstractArchiveTask:baseName > for more details. > The configuration :extensions:geode-modules:compileOnly was resolved without > accessing the project in a safe manner. This may happen when a configuration > is resolved from a different project. This behaviour has been deprecated and > is scheduled to be removed in Gradle 7.0. See > https://docs.gradle.org/6.8.3/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors > for more details. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10306) CacheServerImpl should stop the acceptor immediately after stop is called
[
https://issues.apache.org/jira/browse/GEODE-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536899#comment-17536899
]
ASF subversion and git services commented on GEODE-10306:
-
Commit 20844a84947a746ec4c740acf5af6734bfb272c1 in geode's branch
refs/heads/develop from mhansonp
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=20844a8494 ]
GEODE-10306 Fixing an order issue that can lead to problems when stopping
(#7682)
When stopping the cache server, the acceptor is last which should not be the
case. It should be first so new data stops coming in.
> CacheServerImpl should stop the acceptor immediately after stop is called
> -
>
> Key: GEODE-10306
> URL: https://issues.apache.org/jira/browse/GEODE-10306
> Project: Geode
> Issue Type: Bug
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
>
> Currently, after cache server stop is called, it takes a while for the
> acceptor to stop taking new data, which can be a problem because the bigger
> the window of time, the greater the risk of data loss.
>
> {noformat}
> public synchronized void stop() {
> if (!isRunning()) {
> return;
> }
> RuntimeException firstException = null;
> try {
> if (loadMonitor != null) {
> loadMonitor.stop();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing load monitor", e);
> firstException = e;
> }
> try {
> if (advisor != null) {
> advisor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing advisor", e);
> firstException = e;
> }
> PROBLEM -> try {
> if (acceptor != null) {
> acceptor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing acceptor monitor", e);
> if (firstException != null) {
> firstException = e;
> }
> } {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10306) CacheServerImpl should stop the acceptor immediately after stop is called
[
https://issues.apache.org/jira/browse/GEODE-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10306:
---
Labels: pull-request-available (was: )
> CacheServerImpl should stop the acceptor immediately after stop is called
> -
>
> Key: GEODE-10306
> URL: https://issues.apache.org/jira/browse/GEODE-10306
> Project: Geode
> Issue Type: Bug
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
>
> Currently, after cache server stop is called, it takes a while for the
> acceptor to stop taking new data, which can be a problem because the bigger
> the window of time, the greater the risk of data loss.
>
> {noformat}
> public synchronized void stop() {
> if (!isRunning()) {
> return;
> }
> RuntimeException firstException = null;
> try {
> if (loadMonitor != null) {
> loadMonitor.stop();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing load monitor", e);
> firstException = e;
> }
> try {
> if (advisor != null) {
> advisor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing advisor", e);
> firstException = e;
> }
> PROBLEM -> try {
> if (acceptor != null) {
> acceptor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing acceptor monitor", e);
> if (firstException != null) {
> firstException = e;
> }
> } {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10302) Increase upgrade test timeouts
[ https://issues.apache.org/jira/browse/GEODE-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536898#comment-17536898 ] ASF subversion and git services commented on GEODE-10302: - Commit 602f99cf99e630645021e630a4f27ef82e4f11eb in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=602f99cf99 ] GEODE-10302: Increase call stack timeout for upgrade tests (#7691) To be 3h45m, 15 minutes shy of the newly increased task timeout. > Increase upgrade test timeouts > -- > > Key: GEODE-10302 > URL: https://issues.apache.org/jira/browse/GEODE-10302 > Project: Geode > Issue Type: Improvement > Components: ci >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > > Upgrade test durations are approaching the 3h limit set by CI. > An imminent PR changes most upgrade tests to increase the number of > configurations to upgrade from. These changes push the `upgradeTest` task > over the 3h limit. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10306) CacheServerImpl should stop the acceptor immediately after stop is called
[
https://issues.apache.org/jira/browse/GEODE-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-10306:
---
Assignee: Mark Hanson
> CacheServerImpl should stop the acceptor immediately after stop is called
> -
>
> Key: GEODE-10306
> URL: https://issues.apache.org/jira/browse/GEODE-10306
> Project: Geode
> Issue Type: Bug
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
>
> Currently, after cache server stop is called, it takes a while for the
> acceptor to stop taking new data, which can be a problem because the bigger
> the window of time, the greater the risk of data loss.
>
> {noformat}
> public synchronized void stop() {
> if (!isRunning()) {
> return;
> }
> RuntimeException firstException = null;
> try {
> if (loadMonitor != null) {
> loadMonitor.stop();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing load monitor", e);
> firstException = e;
> }
> try {
> if (advisor != null) {
> advisor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing advisor", e);
> firstException = e;
> }
> PROBLEM -> try {
> if (acceptor != null) {
> acceptor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing acceptor monitor", e);
> if (firstException != null) {
> firstException = e;
> }
> } {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10311) Intermittent CI failure in AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
[
https://issues.apache.org/jira/browse/GEODE-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10311:
---
Description:
AuthExpirationBackwardCompatibleDUnitTest >
registeredInterest_FailedReAuth_non_durableClient fails intermittently. I do
not know whether this is a test problem or a product problem.
I first saw the failure in a precheckin test run on JDK17:
* [https://concourse.apachegeode-ci.info/builds/52805744]
* Test results:
[http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-results/upgradeTest/1652409122/]
* Test artifacts:
[http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-artifacts/1652409122/upgradetestfiles-geode-pr-7686.tgz]
The failure also happens on the {{develop}} branch, which does not yet have my
PR changes. The failure occured 3 times in 100 executions of this test method
on JDK11 on the {{develop}} branch.
Stack trace (from my PR precheckin):
{noformat}
java.lang.AssertionError:
Expecting empty but was:
[CacheClientProxy[identity(heavy-lifter-7d403877-c6e7-5ba6-80ed-0c1ed553c05a(117190:loner):42300:114bc2ba,connection=1;
port=42332; primary=true; version=GEODE 1.15.0]]
at
org.apache.geode.security.AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient(AuthExpirationBackwardCompatibleDUnitTest.java:653)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.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
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
[jira] [Created] (GEODE-10311) Intermittent CI failure in AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
Dale Emery created GEODE-10311:
--
Summary: Intermittent CI failure in
AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
Key: GEODE-10311
URL: https://issues.apache.org/jira/browse/GEODE-10311
Project: Geode
Issue Type: Bug
Components: core
Affects Versions: 1.15.0, 1.16.0
Reporter: Dale Emery
AuthExpirationBackwardCompatibleDUnitTest >
registeredInterest_FailedReAuth_non_durableClient fails intermittently. I do
not know whether this is a test problem or a product problem.
I first saw the failure in a precheckin test run on JDK17:
* [https://concourse.apachegeode-ci.info/builds/52805744]
* Test results:
[http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-results/upgradeTest/1652409122/]
* Test artifacts:
[http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-artifacts/1652409122/upgradetestfiles-geode-pr-7686.tgz]
The failure also happens on the {{develop}} branch, which does not yet have my
PR changes. The failure occured 3 times in 100 executions of this test method
on JDK11.
Stack trace (from my PR precheckin):
{noformat}
java.lang.AssertionError:
Expecting empty but was:
[CacheClientProxy[identity(heavy-lifter-7d403877-c6e7-5ba6-80ed-0c1ed553c05a(117190:loner):42300:114bc2ba,connection=1;
port=42332; primary=true; version=GEODE 1.15.0]]
at
org.apache.geode.security.AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient(AuthExpirationBackwardCompatibleDUnitTest.java:653)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.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-10311) Intermittent CI failure in AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
[
https://issues.apache.org/jira/browse/GEODE-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10311:
--
Labels: needsTriage (was: )
> Intermittent CI failure in
> AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
> --
>
> Key: GEODE-10311
> URL: https://issues.apache.org/jira/browse/GEODE-10311
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> AuthExpirationBackwardCompatibleDUnitTest >
> registeredInterest_FailedReAuth_non_durableClient fails intermittently. I do
> not know whether this is a test problem or a product problem.
> I first saw the failure in a precheckin test run on JDK17:
> * [https://concourse.apachegeode-ci.info/builds/52805744]
> * Test results:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-results/upgradeTest/1652409122/]
> * Test artifacts:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-artifacts/1652409122/upgradetestfiles-geode-pr-7686.tgz]
> The failure also happens on the {{develop}} branch, which does not yet have
> my PR changes. The failure occured 3 times in 100 executions of this test
> method on JDK11.
> Stack trace (from my PR precheckin):
> {noformat}
> java.lang.AssertionError:
> Expecting empty but was:
> [CacheClientProxy[identity(heavy-lifter-7d403877-c6e7-5ba6-80ed-0c1ed553c05a(117190:loner):42300:114bc2ba,connection=1;
> port=42332; primary=true; version=GEODE 1.15.0]]
> at
> org.apache.geode.security.AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient(AuthExpirationBackwardCompatibleDUnitTest.java:653)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.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
>
[jira] [Resolved] (GEODE-10307) Doc changes needed for enable security-manager property
[ https://issues.apache.org/jira/browse/GEODE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-10307. - Fix Version/s: 1.12.10 1.14.5 1.15.0 1.16.0 Assignee: Dave Barnes Resolution: Fixed > Doc changes needed for enable security-manager property > --- > > Key: GEODE-10307 > URL: https://issues.apache.org/jira/browse/GEODE-10307 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.4 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.14.5, 1.15.0, 1.16.0 > > > Community member Eric Shu reports: > Here is the description for enable security properties: > (https://geode.apache.org/docs/guide/114/managing/security/enable_security.html) > security-manager Property > The authentication callback and the authorization callback that implement the > SecurityManager interface are specified with the security-manager property. > When this property is defined, authentication and authorization are enabled. > The definition of the security-manager property is the fully qualified name > of the class that implements the SecurityManager interface. For example: > security-manager = com.example.security.MySecurityManager > To ensure that the security-manager property is applied consistently across a > cluster, follow these guidelines: > Specify the security-manager property in a properties file, such as > gemfire.properties, not in a cluster configuration file (such as > cluster.properties). > Specify the properties file when you start the first locator for the cluster. > The locator will propagate the value to all members (locators and servers) > that follow. > If you must specify the security-manager property for servers (neither > necessary nor recommended) make sure its value is exactly identical to that > specified for the first locator. > This is true if the cluster has enabled the cluster configuration service, > and new members have set the `use-cluster-configuration=true`. > Documentation should explain that if cluster configuration is not enabled, > you must specify the security-manager property for servers, makng sure its > value is exactly identical to that specified for the first locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10307) Doc changes needed for enable security-manager property
[ https://issues.apache.org/jira/browse/GEODE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536874#comment-17536874 ] ASF subversion and git services commented on GEODE-10307: - Commit d8c401699b346d3e3922da993a5d68ef11138836 in geode's branch refs/heads/support/1.12 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d8c401699b ] GEODE-10307: Doc changes needed for enable security-manager property (#7687) * GEODE-10307: Doc changes needed for enable security-manager property > Doc changes needed for enable security-manager property > --- > > Key: GEODE-10307 > URL: https://issues.apache.org/jira/browse/GEODE-10307 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.4 >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > Community member Eric Shu reports: > Here is the description for enable security properties: > (https://geode.apache.org/docs/guide/114/managing/security/enable_security.html) > security-manager Property > The authentication callback and the authorization callback that implement the > SecurityManager interface are specified with the security-manager property. > When this property is defined, authentication and authorization are enabled. > The definition of the security-manager property is the fully qualified name > of the class that implements the SecurityManager interface. For example: > security-manager = com.example.security.MySecurityManager > To ensure that the security-manager property is applied consistently across a > cluster, follow these guidelines: > Specify the security-manager property in a properties file, such as > gemfire.properties, not in a cluster configuration file (such as > cluster.properties). > Specify the properties file when you start the first locator for the cluster. > The locator will propagate the value to all members (locators and servers) > that follow. > If you must specify the security-manager property for servers (neither > necessary nor recommended) make sure its value is exactly identical to that > specified for the first locator. > This is true if the cluster has enabled the cluster configuration service, > and new members have set the `use-cluster-configuration=true`. > Documentation should explain that if cluster configuration is not enabled, > you must specify the security-manager property for servers, makng sure its > value is exactly identical to that specified for the first locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10307) Doc changes needed for enable security-manager property
[ https://issues.apache.org/jira/browse/GEODE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536872#comment-17536872 ] ASF subversion and git services commented on GEODE-10307: - Commit 08fe5c543c1ebf6c9b09776a1b1e16afac7acb41 in geode's branch refs/heads/support/1.15 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=08fe5c543c ] GEODE-10307: Doc changes needed for enable security-manager property (#7687) * GEODE-10307: Doc changes needed for enable security-manager property > Doc changes needed for enable security-manager property > --- > > Key: GEODE-10307 > URL: https://issues.apache.org/jira/browse/GEODE-10307 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.4 >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > Community member Eric Shu reports: > Here is the description for enable security properties: > (https://geode.apache.org/docs/guide/114/managing/security/enable_security.html) > security-manager Property > The authentication callback and the authorization callback that implement the > SecurityManager interface are specified with the security-manager property. > When this property is defined, authentication and authorization are enabled. > The definition of the security-manager property is the fully qualified name > of the class that implements the SecurityManager interface. For example: > security-manager = com.example.security.MySecurityManager > To ensure that the security-manager property is applied consistently across a > cluster, follow these guidelines: > Specify the security-manager property in a properties file, such as > gemfire.properties, not in a cluster configuration file (such as > cluster.properties). > Specify the properties file when you start the first locator for the cluster. > The locator will propagate the value to all members (locators and servers) > that follow. > If you must specify the security-manager property for servers (neither > necessary nor recommended) make sure its value is exactly identical to that > specified for the first locator. > This is true if the cluster has enabled the cluster configuration service, > and new members have set the `use-cluster-configuration=true`. > Documentation should explain that if cluster configuration is not enabled, > you must specify the security-manager property for servers, makng sure its > value is exactly identical to that specified for the first locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10307) Doc changes needed for enable security-manager property
[ https://issues.apache.org/jira/browse/GEODE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536871#comment-17536871 ] ASF subversion and git services commented on GEODE-10307: - Commit f0664f11972ea30c4e4e9462118cba7b10d5e6ff in geode's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0664f1197 ] GEODE-10307: Doc changes needed for enable security-manager property (#7687) * GEODE-10307: Doc changes needed for enable security-manager property > Doc changes needed for enable security-manager property > --- > > Key: GEODE-10307 > URL: https://issues.apache.org/jira/browse/GEODE-10307 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.4 >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > Community member Eric Shu reports: > Here is the description for enable security properties: > (https://geode.apache.org/docs/guide/114/managing/security/enable_security.html) > security-manager Property > The authentication callback and the authorization callback that implement the > SecurityManager interface are specified with the security-manager property. > When this property is defined, authentication and authorization are enabled. > The definition of the security-manager property is the fully qualified name > of the class that implements the SecurityManager interface. For example: > security-manager = com.example.security.MySecurityManager > To ensure that the security-manager property is applied consistently across a > cluster, follow these guidelines: > Specify the security-manager property in a properties file, such as > gemfire.properties, not in a cluster configuration file (such as > cluster.properties). > Specify the properties file when you start the first locator for the cluster. > The locator will propagate the value to all members (locators and servers) > that follow. > If you must specify the security-manager property for servers (neither > necessary nor recommended) make sure its value is exactly identical to that > specified for the first locator. > This is true if the cluster has enabled the cluster configuration service, > and new members have set the `use-cluster-configuration=true`. > Documentation should explain that if cluster configuration is not enabled, > you must specify the security-manager property for servers, makng sure its > value is exactly identical to that specified for the first locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10290) GII requester should remove departed members
[ https://issues.apache.org/jira/browse/GEODE-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10290: -- Labels: blocks-1.15.0 pull-request-available (was: needsTriage pull-request-available) > GII requester should remove departed members > > > Key: GEODE-10290 > URL: https://issues.apache.org/jira/browse/GEODE-10290 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > In non-persistent but concurrent-check enabled case, members departed will be > marked. They should be removed from RVV during GII to prevent memberToVersion > in RVV grows bigger and bigger. > However, we only removed them from GII provider, not in GII requester. The > good opportunity to remove them in GII requester is when calculating > unfinished operations. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10307) Doc changes needed for enable security-manager property
[ https://issues.apache.org/jira/browse/GEODE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536868#comment-17536868 ] ASF subversion and git services commented on GEODE-10307: - Commit 0ed779351824eddbdd1b6801268e185b0b321950 in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0ed7793518 ] GEODE-10307: Doc changes needed for enable security-manager property (#7687) * GEODE-10307: Doc changes needed for enable security-manager property > Doc changes needed for enable security-manager property > --- > > Key: GEODE-10307 > URL: https://issues.apache.org/jira/browse/GEODE-10307 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.4 >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > Community member Eric Shu reports: > Here is the description for enable security properties: > (https://geode.apache.org/docs/guide/114/managing/security/enable_security.html) > security-manager Property > The authentication callback and the authorization callback that implement the > SecurityManager interface are specified with the security-manager property. > When this property is defined, authentication and authorization are enabled. > The definition of the security-manager property is the fully qualified name > of the class that implements the SecurityManager interface. For example: > security-manager = com.example.security.MySecurityManager > To ensure that the security-manager property is applied consistently across a > cluster, follow these guidelines: > Specify the security-manager property in a properties file, such as > gemfire.properties, not in a cluster configuration file (such as > cluster.properties). > Specify the properties file when you start the first locator for the cluster. > The locator will propagate the value to all members (locators and servers) > that follow. > If you must specify the security-manager property for servers (neither > necessary nor recommended) make sure its value is exactly identical to that > specified for the first locator. > This is true if the cluster has enabled the cluster configuration service, > and new members have set the `use-cluster-configuration=true`. > Documentation should explain that if cluster configuration is not enabled, > you must specify the security-manager property for servers, makng sure its > value is exactly identical to that specified for the first locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10291) Support Jammy (ubuntu 22.04)
[ https://issues.apache.org/jira/browse/GEODE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536843#comment-17536843 ] ASF GitHub Bot commented on GEODE-10291: moleske opened a new pull request, #972: URL: https://github.com/apache/geode-native/pull/972 - found the differences when working on adding ubuntu 22.04 Authored-by: M. Oleske > Support Jammy (ubuntu 22.04) > > > Key: GEODE-10291 > URL: https://issues.apache.org/jira/browse/GEODE-10291 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Native client should compile on the latest (ubuntu 22.04) operating system. > Consider including a new pipeline as part of this -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10292) Upgrade boost to 1.79.0
[ https://issues.apache.org/jira/browse/GEODE-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536842#comment-17536842 ] ASF GitHub Bot commented on GEODE-10292: moleske commented on PR #967: URL: https://github.com/apache/geode-native/pull/967#issuecomment-1126355412 surprised at the sad time for windows. I thought on my windows 10/vs2019 personal machine things were fine, but guess will have to check again > Upgrade boost to 1.79.0 > --- > > Key: GEODE-10292 > URL: https://issues.apache.org/jira/browse/GEODE-10292 > Project: Geode > Issue Type: Task >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Upgrade boost to 1.79.0 as first step in supporting visual studio 2022 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10306) CacheServerImpl should stop the acceptor immediately after stop is called
[
https://issues.apache.org/jira/browse/GEODE-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10306:
--
Labels: (was: needsTriage)
> CacheServerImpl should stop the acceptor immediately after stop is called
> -
>
> Key: GEODE-10306
> URL: https://issues.apache.org/jira/browse/GEODE-10306
> Project: Geode
> Issue Type: Bug
>Reporter: Mark Hanson
>Priority: Major
>
> Currently, after cache server stop is called, it takes a while for the
> acceptor to stop taking new data, which can be a problem because the bigger
> the window of time, the greater the risk of data loss.
>
> {noformat}
> public synchronized void stop() {
> if (!isRunning()) {
> return;
> }
> RuntimeException firstException = null;
> try {
> if (loadMonitor != null) {
> loadMonitor.stop();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing load monitor", e);
> firstException = e;
> }
> try {
> if (advisor != null) {
> advisor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing advisor", e);
> firstException = e;
> }
> PROBLEM -> try {
> if (acceptor != null) {
> acceptor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing acceptor monitor", e);
> if (firstException != null) {
> firstException = e;
> }
> } {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[ https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10300: -- Labels: pull-request-available (was: needsTriage pull-request-available) > C++ Native client messages coming from the locator cannot be longer than 3000 > bytes > --- > > Key: GEODE-10300 > URL: https://issues.apache.org/jira/browse/GEODE-10300 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > If a locator sends a response to the C++ native client that is longer than > 3000 bytes the C++ native client library will only read the first 3000 bytes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10257) Enhance upgrade tests to upgrade JDK
[ https://issues.apache.org/jira/browse/GEODE-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10257: --- Labels: Java17 pull-request-available (was: Java17) > Enhance upgrade tests to upgrade JDK > > > Key: GEODE-10257 > URL: https://issues.apache.org/jira/browse/GEODE-10257 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > > Currently, upgrade tests upgrade Geode from each old version to the current > version, on whatever JDK the test is running. > Expand this to also upgrade the current version of Geode from each older JDK > to each newer JDK (or to the JDK running the tests). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[ https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536744#comment-17536744 ] ASF subversion and git services commented on GEODE-10218: - Commit d649264b975891ce352ddc88ffb863cbc6236fdb in geode-native's branch refs/heads/develop from Michael Martell [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d649264b9 ] GEODE-10218: Allow server debug (#971) * Remove unused List * Show withDebugAgent() usage in cli > Launch Cluster with Attachability Flag > -- > > Key: GEODE-10218 > URL: https://issues.apache.org/jira/browse/GEODE-10218 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Minor > Labels: pull-request-available > > To assist with protocol analysis it is very helpful to be able to step > through the server code in the Intellij debugger while running native client > test code. However, to be allowed to set breakpoints in the server code, the > server must be started with the special flag below: > > --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT > This ticket is to add support for the above flag in the native client test > frameworks. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[ https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536743#comment-17536743 ] ASF GitHub Bot commented on GEODE-10218: mmartell merged PR #971: URL: https://github.com/apache/geode-native/pull/971 > Launch Cluster with Attachability Flag > -- > > Key: GEODE-10218 > URL: https://issues.apache.org/jira/browse/GEODE-10218 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Minor > Labels: pull-request-available > > To assist with protocol analysis it is very helpful to be able to step > through the server code in the Intellij debugger while running native client > test code. However, to be allowed to set breakpoints in the server code, the > server must be started with the special flag below: > > --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT > This ticket is to add support for the above flag in the native client test > frameworks. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[
https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536620#comment-17536620
]
ASF GitHub Bot commented on GEODE-10300:
albertogpz commented on code in PR #970:
URL: https://github.com/apache/geode-native/pull/970#discussion_r872356339
##
cppcache/src/StreamDataInput.cpp:
##
@@ -31,65 +31,57 @@ const size_t kBufferSize = 3000;
StreamDataInput::StreamDataInput(std::chrono::milliseconds timeout,
std::unique_ptr connector,
const CacheImpl* cache, Pool* pool)
-: DataInput(nullptr, 0, cache, pool) {
- m_remainingTimeBeforeTimeout = timeout;
- m_connector = std::move(connector);
- m_buf = nullptr;
- m_bufHead = m_buf;
- m_bufLength = 0;
-}
-
-StreamDataInput::~StreamDataInput() {
- if (m_bufHead != nullptr) {
-free(const_cast(m_bufHead));
- }
+: DataInput(nullptr, 0, cache, pool),
+ connector_(std::move(connector)),
+ remainingTimeBeforeTimeout_(timeout),
+ streamBuf_(0) {
+ buf_ = nullptr;
+ bufHead_ = buf_;
+ bufLength_ = 0;
}
void StreamDataInput::readDataIfNotAvailable(size_t size) {
char buff[kBufferSize];
- while ((m_bufLength - (m_buf - m_bufHead)) < size) {
+ while (getBytesRemaining() < size) {
const auto start = std::chrono::system_clock::now();
-const auto receivedLength = m_connector->receive_nothrowiftimeout(
+const auto receivedLength = connector_->receive_nothrowiftimeout(
buff, kBufferSize,
std::chrono::duration_cast(
-m_remainingTimeBeforeTimeout));
+remainingTimeBeforeTimeout_));
const auto timeSpent = std::chrono::system_clock::now() - start;
-m_remainingTimeBeforeTimeout -=
-std::chrono::duration_cast(
+remainingTimeBeforeTimeout_ -=
+std::chrono::duration_cast(
timeSpent);
LOGDEBUG(
"received %d bytes from %s: %s, time spent: "
"%ld microsecs, time remaining before timeout: %ld microsecs",
-receivedLength, m_connector->getRemoteEndpoint().c_str(),
+receivedLength, connector_->getRemoteEndpoint().c_str(),
Utils::convertBytesToString(reinterpret_cast(buff),
receivedLength)
.c_str(),
std::chrono::duration_cast(timeSpent)
.count(),
std::chrono::duration_cast(
-m_remainingTimeBeforeTimeout)
+remainingTimeBeforeTimeout_)
.count());
-if (m_remainingTimeBeforeTimeout <= std::chrono::microseconds ::zero()) {
+if (remainingTimeBeforeTimeout_ <= std::chrono::microseconds ::zero()) {
throw(TimeoutException(std::string("Timeout when receiving from ")
- .append(m_connector->getRemoteEndpoint(;
+ .append(connector_->getRemoteEndpoint(;
}
-auto newLength = m_bufLength + receivedLength;
-auto currentPosition = m_buf - m_bufHead;
-if ((m_bufHead) == nullptr) {
- m_bufHead = static_cast(malloc(sizeof(uint8_t) * newLength));
-} else {
- m_bufHead = static_cast(
- realloc(const_cast(m_bufHead), newLength));
-}
-memcpy(const_cast(m_bufHead + m_bufLength), buff,
receivedLength);
-m_buf = m_bufHead + currentPosition;
-m_bufLength += receivedLength;
+auto currentPosition = getBytesRead();
+streamBuf_.resize(bufLength_ + receivedLength);
+streamBuf_.insert(streamBuf_.begin() + bufLength_, buff,
Review Comment:
You are absolutely right. Thanks
> C++ Native client messages coming from the locator cannot be longer than 3000
> bytes
> ---
>
> Key: GEODE-10300
> URL: https://issues.apache.org/jira/browse/GEODE-10300
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If a locator sends a response to the C++ native client that is longer than
> 3000 bytes the C++ native client library will only read the first 3000 bytes.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10310) Deactivate possibility to retry operation on partitioned region, when member containing primary bucket is restarted
[ https://issues.apache.org/jira/browse/GEODE-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10310: --- Labels: pull-request-available (was: ) > Deactivate possibility to retry operation on partitioned region, when member > containing primary bucket is restarted > --- > > Key: GEODE-10310 > URL: https://issues.apache.org/jira/browse/GEODE-10310 > Project: Geode > Issue Type: Improvement > Components: regions >Affects Versions: 1.14.4 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > In case client is putting data in partitioned region, and server is > restarted, add option not to retry operation for case when member with > primary bucket is restarted. In that case, operation will be aborted and > notified to client, instead of waiting for primary bucket to be reallocated. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10218) Launch Cluster with Attachability Flag
[ https://issues.apache.org/jira/browse/GEODE-10218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536612#comment-17536612 ] ASF GitHub Bot commented on GEODE-10218: mmartell opened a new pull request, #971: URL: https://github.com/apache/geode-native/pull/971 Resubmitting a new PR to include changes per review by pdxcodemonkey. > Launch Cluster with Attachability Flag > -- > > Key: GEODE-10218 > URL: https://issues.apache.org/jira/browse/GEODE-10218 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Minor > Labels: pull-request-available > > To assist with protocol analysis it is very helpful to be able to step > through the server code in the Intellij debugger while running native client > test code. However, to be allowed to set breakpoints in the server code, the > server must be started with the special flag below: > > --J=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:FREEPORT > This ticket is to add support for the above flag in the native client test > frameworks. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[
https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536575#comment-17536575
]
ASF GitHub Bot commented on GEODE-10300:
albertogpz commented on code in PR #970:
URL: https://github.com/apache/geode-native/pull/970#discussion_r872292220
##
cppcache/src/CacheXmlCreation.cpp:
##
@@ -50,12 +50,12 @@ void CacheXmlCreation::create(Cache* cache) {
}
void CacheXmlCreation::setPdxIgnoreUnreadField(bool ignore) {
- // m_cache->m_cacheImpl->setPdxIgnoreUnreadFields(ignore);
+ // cache_->m_cacheImpl->setPdxIgnoreUnreadFields(ignore);
Review Comment:
Yep, CLion did it for me and I did not check it.
> C++ Native client messages coming from the locator cannot be longer than 3000
> bytes
> ---
>
> Key: GEODE-10300
> URL: https://issues.apache.org/jira/browse/GEODE-10300
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If a locator sends a response to the C++ native client that is longer than
> 3000 bytes the C++ native client library will only read the first 3000 bytes.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[
https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536572#comment-17536572
]
ASF GitHub Bot commented on GEODE-10300:
gaussianrecurrence commented on code in PR #970:
URL: https://github.com/apache/geode-native/pull/970#discussion_r872273823
##
cppcache/src/CacheXmlCreation.cpp:
##
@@ -50,12 +50,12 @@ void CacheXmlCreation::create(Cache* cache) {
}
void CacheXmlCreation::setPdxIgnoreUnreadField(bool ignore) {
- // m_cache->m_cacheImpl->setPdxIgnoreUnreadFields(ignore);
+ // cache_->m_cacheImpl->setPdxIgnoreUnreadFields(ignore);
Review Comment:
I think you might have change this by mistake?
##
cppcache/src/StreamDataInput.cpp:
##
@@ -31,65 +31,57 @@ const size_t kBufferSize = 3000;
StreamDataInput::StreamDataInput(std::chrono::milliseconds timeout,
std::unique_ptr connector,
const CacheImpl* cache, Pool* pool)
-: DataInput(nullptr, 0, cache, pool) {
- m_remainingTimeBeforeTimeout = timeout;
- m_connector = std::move(connector);
- m_buf = nullptr;
- m_bufHead = m_buf;
- m_bufLength = 0;
-}
-
-StreamDataInput::~StreamDataInput() {
- if (m_bufHead != nullptr) {
-free(const_cast(m_bufHead));
- }
+: DataInput(nullptr, 0, cache, pool),
+ connector_(std::move(connector)),
+ remainingTimeBeforeTimeout_(timeout),
+ streamBuf_(0) {
+ buf_ = nullptr;
+ bufHead_ = buf_;
+ bufLength_ = 0;
}
void StreamDataInput::readDataIfNotAvailable(size_t size) {
char buff[kBufferSize];
- while ((m_bufLength - (m_buf - m_bufHead)) < size) {
+ while (getBytesRemaining() < size) {
const auto start = std::chrono::system_clock::now();
-const auto receivedLength = m_connector->receive_nothrowiftimeout(
+const auto receivedLength = connector_->receive_nothrowiftimeout(
buff, kBufferSize,
std::chrono::duration_cast(
-m_remainingTimeBeforeTimeout));
+remainingTimeBeforeTimeout_));
const auto timeSpent = std::chrono::system_clock::now() - start;
-m_remainingTimeBeforeTimeout -=
-std::chrono::duration_cast(
+remainingTimeBeforeTimeout_ -=
+std::chrono::duration_cast(
timeSpent);
LOGDEBUG(
"received %d bytes from %s: %s, time spent: "
"%ld microsecs, time remaining before timeout: %ld microsecs",
-receivedLength, m_connector->getRemoteEndpoint().c_str(),
+receivedLength, connector_->getRemoteEndpoint().c_str(),
Utils::convertBytesToString(reinterpret_cast(buff),
receivedLength)
.c_str(),
std::chrono::duration_cast(timeSpent)
.count(),
std::chrono::duration_cast(
-m_remainingTimeBeforeTimeout)
+remainingTimeBeforeTimeout_)
.count());
-if (m_remainingTimeBeforeTimeout <= std::chrono::microseconds ::zero()) {
+if (remainingTimeBeforeTimeout_ <= std::chrono::microseconds ::zero()) {
throw(TimeoutException(std::string("Timeout when receiving from ")
- .append(m_connector->getRemoteEndpoint(;
+ .append(connector_->getRemoteEndpoint(;
}
-auto newLength = m_bufLength + receivedLength;
-auto currentPosition = m_buf - m_bufHead;
-if ((m_bufHead) == nullptr) {
- m_bufHead = static_cast(malloc(sizeof(uint8_t) * newLength));
-} else {
- m_bufHead = static_cast(
- realloc(const_cast(m_bufHead), newLength));
-}
-memcpy(const_cast(m_bufHead + m_bufLength), buff,
receivedLength);
-m_buf = m_bufHead + currentPosition;
-m_bufLength += receivedLength;
+auto currentPosition = getBytesRead();
+streamBuf_.resize(bufLength_ + receivedLength);
+streamBuf_.insert(streamBuf_.begin() + bufLength_, buff,
Review Comment:
Actually, insert, extends the buffer size, so, even this is working, you'd
be allocating more memory than necessary.
Also, in the case of a buff copy it's always best to use std::memcpy as it's
optimized for this purpose by compilers.
##
cppcache/src/StreamDataInput.cpp:
##
@@ -31,65 +31,57 @@ const size_t kBufferSize = 3000;
StreamDataInput::StreamDataInput(std::chrono::milliseconds timeout,
std::unique_ptr connector,
const CacheImpl* cache, Pool* pool)
-: DataInput(nullptr, 0, cache, pool) {
- m_remainingTimeBeforeTimeout = timeout;
- m_connector = std::move(connector);
- m_buf = nullptr;
- m_bufHead = m_buf;
- m_bufLength = 0;
-}
-
-StreamDataInput::~StreamDataInput() {
- if (m_bufHead != nullptr) {
-free(const_cast(m_bufHead));
- }
+: DataInput(nullptr, 0, cache, pool),
+ connector_(std::move(connector)),
+
[jira] [Commented] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[
https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536542#comment-17536542
]
ASF GitHub Bot commented on GEODE-10300:
albertogpz commented on code in PR #970:
URL: https://github.com/apache/geode-native/pull/970#discussion_r872219994
##
cppcache/src/StreamDataInput.cpp:
##
@@ -0,0 +1,98 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "StreamDataInput.hpp"
+
+#include
+
+#include "Utils.hpp"
+#include "util/Log.hpp"
+
+namespace apache {
+namespace geode {
+namespace client {
+
+const size_t kBufferSize = 3000;
+
+StreamDataInput::StreamDataInput(std::chrono::milliseconds timeout,
+ std::unique_ptr connector,
+ const CacheImpl* cache, Pool* pool)
+: DataInput(nullptr, 0, cache, pool) {
+ m_remainingTimeBeforeTimeout = timeout;
+ m_connector = std::move(connector);
+ m_buf = nullptr;
+ m_bufHead = m_buf;
+ m_bufLength = 0;
+}
+
+StreamDataInput::~StreamDataInput() {
+ if (m_bufHead != nullptr) {
+free(const_cast(m_bufHead));
+ }
+}
+
+void StreamDataInput::readDataIfNotAvailable(size_t size) {
+ char buff[kBufferSize];
+ while ((m_bufLength - (m_buf - m_bufHead)) < size) {
Review Comment:
Indeed! :-)
> C++ Native client messages coming from the locator cannot be longer than 3000
> bytes
> ---
>
> Key: GEODE-10300
> URL: https://issues.apache.org/jira/browse/GEODE-10300
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If a locator sends a response to the C++ native client that is longer than
> 3000 bytes the C++ native client library will only read the first 3000 bytes.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[
https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536525#comment-17536525
]
ASF GitHub Bot commented on GEODE-10300:
gaussianrecurrence commented on code in PR #970:
URL: https://github.com/apache/geode-native/pull/970#discussion_r872148851
##
cppcache/src/StreamDataInput.cpp:
##
@@ -0,0 +1,98 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "StreamDataInput.hpp"
+
+#include
+
+#include "Utils.hpp"
+#include "util/Log.hpp"
+
+namespace apache {
+namespace geode {
+namespace client {
+
+const size_t BUFF_SIZE = 3000;
+
+StreamDataInput::StreamDataInput(std::chrono::milliseconds timeout,
+ std::unique_ptr connector,
+ const CacheImpl* cache, Pool* pool)
+: DataInput(nullptr, 0, cache, pool) {
+ m_remainingTimeBeforeTimeout = timeout;
+ m_connector = std::move(connector);
+ m_buf = nullptr;
+ m_bufHead = m_buf;
+ m_bufLength = 0;
+}
+
+StreamDataInput::~StreamDataInput() {
+ if (m_bufHead != nullptr) {
+free(const_cast(m_bufHead));
Review Comment:
One feasible solution would be to have an std::vector as buffer for
StreamDataInput, this way you don't need to perform memory managment, that is
prone to mem leaks.
> C++ Native client messages coming from the locator cannot be longer than 3000
> bytes
> ---
>
> Key: GEODE-10300
> URL: https://issues.apache.org/jira/browse/GEODE-10300
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If a locator sends a response to the C++ native client that is longer than
> 3000 bytes the C++ native client library will only read the first 3000 bytes.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[
https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536518#comment-17536518
]
ASF GitHub Bot commented on GEODE-10300:
gaussianrecurrence commented on code in PR #970:
URL: https://github.com/apache/geode-native/pull/970#discussion_r872129402
##
cppcache/include/geode/DataInput.hpp:
##
@@ -452,19 +452,19 @@ class APACHE_GEODE_EXPORT DataInput {
DataInput& operator=(DataInput&&) = default;
protected:
+ const uint8_t* m_buf;
+ const uint8_t* m_bufHead;
Review Comment:
Naming notation for member attributes in Geode Native follows lowerCamelCase
with _ as a postfix, to indicate that it's a member variable. As example
'm_buf' would rather be 'buf_'. Usually whenever we make a change that touches
part of the code with the old notation (m_...) the idea is to change it to the
right notation
> C++ Native client messages coming from the locator cannot be longer than 3000
> bytes
> ---
>
> Key: GEODE-10300
> URL: https://issues.apache.org/jira/browse/GEODE-10300
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If a locator sends a response to the C++ native client that is longer than
> 3000 bytes the C++ native client library will only read the first 3000 bytes.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[
https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536517#comment-17536517
]
ASF GitHub Bot commented on GEODE-10300:
gaussianrecurrence commented on code in PR #970:
URL: https://github.com/apache/geode-native/pull/970#discussion_r872129402
##
cppcache/include/geode/DataInput.hpp:
##
@@ -452,19 +452,19 @@ class APACHE_GEODE_EXPORT DataInput {
DataInput& operator=(DataInput&&) = default;
protected:
+ const uint8_t* m_buf;
+ const uint8_t* m_bufHead;
Review Comment:
Naming notation for member attributes in Geode Native follows lowerCamelCase
with '_' as a postfix, to indicate that it's a member variable. As example
'm_buf' would rather be 'buf_'. Usually whenever we make a change that touches
part of the code with the old notation (m_...) the idea is to change it to the
right notation
##
cppcache/src/GetAllServersResponse.hpp:
##
@@ -42,6 +42,11 @@ class GetAllServersResponse : public
internal::DataSerializableFixedId_t<
return std::make_shared();
}
GetAllServersResponse() : Serializable() {}
+ explicit GetAllServersResponse(
+ std::vector > servers)
+ : Serializable() {
+m_servers = servers;
Review Comment:
Same comment regarding member attributes naming conventions:
- Please use lowerCamelCase_ notation.
- All the member attributes should be declared at the end of the class
rather than at the beginning.
Also, I've seen member attributes scope is not explicitly set in this class,
by default this means it would be private, but I usually like to explicitly
state it. So don't forget to state the scope after chaning the location of the
member attributes :)
##
cppcache/src/GetAllServersResponse.hpp:
##
@@ -42,6 +42,11 @@ class GetAllServersResponse : public
internal::DataSerializableFixedId_t<
return std::make_shared();
}
GetAllServersResponse() : Serializable() {}
+ explicit GetAllServersResponse(
+ std::vector > servers)
+ : Serializable() {
+m_servers = servers;
Review Comment:
This is only used for testing, however if you pass an object copy to this
constructor and then make a copy-assign, you'd be copying this twice. Please
use std::move :)
##
cppcache/src/GetAllServersResponse.hpp:
##
@@ -42,6 +42,11 @@ class GetAllServersResponse : public
internal::DataSerializableFixedId_t<
return std::make_shared();
}
GetAllServersResponse() : Serializable() {}
+ explicit GetAllServersResponse(
+ std::vector > servers)
+ : Serializable() {
+m_servers = servers;
Review Comment:
Usually it's preferred, when possible to use constructor inline
initialization for member attributes
##
cppcache/src/StreamDataInput.cpp:
##
@@ -0,0 +1,98 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "StreamDataInput.hpp"
+
+#include
+
+#include "Utils.hpp"
+#include "util/Log.hpp"
+
+namespace apache {
+namespace geode {
+namespace client {
+
+const size_t kBufferSize = 3000;
+
+StreamDataInput::StreamDataInput(std::chrono::milliseconds timeout,
+ std::unique_ptr connector,
+ const CacheImpl* cache, Pool* pool)
+: DataInput(nullptr, 0, cache, pool) {
+ m_remainingTimeBeforeTimeout = timeout;
Review Comment:
Same comment regarding member attributes naming conventions:
- Please use lowerCamelCase_ notation.
- Also, when possible, use constructor inline initialization for member
attributes.
##
cppcache/src/StreamDataInput.cpp:
##
@@ -0,0 +1,98 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
[jira] [Created] (GEODE-10310) Deactivate possibility to retry operation on partitioned region, when member containing primary bucket is restarted
Mario Ivanac created GEODE-10310: Summary: Deactivate possibility to retry operation on partitioned region, when member containing primary bucket is restarted Key: GEODE-10310 URL: https://issues.apache.org/jira/browse/GEODE-10310 Project: Geode Issue Type: Improvement Components: regions Affects Versions: 1.14.4 Reporter: Mario Ivanac In case client is putting data in partitioned region, and server is restarted, add option not to retry operation for case when member with primary bucket is restarted. In that case, operation will be aborted and notified to client, instead of waiting for primary bucket to be reallocated. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10310) Deactivate possibility to retry operation on partitioned region, when member containing primary bucket is restarted
[ https://issues.apache.org/jira/browse/GEODE-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-10310: Assignee: Mario Ivanac > Deactivate possibility to retry operation on partitioned region, when member > containing primary bucket is restarted > --- > > Key: GEODE-10310 > URL: https://issues.apache.org/jira/browse/GEODE-10310 > Project: Geode > Issue Type: Improvement > Components: regions >Affects Versions: 1.14.4 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > In case client is putting data in partitioned region, and server is > restarted, add option not to retry operation for case when member with > primary bucket is restarted. In that case, operation will be aborted and > notified to client, instead of waiting for primary bucket to be reallocated. -- This message was sent by Atlassian Jira (v8.20.7#820007)
