[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423444#comment-17423444
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#235|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/235].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Updated] (GEODE-9665) RENAME or RENAMENX using keys on different servers causes multiple redirections
[ https://issues.apache.org/jira/browse/GEODE-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9665: -- Labels: needsTriage pull-request-available (was: needsTriage) > RENAME or RENAMENX using keys on different servers causes multiple > redirections > --- > > Key: GEODE-9665 > URL: https://issues.apache.org/jira/browse/GEODE-9665 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Assignee: Eric Zoerner >Priority: Major > Labels: needsTriage, pull-request-available > > when running on a multi-server cluster, an attempt to rename with source and > target keys that are hosted on different servers causes multiple MOVED > redirects. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9665) RENAME or RENAMENX using keys on different servers causes multiple redirections
[ https://issues.apache.org/jira/browse/GEODE-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423438#comment-17423438 ] Eric Zoerner commented on GEODE-9665: - >From John Martin's cli session: 127.0.0.1:6380> set thekey foo -> Redirected to slot [3488] located at 127.0.0.1:6379 OK 127.0.0.1:6379> renamenx thekey theotherkey -> Redirected to slot [650] located at 127.0.0.1:6380 -> Redirected to slot [3488] located at 127.0.0.1:6379 -> Redirected to slot [650] located at 127.0.0.1:6380 -> Redirected to slot [3488] located at 127.0.0.1:6379 -> Redirected to slot [650] located at 127.0.0.1:6380 -> Redirected to slot [3488] located at 127.0.0.1:6379 -> Redirected to slot [650] located at 127.0.0.1:6380 -> Redirected to slot [3488] located at 127.0.0.1:6379 -> Redirected to slot [650] located at 127.0.0.1:6380 -> Redirected to slot [3488] located at 127.0.0.1:6379 -> Redirected to slot [650] located at 127.0.0.1:6380 -> Redirected to slot [3488] located at 127.0.0.1:6379 -> Redirected to slot [650] located at 127.0.0.1:6380 > RENAME or RENAMENX using keys on different servers causes multiple > redirections > --- > > Key: GEODE-9665 > URL: https://issues.apache.org/jira/browse/GEODE-9665 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Assignee: Eric Zoerner >Priority: Major > Labels: needsTriage > > when running on a multi-server cluster, an attempt to rename with source and > target keys that are hosted on different servers causes multiple MOVED > redirects. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9666) Client throws NoAvailableLocatorsException after locators change IP addresses
Aaron Lindsey created GEODE-9666:
Summary: Client throws NoAvailableLocatorsException after locators
change IP addresses
Key: GEODE-9666
URL: https://issues.apache.org/jira/browse/GEODE-9666
Project: Geode
Issue Type: Bug
Components: membership
Affects Versions: 1.15.0
Reporter: Aaron Lindsey
We have a test for Geode on Kubernetes which:
* Deploys a Geode cluster consisting of 2 locator Pods, 3 server Pods
* Deploys 5 Spring boot client Pods which continually do PUTs and GETs
* Triggers a rolling restart of the locator Pods
** The rolling restart operation restarts one locator at a time, waiting for
each restarted locator to become fully online before restarting the next locator
* Stops the client operations and validates there were no exceptions thrown in
the clients.
Occasionally, we see {{NoAvailableLocatorsException}} thrown on one of the
clients:
{code:none}
org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to connect
to any locators in the list
[system-test-gemfire-locator-0.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334,
system-test-gemfire-locator-1.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334]
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:174)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:198)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:276)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:136)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
at org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:92)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:114)
at
org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2802)
at
org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1469)
at
org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1442)
at
org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:197)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1379)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1318)
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1303)
at
org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:439)
at
org.apache.geode.kubernetes.client.service.AsyncOperationService.evaluate(AsyncOperationService.java:282)
at
org.apache.geode.kubernetes.client.api.Controller.evaluateRegion(Controller.java:88)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:197)
at
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:141)
at
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:106)
at
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:894)
at
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
at
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1063)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:963)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
[jira] [Updated] (GEODE-9666) Client throws NoAvailableLocatorsException after locators change IP addresses
[
https://issues.apache.org/jira/browse/GEODE-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9666:
-
Labels: needsTriage (was: )
> Client throws NoAvailableLocatorsException after locators change IP addresses
> -
>
> Key: GEODE-9666
> URL: https://issues.apache.org/jira/browse/GEODE-9666
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Aaron Lindsey
>Priority: Major
> Labels: needsTriage
>
> We have a test for Geode on Kubernetes which:
> * Deploys a Geode cluster consisting of 2 locator Pods, 3 server Pods
> * Deploys 5 Spring boot client Pods which continually do PUTs and GETs
> * Triggers a rolling restart of the locator Pods
> ** The rolling restart operation restarts one locator at a time, waiting for
> each restarted locator to become fully online before restarting the next
> locator
> * Stops the client operations and validates there were no exceptions thrown
> in the clients.
> Occasionally, we see {{NoAvailableLocatorsException}} thrown on one of the
> clients:
> {code:none}
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to connect
> to any locators in the list
> [system-test-gemfire-locator-0.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334,
>
> system-test-gemfire-locator-1.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:174)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:198)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:276)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:136)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:92)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:114)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2802)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1469)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1442)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:197)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1379)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1318)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1303)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:439)
> at
> org.apache.geode.kubernetes.client.service.AsyncOperationService.evaluate(AsyncOperationService.java:282)
> at
> org.apache.geode.kubernetes.client.api.Controller.evaluateRegion(Controller.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:197)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:141)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:106)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:894)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
> at
>
[jira] [Assigned] (GEODE-9666) Client throws NoAvailableLocatorsException after locators change IP addresses
[
https://issues.apache.org/jira/browse/GEODE-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey reassigned GEODE-9666:
Assignee: Aaron Lindsey
> Client throws NoAvailableLocatorsException after locators change IP addresses
> -
>
> Key: GEODE-9666
> URL: https://issues.apache.org/jira/browse/GEODE-9666
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Labels: needsTriage
>
> We have a test for Geode on Kubernetes which:
> * Deploys a Geode cluster consisting of 2 locator Pods, 3 server Pods
> * Deploys 5 Spring boot client Pods which continually do PUTs and GETs
> * Triggers a rolling restart of the locator Pods
> ** The rolling restart operation restarts one locator at a time, waiting for
> each restarted locator to become fully online before restarting the next
> locator
> * Stops the client operations and validates there were no exceptions thrown
> in the clients.
> Occasionally, we see {{NoAvailableLocatorsException}} thrown on one of the
> clients:
> {code:none}
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to connect
> to any locators in the list
> [system-test-gemfire-locator-0.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334,
>
> system-test-gemfire-locator-1.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:174)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:198)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:276)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:136)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:92)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:114)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2802)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1469)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1442)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:197)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1379)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1318)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1303)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:439)
> at
> org.apache.geode.kubernetes.client.service.AsyncOperationService.evaluate(AsyncOperationService.java:282)
> at
> org.apache.geode.kubernetes.client.api.Controller.evaluateRegion(Controller.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:197)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:141)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:106)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:894)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
> at
>
[jira] [Assigned] (GEODE-9665) RENAME or RENAMENX using keys on different servers causes multiple redirections
[ https://issues.apache.org/jira/browse/GEODE-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Zoerner reassigned GEODE-9665: --- Assignee: Eric Zoerner > RENAME or RENAMENX using keys on different servers causes multiple > redirections > --- > > Key: GEODE-9665 > URL: https://issues.apache.org/jira/browse/GEODE-9665 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Assignee: Eric Zoerner >Priority: Major > Labels: needsTriage > > when running on a multi-server cluster, an attempt to rename with source and > target keys that are hosted on different servers causes multiple MOVED > redirects. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9665) RENAME or RENAMENX using keys on different servers causes multiple redirections
[ https://issues.apache.org/jira/browse/GEODE-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9665: - Labels: needsTriage (was: ) > RENAME or RENAMENX using keys on different servers causes multiple > redirections > --- > > Key: GEODE-9665 > URL: https://issues.apache.org/jira/browse/GEODE-9665 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Priority: Major > Labels: needsTriage > > when running on a multi-server cluster, an attempt to rename with source and > target keys that are hosted on different servers causes multiple MOVED > redirects. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9665) RENAME or RENAMENX using keys on different servers causes multiple redirections
Eric Zoerner created GEODE-9665: --- Summary: RENAME or RENAMENX using keys on different servers causes multiple redirections Key: GEODE-9665 URL: https://issues.apache.org/jira/browse/GEODE-9665 Project: Geode Issue Type: Bug Components: redis Affects Versions: 1.15.0 Reporter: Eric Zoerner when running on a multi-server cluster, an attempt to rename with source and target keys that are hosted on different servers causes multiple MOVED redirects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9658) CI Failure: AuthExpirationDUnitTest > newClient_registeredInterest_slowReAuth_policyNone_durableClient failed due to
[
https://issues.apache.org/jira/browse/GEODE-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9658:
-
Labels: pull-request-available (was: needsTriage pull-request-available)
> CI Failure: AuthExpirationDUnitTest >
> newClient_registeredInterest_slowReAuth_policyNone_durableClient failed due
> to
> -
>
> Key: GEODE-9658
> URL: https://issues.apache.org/jira/browse/GEODE-9658
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> AuthExpirationDUnitTest >
> newClient_registeredInterest_slowReAuth_policyNone_durableClient[10240.0.0]
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$756/0x0001007c6440.run
> in VM 0 running on Host
> heavy-lifter-4baf3206-8afb-569f-b74b-b22341f348ed.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.newClient_registeredInterest_slowReAuth_policyNone_durableClient(AuthExpirationDUnitTest.java:629)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.security.AuthExpirationDUnitTest that uses
> org.apache.geode.cache.Region
> Expected size: 100 but was: 95 in:
> ["key93",
>...
> "key55"] within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$newClient_registeredInterest_slowReAuth_policyNone_durableClient$bb17a952$2(AuthExpirationDUnitTest.java:631)
> Caused by:
> java.lang.AssertionError:
> Expected size: 100 but was: 95 in:
> ["key93",
>...
> "key55"]
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$17(AuthExpirationDUnitTest.java:632)
> 1502 tests completed, 1 failed, 110 skipped
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0526/test-results/upgradeTest/1632961901/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0526/test-artifacts/1632961901/upgradetestfiles-openjdk11-1.15.0-build.0526.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9664) Two different clients with the same durable id will both connect to the servers and receive messages
[
https://issues.apache.org/jira/browse/GEODE-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9664:
-
Labels: needsTriage (was: )
> Two different clients with the same durable id will both connect to the
> servers and receive messages
>
>
> Key: GEODE-9664
> URL: https://issues.apache.org/jira/browse/GEODE-9664
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Barrett Oglesby
>Priority: Major
> Labels: needsTriage
>
> There are two cases:
> # The number of queues is the same as the number of servers (e.g. client
> with subscription-redundancy=1 and 2 servers)
> # The number of queues is less than the number of servers (e.g. client with
> subscription-redundancy=0 and 2 servers)
> h2. Case 1
> In this case, the client first attempts to connect to the primary and fails.
> {noformat}
> [warn 2021/10/01 14:37:56.209 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal about to
> register
> clientProxyMembershipID=identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300])
> [warn 2021/10/01 14:37:56.209 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61581; primary=true; version=GEODE 1.15.0]
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal existing
> proxy isPaused=false
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] The requested durable client has the same identifier (
> client-a ) as an existing durable client (
> CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61581; primary=true; version=GEODE 1.15.0] ). Duplicate
> durable clients are not allowed.
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] CacheClientNotifier: Unsuccessfully registered client
> with identifier
> identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]) and response code 64
> {noformat}
> It then attempts to connect to the secondary and succeeds.
> {noformat}
> [warn 2021/10/01 14:37:56.215 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal about to
> register
> clientProxyMembershipID=identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300])
> [warn 2021/10/01 14:37:56.215 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61578; primary=false; version=GEODE 1.15.0]
> [warn 2021/10/01 14:37:56.216 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal existing
> proxy isPaused=true
> [warn 2021/10/01 14:37:56.217 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal
> reinitialized existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61578; primary=true; version=GEODE 1.15.0]
> {noformat}
> The previous secondary is reinitialized and made into a primary. Both queues
> will dispatch events.
> The CacheClientNotifier.registerClientInternal method invoked when a client
> connects does:
> {noformat}
> if (cacheClientProxy.isPaused()) {
> ...
> cacheClientProxy.reinitialize(...);
> } else {
> unsuccessfulMsg = String.format("The requested durable client has the same
> identifier ( %s ) as an existing durable client...);
> logger.warn(unsuccessfulMsg);
> }
> {noformat}
> The CacheClientProxy is paused when the durable client it represents has
> disconnected. Unfortunately, a secondary CacheClientProxy is also paused. So,
> this check is not good enough to prevent a duplicate durable client from
> connecting.
> There are a few things that can also be checked. One of them is:
> {noformat}
> cacheClientProxy.getCommBuffer() == null
> {noformat}
> With that check added, when the client attempts to connect to the secondary,
> it fails just like the it does with the primary.
> The
[jira] [Created] (GEODE-9664) Two different clients with the same durable id will both connect to the servers and receive messages
Barrett Oglesby created GEODE-9664:
--
Summary: Two different clients with the same durable id will both
connect to the servers and receive messages
Key: GEODE-9664
URL: https://issues.apache.org/jira/browse/GEODE-9664
Project: Geode
Issue Type: Bug
Components: client queues
Reporter: Barrett Oglesby
There are two cases:
# The number of queues is the same as the number of servers (e.g. client with
subscription-redundancy=1 and 2 servers)
# The number of queues is less than the number of servers (e.g. client with
subscription-redundancy=0 and 2 servers)
h2. Case 1
In this case, the client first attempts to connect to the primary and fails.
{noformat}
[warn 2021/10/01 14:37:56.209 PDT server-1 tid=0x4b] XXX CacheClientNotifier.registerClientInternal about to register
clientProxyMembershipID=identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
timeout=300])
[warn 2021/10/01 14:37:56.209 PDT server-1 tid=0x4b] XXX CacheClientNotifier.registerClientInternal existing
proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
timeout=300]); port=61581; primary=true; version=GEODE 1.15.0]
[warn 2021/10/01 14:37:56.210 PDT server-1 tid=0x4b] XXX CacheClientNotifier.registerClientInternal existing proxy
isPaused=false
[warn 2021/10/01 14:37:56.210 PDT server-1 tid=0x4b] The requested durable client has the same identifier ( client-a )
as an existing durable client (
CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
timeout=300]); port=61581; primary=true; version=GEODE 1.15.0] ). Duplicate
durable clients are not allowed.
[warn 2021/10/01 14:37:56.210 PDT server-1 tid=0x4b] CacheClientNotifier: Unsuccessfully registered client with
identifier
identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
timeout=300]) and response code 64
{noformat}
It then attempts to connect to the secondary and succeeds.
{noformat}
[warn 2021/10/01 14:37:56.215 PDT server-2 tid=0x47] XXX CacheClientNotifier.registerClientInternal about to register
clientProxyMembershipID=identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
timeout=300])
[warn 2021/10/01 14:37:56.215 PDT server-2 tid=0x47] XXX CacheClientNotifier.registerClientInternal existing
proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
timeout=300]); port=61578; primary=false; version=GEODE 1.15.0]
[warn 2021/10/01 14:37:56.216 PDT server-2 tid=0x47] XXX CacheClientNotifier.registerClientInternal existing proxy
isPaused=true
[warn 2021/10/01 14:37:56.217 PDT server-2 tid=0x47] XXX CacheClientNotifier.registerClientInternal reinitialized
existing
proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
timeout=300]); port=61578; primary=true; version=GEODE 1.15.0]
{noformat}
The previous secondary is reinitialized and made into a primary. Both queues
will dispatch events.
The CacheClientNotifier.registerClientInternal method invoked when a client
connects does:
{noformat}
if (cacheClientProxy.isPaused()) {
...
cacheClientProxy.reinitialize(...);
} else {
unsuccessfulMsg = String.format("The requested durable client has the same
identifier ( %s ) as an existing durable client...);
logger.warn(unsuccessfulMsg);
}
{noformat}
The CacheClientProxy is paused when the durable client it represents has
disconnected. Unfortunately, a secondary CacheClientProxy is also paused. So,
this check is not good enough to prevent a duplicate durable client from
connecting.
There are a few things that can also be checked. One of them is:
{noformat}
cacheClientProxy.getCommBuffer() == null
{noformat}
With that check added, when the client attempts to connect to the secondary, it
fails just like the it does with the primary.
The client then exits with this exception:
{noformat}
geode.cache.NoSubscriptionServersAvailableException:
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
initialize a primary queue on startup. No queue servers available.
at
org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:191)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:428)
at
[jira] [Updated] (GEODE-9663) throw and handle AuthenticationExpiredException at login time
[ https://issues.apache.org/jira/browse/GEODE-9663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9663: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > throw and handle AuthenticationExpiredException at login time > - > > Key: GEODE-9663 > URL: https://issues.apache.org/jira/browse/GEODE-9663 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > There is a time gap between credentials are gathered at the client and > credentials are examined on the server, if between this time period, > credentials expired (rare case, but it does happen a lot during stress tests, > see `AuthExpirationMultiServerDunitTest.consecutivePut` test), client > operations might fail during the operations (even after user is > authenticated, doing a put/get might need to open new connections and require > authentication again). So we should allow "authenticate" method also throw > AuthExpirationException if they want to give client a chance to retry (only > retry once). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9639) Make native client compatible with C++20
[ https://issues.apache.org/jira/browse/GEODE-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9639: -- Labels: pull-request-available (was: ) > Make native client compatible with C++20 > > > Key: GEODE-9639 > URL: https://issues.apache.org/jira/browse/GEODE-9639 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Matthew Reddington >Priority: Major > Labels: pull-request-available > > There are standard library components that were removed in C++20, making our > library incompatible. Luckily, our use of deleted components are minimal and > replaceable without breaking API backward compatibility, but it will disrupt > ABI compatibility. > > The outcome needs to be tested against MSVC2017/v141 and MSVC2019/v142, > including examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9639) Make native client compatible with C++20
[ https://issues.apache.org/jira/browse/GEODE-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423415#comment-17423415 ] ASF GitHub Bot commented on GEODE-9639: --- pivotal-jbarrett commented on pull request #874: URL: https://github.com/apache/geode-native/pull/874#issuecomment-932521201 @mreddington You will find them also in use in SerializationRegistry.hpp. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Make native client compatible with C++20 > > > Key: GEODE-9639 > URL: https://issues.apache.org/jira/browse/GEODE-9639 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Matthew Reddington >Priority: Major > > There are standard library components that were removed in C++20, making our > library incompatible. Luckily, our use of deleted components are minimal and > replaceable without breaking API backward compatibility, but it will disrupt > ABI compatibility. > > The outcome needs to be tested against MSVC2017/v141 and MSVC2019/v142, > including examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9662) CI Failure: acceptance-test-openjdk8 timed out
[ https://issues.apache.org/jira/browse/GEODE-9662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423391#comment-17423391 ] Geode Integration commented on GEODE-9662: -- Seen in [acceptance-test-openjdk8 #231.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/231.1] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0535/test-results/acceptanceTest/1633110480/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0535/test-artifacts/1633110480/acceptancetestfiles-openjdk8-1.15.0-build.0535.tgz]. > CI Failure: acceptance-test-openjdk8 timed out > -- > > Key: GEODE-9662 > URL: https://issues.apache.org/jira/browse/GEODE-9662 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Priority: Major > Labels: flaky-test, needsTriage > > this run of acceptance-test-openjdk8 timed out with a total duration of 3h5m. > The next one passed with a total duration of 3h1m. Is it possible that we > need to extend how much time we give acceptance tests to run? > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/229 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9663) throw and handle AuthenticationExpiredException at login time
[ https://issues.apache.org/jira/browse/GEODE-9663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9663: --- Labels: GeodeOperationAPI (was: ) > throw and handle AuthenticationExpiredException at login time > - > > Key: GEODE-9663 > URL: https://issues.apache.org/jira/browse/GEODE-9663 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > There is a time gap between credentials are gathered at the client and > credentials are examined on the server, if between this time period, > credentials expired (rare case, but it does happen a lot during stress tests, > see `AuthExpirationMultiServerDunitTest.consecutivePut` test), client > operations might fail during the operations (even after user is > authenticated, doing a put/get might need to open new connections and require > authentication again). So we should allow "authenticate" method also throw > AuthExpirationException if they want to give client a chance to retry (only > retry once). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9663) throw and handle AuthenticationExpiredException at login time
[ https://issues.apache.org/jira/browse/GEODE-9663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-9663: -- Assignee: Jinmei Liao > throw and handle AuthenticationExpiredException at login time > - > > Key: GEODE-9663 > URL: https://issues.apache.org/jira/browse/GEODE-9663 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > There is a time gap between credentials are gathered at the client and > credentials are examined on the server, if between this time period, > credentials expired (rare case, but it does happen a lot during stress tests, > see `AuthExpirationMultiServerDunitTest.consecutivePut` test), client > operations might fail during the operations (even after user is > authenticated, doing a put/get might need to open new connections and require > authentication again). So we should allow "authenticate" method also throw > AuthExpirationException if they want to give client a chance to retry (only > retry once). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9663) throw and handle AuthenticationExpiredException at login time
Jinmei Liao created GEODE-9663: -- Summary: throw and handle AuthenticationExpiredException at login time Key: GEODE-9663 URL: https://issues.apache.org/jira/browse/GEODE-9663 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao There is a time gap between credentials are gathered at the client and credentials are examined on the server, if between this time period, credentials expired (rare case, but it does happen a lot during stress tests, see `AuthExpirationMultiServerDunitTest.consecutivePut` test), client operations might fail during the operations (even after user is authenticated, doing a put/get might need to open new connections and require authentication again). So we should allow "authenticate" method also throw AuthExpirationException if they want to give client a chance to retry (only retry once). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9662) CI Failure: acceptance-test-openjdk8 timed out
[ https://issues.apache.org/jira/browse/GEODE-9662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423363#comment-17423363 ] Geode Integration commented on GEODE-9662: -- Seen in [acceptance-test-openjdk8 #229|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/229] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0534/test-results/acceptanceTest/1633051657/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0534/test-artifacts/1633051657/acceptancetestfiles-openjdk8-1.15.0-build.0534.tgz]. > CI Failure: acceptance-test-openjdk8 timed out > -- > > Key: GEODE-9662 > URL: https://issues.apache.org/jira/browse/GEODE-9662 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Priority: Major > Labels: flaky-test, needsTriage > > this run of acceptance-test-openjdk8 timed out with a total duration of 3h5m. > The next one passed with a total duration of 3h1m. Is it possible that we > need to extend how much time we give acceptance tests to run? > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/229 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9662) CI Failure: acceptance-test-openjdk8 timed out
Darrel Schneider created GEODE-9662: --- Summary: CI Failure: acceptance-test-openjdk8 timed out Key: GEODE-9662 URL: https://issues.apache.org/jira/browse/GEODE-9662 Project: Geode Issue Type: Bug Components: tests Reporter: Darrel Schneider this run of acceptance-test-openjdk8 timed out with a total duration of 3h5m. The next one passed with a total duration of 3h1m. Is it possible that we need to extend how much time we give acceptance tests to run? https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/229 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9662) CI Failure: acceptance-test-openjdk8 timed out
[ https://issues.apache.org/jira/browse/GEODE-9662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9662: - Labels: needsTriage (was: ) > CI Failure: acceptance-test-openjdk8 timed out > -- > > Key: GEODE-9662 > URL: https://issues.apache.org/jira/browse/GEODE-9662 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > this run of acceptance-test-openjdk8 timed out with a total duration of 3h5m. > The next one passed with a total duration of 3h1m. Is it possible that we > need to extend how much time we give acceptance tests to run? > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/229 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9662) CI Failure: acceptance-test-openjdk8 timed out
[ https://issues.apache.org/jira/browse/GEODE-9662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9662: Labels: flaky-test needsTriage (was: needsTriage) > CI Failure: acceptance-test-openjdk8 timed out > -- > > Key: GEODE-9662 > URL: https://issues.apache.org/jira/browse/GEODE-9662 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Priority: Major > Labels: flaky-test, needsTriage > > this run of acceptance-test-openjdk8 timed out with a total duration of 3h5m. > The next one passed with a total duration of 3h1m. Is it possible that we > need to extend how much time we give acceptance tests to run? > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/229 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9623) Implement the Redis command COMMAND
[ https://issues.apache.org/jira/browse/GEODE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9623. --- Fix Version/s: 1.15.0 Assignee: Jens Deppe Resolution: Fixed > Implement the Redis command COMMAND > --- > > Key: GEODE-9623 > URL: https://issues.apache.org/jira/browse/GEODE-9623 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the Redis command named [COMMAND|https://redis.io/commands/command]. > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9661) CI failure: SetRangeNativeRedisAcceptanceTest because native redis server went down
[ https://issues.apache.org/jira/browse/GEODE-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423356#comment-17423356 ] Geode Integration commented on GEODE-9661: -- Seen in [acceptance-test-openjdk8 #231|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/231] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0535/test-results/acceptanceTest/1633064687/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0535/test-artifacts/1633064687/acceptancetestfiles-openjdk8-1.15.0-build.0535.tgz]. > CI failure: SetRangeNativeRedisAcceptanceTest because native redis server > went down > --- > > Key: GEODE-9661 > URL: https://issues.apache.org/jira/browse/GEODE-9661 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > Labels: ci-failure, flaky > > Given that this is caused by a crash of the native redis server, this ticket > should not hold up a geode release. > SetRangeNativeRedisAcceptanceTest > setRange_replacesMiddle FAILED > redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The > cluster is down -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9661) CI failure: SetRangeNativeRedisAcceptanceTest because native redis server went down
Darrel Schneider created GEODE-9661: --- Summary: CI failure: SetRangeNativeRedisAcceptanceTest because native redis server went down Key: GEODE-9661 URL: https://issues.apache.org/jira/browse/GEODE-9661 Project: Geode Issue Type: Bug Components: redis Reporter: Darrel Schneider Given that this is caused by a crash of the native redis server, this ticket should not hold up a geode release. SetRangeNativeRedisAcceptanceTest > setRange_replacesMiddle FAILED redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The cluster is down -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9661) CI failure: SetRangeNativeRedisAcceptanceTest because native redis server went down
[ https://issues.apache.org/jira/browse/GEODE-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9661: - Labels: needsTriage (was: ) > CI failure: SetRangeNativeRedisAcceptanceTest because native redis server > went down > --- > > Key: GEODE-9661 > URL: https://issues.apache.org/jira/browse/GEODE-9661 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > Given that this is caused by a crash of the native redis server, this ticket > should not hold up a geode release. > SetRangeNativeRedisAcceptanceTest > setRange_replacesMiddle FAILED > redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The > cluster is down -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9661) CI failure: SetRangeNativeRedisAcceptanceTest because native redis server went down
[ https://issues.apache.org/jira/browse/GEODE-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9661: Labels: ci-failure flaky (was: needsTriage) > CI failure: SetRangeNativeRedisAcceptanceTest because native redis server > went down > --- > > Key: GEODE-9661 > URL: https://issues.apache.org/jira/browse/GEODE-9661 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > Labels: ci-failure, flaky > > Given that this is caused by a crash of the native redis server, this ticket > should not hold up a geode release. > SetRangeNativeRedisAcceptanceTest > setRange_replacesMiddle FAILED > redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The > cluster is down -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423351#comment-17423351
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#230|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/230].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423352#comment-17423352
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#231|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/231].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423354#comment-17423354
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#229|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/229].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423348#comment-17423348
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#234|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/234].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Commented] (GEODE-9658) CI Failure: AuthExpirationDUnitTest > newClient_registeredInterest_slowReAuth_policyNone_durableClient failed due to
[
https://issues.apache.org/jira/browse/GEODE-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423347#comment-17423347
]
Geode Integration commented on GEODE-9658:
--
Seen in [upgrade-test-openjdk8
#239|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/239]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0536/test-results/upgradeTest/1633103031/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0536/test-artifacts/1633103031/upgradetestfiles-openjdk8-1.15.0-build.0536.tgz].
> CI Failure: AuthExpirationDUnitTest >
> newClient_registeredInterest_slowReAuth_policyNone_durableClient failed due
> to
> -
>
> Key: GEODE-9658
> URL: https://issues.apache.org/jira/browse/GEODE-9658
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {noformat}
> AuthExpirationDUnitTest >
> newClient_registeredInterest_slowReAuth_policyNone_durableClient[10240.0.0]
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$756/0x0001007c6440.run
> in VM 0 running on Host
> heavy-lifter-4baf3206-8afb-569f-b74b-b22341f348ed.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.newClient_registeredInterest_slowReAuth_policyNone_durableClient(AuthExpirationDUnitTest.java:629)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.security.AuthExpirationDUnitTest that uses
> org.apache.geode.cache.Region
> Expected size: 100 but was: 95 in:
> ["key93",
>...
> "key55"] within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$newClient_registeredInterest_slowReAuth_policyNone_durableClient$bb17a952$2(AuthExpirationDUnitTest.java:631)
> Caused by:
> java.lang.AssertionError:
> Expected size: 100 but was: 95 in:
> ["key93",
>...
> "key55"]
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$17(AuthExpirationDUnitTest.java:632)
> 1502 tests completed, 1 failed, 110 skipped
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0526/test-results/upgradeTest/1632961901/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0526/test-artifacts/1632961901/upgradetestfiles-openjdk11-1.15.0-build.0526.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9660) ConcurrentLoopingThreads should not run action in case of thread exceptions
Jens Deppe created GEODE-9660: - Summary: ConcurrentLoopingThreads should not run action in case of thread exceptions Key: GEODE-9660 URL: https://issues.apache.org/jira/browse/GEODE-9660 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe This test class uses CyclicBarriers to implement an action that is performed at the end of every thread iteration. In the case where one of the threads produces an exception, the action is still performed. The semantics of this are different to CyclicBarriers and should really be the same. Also write some tests for this class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9650) Radish LOLWUT command
[ https://issues.apache.org/jira/browse/GEODE-9650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423290#comment-17423290 ] ASF subversion and git services commented on GEODE-9650: Commit 9c597afabe8eec1350feff2e06c29c2d7a192e75 in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9c597af ] GEODE-9650: LOLWUT command (#6908) This implements a version of the Redis LOLWUT command, which is supposed to (a) algorithmically generate computer art, and (b) output the program version. Optionally, the LOLWUT command can take arguments to affect the output. This implementation generates arbitrary-size mazes. By default, it generates a 40-cell-wide maze of height 10, but given arguments it can generate a valid maze of any width and height (up to 1Kx1M), while consuming a small and fixed amount of memory. Below the maze, it outputs the Geode version. Co-authored-by: Ray Ingles > Radish LOLWUT command > - > > Key: GEODE-9650 > URL: https://issues.apache.org/jira/browse/GEODE-9650 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the LOLWUT command, which allows command-line users to quickly > check the software version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9650) Radish LOLWUT command
[ https://issues.apache.org/jira/browse/GEODE-9650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Ingles reassigned GEODE-9650: - Assignee: Ray Ingles > Radish LOLWUT command > - > > Key: GEODE-9650 > URL: https://issues.apache.org/jira/browse/GEODE-9650 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > > Implement the LOLWUT command, which allows command-line users to quickly > check the software version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9650) Radish LOLWUT command
[ https://issues.apache.org/jira/browse/GEODE-9650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Ingles resolved GEODE-9650. --- Fix Version/s: 1.15.0 Resolution: Fixed > Radish LOLWUT command > - > > Key: GEODE-9650 > URL: https://issues.apache.org/jira/browse/GEODE-9650 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the LOLWUT command, which allows command-line users to quickly > check the software version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9569) Geode Native User Guide build script: allow docs to be retained
[ https://issues.apache.org/jira/browse/GEODE-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes resolved GEODE-9569. - Fix Version/s: 1.15.0 Resolution: Fixed > Geode Native User Guide build script: allow docs to be retained > --- > > Key: GEODE-9569 > URL: https://issues.apache.org/jira/browse/GEODE-9569 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Affects Versions: 1.13.4 >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The user guide build script allows the user to build and preview the > geode-native user guides. > A command-line option specifies whether the script generates the .NET or C++ > user guide. > When the script completes, it always deletes the generated guide. > Allow the user to keep the compiled guide. > Relevant files: > geode-native/docs/docker/preview-user-guide.sh > geode-native/docs/README.md -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9569) Geode Native User Guide build script: allow docs to be retained
[ https://issues.apache.org/jira/browse/GEODE-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423181#comment-17423181 ] ASF GitHub Bot commented on GEODE-9569: --- alb3rtobr merged pull request #873: URL: https://github.com/apache/geode-native/pull/873 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Geode Native User Guide build script: allow docs to be retained > --- > > Key: GEODE-9569 > URL: https://issues.apache.org/jira/browse/GEODE-9569 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Affects Versions: 1.13.4 >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > The user guide build script allows the user to build and preview the > geode-native user guides. > A command-line option specifies whether the script generates the .NET or C++ > user guide. > When the script completes, it always deletes the generated guide. > Allow the user to keep the compiled guide. > Relevant files: > geode-native/docs/docker/preview-user-guide.sh > geode-native/docs/README.md -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9569) Geode Native User Guide build script: allow docs to be retained
[ https://issues.apache.org/jira/browse/GEODE-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423180#comment-17423180 ] ASF subversion and git services commented on GEODE-9569: Commit d574f355092757fd9d53ebc6ffdce630e4e05a4e in geode-native's branch refs/heads/develop from Alberto Bustamante [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d574f35 ] GEODE-9569: Native client UG build script keeps doc after generating it (#873) > Geode Native User Guide build script: allow docs to be retained > --- > > Key: GEODE-9569 > URL: https://issues.apache.org/jira/browse/GEODE-9569 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Affects Versions: 1.13.4 >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > The user guide build script allows the user to build and preview the > geode-native user guides. > A command-line option specifies whether the script generates the .NET or C++ > user guide. > When the script completes, it always deletes the generated guide. > Allow the user to keep the compiled guide. > Relevant files: > geode-native/docs/docker/preview-user-guide.sh > geode-native/docs/README.md -- This message was sent by Atlassian Jira (v8.3.4#803005)
