[jira] [Commented] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406109#comment-17406109 ] Geode Integration commented on GEODE-9038: -- Seen in [distributed-test-openjdk8 #1401|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1401] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-results/distributedTest/1630121805/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0447/test-artifacts/1630121805/distributedtestfiles-openjdk8-1.15.0-build.0447.tgz]. > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Priority: Major > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting 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 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- 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=17406108#comment-17406108
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#149|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/149].
> 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-9369) Command to copy region entries from a WAN site to another.
[ https://issues.apache.org/jira/browse/GEODE-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406107#comment-17406107 ] Geode Integration commented on GEODE-9369: -- Seen in [windows-unit-test-openjdk11 #147|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/147] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0443/test-results/test/1630020537/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0443/test-artifacts/1630020537/windows-unittestfiles-openjdk11-1.15.0-build.0443.tgz]. > Command to copy region entries from a WAN site to another. > -- > > Key: GEODE-9369 > URL: https://issues.apache.org/jira/browse/GEODE-9369 > Project: Geode > Issue Type: New Feature > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > As described in RFC: > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN] > it is proposed to implement a command that copies the entries of a region in > a WAN site to the same region in another WAN site by using WAN replication. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (GEODE-6369) Cache-creation failure after a successful auto-reconnect causes subsequent NPE
[ https://issues.apache.org/jira/browse/GEODE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-6369: Comment: was deleted (was: Seen in [windows-unit-test-openjdk11 #147|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/147] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0443/test-results/test/1630020537/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0443/test-artifacts/1630020537/windows-unittestfiles-openjdk11-1.15.0-build.0443.tgz].) > Cache-creation failure after a successful auto-reconnect causes subsequent NPE > -- > > Key: GEODE-6369 > URL: https://issues.apache.org/jira/browse/GEODE-6369 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If your server auto-reconnects but there is a problem recreating the cache > the JGroups channel used for auto-reconnect is closed. This causes an NPE > when the server makes another auto-reconnect attempt. > The server should instead just log the problem and shut down since future > attempts to recreate the cache will probably run into the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (GEODE-6369) Cache-creation failure after a successful auto-reconnect causes subsequent NPE
[ https://issues.apache.org/jira/browse/GEODE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-6369: Comment: was deleted (was: Seen in [windows-unit-test-openjdk8 #146|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/146] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0442/test-results/test/1630014649/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0442/test-artifacts/1630014649/windows-unittestfiles-openjdk8-1.15.0-build.0442.tgz].) > Cache-creation failure after a successful auto-reconnect causes subsequent NPE > -- > > Key: GEODE-6369 > URL: https://issues.apache.org/jira/browse/GEODE-6369 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If your server auto-reconnects but there is a problem recreating the cache > the JGroups channel used for auto-reconnect is closed. This causes an NPE > when the server makes another auto-reconnect attempt. > The server should instead just log the problem and shut down since future > attempts to recreate the cache will probably run into the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9369) Command to copy region entries from a WAN site to another.
[ https://issues.apache.org/jira/browse/GEODE-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406105#comment-17406105 ] Geode Integration commented on GEODE-9369: -- Seen in [windows-unit-test-openjdk8 #146|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/146] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0442/test-results/test/1630014649/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0442/test-artifacts/1630014649/windows-unittestfiles-openjdk8-1.15.0-build.0442.tgz]. > Command to copy region entries from a WAN site to another. > -- > > Key: GEODE-9369 > URL: https://issues.apache.org/jira/browse/GEODE-9369 > Project: Geode > Issue Type: New Feature > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > As described in RFC: > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN] > it is proposed to implement a command that copies the entries of a region in > a WAN site to the same region in another WAN site by using WAN replication. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7118) RestartOfMemberDistributedTest fails intermittently in precheckin
[
https://issues.apache.org/jira/browse/GEODE-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406069#comment-17406069
]
Donal Evans commented on GEODE-7118:
Seen in again in pre-checkin. The new failure has a BindExcecption as its root
cause:
{noformat}
org.apache.geode.distributed.internal.RestartOfMemberDistributedTest >
exCoordinatorJoiningQuorumDoesNotThrowNullPointerException FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 0 running
on Host
heavy-lifter-e197991b-47bf-528a-8c69-a97472205f83.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:461)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startLocatorVM(ClusterStartupRule.java:227)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.startLocatorVM(ClusterStartupRule.java:209)
at
org.apache.geode.distributed.internal.RestartOfMemberDistributedTest.exCoordinatorJoiningQuorumDoesNotThrowNullPointerException(RestartOfMemberDistributedTest.java:70)
Caused by:
java.io.UncheckedIOException: java.net.BindException: Failed to create
server socket on 10.0.0.83[41799]
at
org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:95)
at
org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:74)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$a061f02f$1(ClusterStartupRule.java:238)
at
org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:829)Caused by:
java.net.BindException: Failed to create server socket on
10.0.0.83[41799]
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
at
org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:48)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:193)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
at
org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
at
org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:653)
at
[jira] [Assigned] (GEODE-9482) Radish commands do not match Redis error behaviour for integer arguments beginning "-0" and "+"
[
https://issues.apache.org/jira/browse/GEODE-9482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-9482:
---
Assignee: Darrel Schneider
> Radish commands do not match Redis error behaviour for integer arguments
> beginning "-0" and "+"
> ---
>
> Key: GEODE-9482
> URL: https://issues.apache.org/jira/browse/GEODE-9482
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Darrel Schneider
>Priority: Major
>
> When using native Redis, commands that take integer arguments return {{"ERR
> value is not an integer or out of range"}} if the argument begins with "-0"
> or "+". The current implementation of these commands in Geode does not behave
> the same way.
> The {{Coder.bytesToLong()}} method should be modified to check for the first
> two characters being "-0" or "+" and throw a {{NumberFormatException}} if
> that is the case. Alternately, if there are places where we want to preserve
> the existing behaviour of {{Coder.bytesToLong()}}, an additional
> {{bytesToLongStrict()}} method could be added to the {{Coder}} class with
> this additional check.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9555) the redis commands that increment or decrement using a long do an extra conversion
[ https://issues.apache.org/jira/browse/GEODE-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406055#comment-17406055 ] ASF subversion and git services commented on GEODE-9555: Commit 39e74135ca62817293e61b6c4cbdc538e0fb4ffb in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=39e7413 ] GEODE-9555: optimize incr/decr results (#6778) RedisString and RedisHash incr/decr ops now return byte[] instead of long saving an extra conversion. > the redis commands that increment or decrement using a long do an extra > conversion > -- > > Key: GEODE-9555 > URL: https://issues.apache.org/jira/browse/GEODE-9555 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The redis commands that increment or decrement using a long end up storing > the new value in the RedisData instance as an ascii byte array. They are also > required to return that value to the client. When geode's implementation > returns the value, it currently does so as a "long" instead of as a "byte[]". > This forces the code later on to call Coder.longToBytes again. Since we > already have it in the correct form we should return that to the caller so > that it can just copy the bytes instead of needing to compute them again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9555) the redis commands that increment or decrement using a long do an extra conversion
[ https://issues.apache.org/jira/browse/GEODE-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9555. - Fix Version/s: 1.15.0 Resolution: Fixed > the redis commands that increment or decrement using a long do an extra > conversion > -- > > Key: GEODE-9555 > URL: https://issues.apache.org/jira/browse/GEODE-9555 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The redis commands that increment or decrement using a long end up storing > the new value in the RedisData instance as an ascii byte array. They are also > required to return that value to the client. When geode's implementation > returns the value, it currently does so as a "long" instead of as a "byte[]". > This forces the code later on to call Coder.longToBytes again. Since we > already have it in the correct form we should return that to the caller so > that it can just copy the bytes instead of needing to compute them again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9555) the redis commands that increment or decrement using a long do an extra conversion
[ https://issues.apache.org/jira/browse/GEODE-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9555: -- Labels: pull-request-available (was: ) > the redis commands that increment or decrement using a long do an extra > conversion > -- > > Key: GEODE-9555 > URL: https://issues.apache.org/jira/browse/GEODE-9555 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > The redis commands that increment or decrement using a long end up storing > the new value in the RedisData instance as an ascii byte array. They are also > required to return that value to the client. When geode's implementation > returns the value, it currently does so as a "long" instead of as a "byte[]". > This forces the code later on to call Coder.longToBytes again. Since we > already have it in the correct form we should return that to the caller so > that it can just copy the bytes instead of needing to compute them again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9532) CI Failure: DiskDistributedNoAckAsyncRegionDUnitTest > testNoDataSerializer fails with NotSerializableException
[
https://issues.apache.org/jira/browse/GEODE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406040#comment-17406040
]
ASF subversion and git services commented on GEODE-9532:
Commit 10abff6cb6722a56b03305251076c9c78e948dd3 in geode's branch
refs/heads/develop from Jianxia Chen
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=10abff6 ]
GEODE-9532: Register LongWrapperSerializer before Region.put() (#6799)
> CI Failure: DiskDistributedNoAckAsyncRegionDUnitTest > testNoDataSerializer
> fails with NotSerializableException
> ---
>
> Key: GEODE-9532
> URL: https://issues.apache.org/jira/browse/GEODE-9532
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {noformat}
> org.apache.geode.cache30.DiskDistributedNoAckAsyncRegionDUnitTest >
> testNoDataSerializer 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 570
> [fatal 2021/06/15 17:11:03.722 GMT DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer> tid=2145]
> Fatal error from asynchronous flusher thread
> org.apache.geode.SerializationException: An IOException was thrown while
> serializing.
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2105)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2088)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getSerializedValue(VMCachedDeserializable.java:200)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.createValueWrapper(DiskEntry.java:753)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.createValueWrapperFromEntry(DiskEntry.java:807)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeToDisk(DiskEntry.java:825)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeToDisk(DiskEntry.java:815)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeEntryToDisk(DiskEntry.java:1493)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.doAsyncFlush(DiskEntry.java:1445)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.doAsyncFlush(DiskStoreImpl.java:1765)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.run(DiskStoreImpl.java:1723)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.NotSerializableException:
> org.apache.geode.cache30.MultiVMRegionTestCase$LongWrapper
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at
> org.apache.geode.internal.InternalDataSerializer.writeSerializableObject(InternalDataSerializer.java:2186)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2055)
> at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.util.BlobHelper.serializeToBlob(BlobHelper.java:54)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2103)
> ... 11 more
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 594
> [error 2021/06/15 17:11:03.734 GMT DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer> tid=2145] A
> DiskAccessException has occurred while writing to the disk for disk store
> DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer. The cache will
> be closed.
> org.apache.geode.cache.DiskAccessException: For DiskStore:
> DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer: Fatal error
> from asynchronous flusher thread, caused by
> org.apache.geode.SerializationException: An IOException was thrown while
> serializing.
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.doAsyncFlush(DiskStoreImpl.java:1809)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.run(DiskStoreImpl.java:1723)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.geode.SerializationException: An IOException was
> thrown while serializing.
> at
>
[jira] [Updated] (GEODE-9532) CI Failure: DiskDistributedNoAckAsyncRegionDUnitTest > testNoDataSerializer fails with NotSerializableException
[
https://issues.apache.org/jira/browse/GEODE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9532:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> CI Failure: DiskDistributedNoAckAsyncRegionDUnitTest > testNoDataSerializer
> fails with NotSerializableException
> ---
>
> Key: GEODE-9532
> URL: https://issues.apache.org/jira/browse/GEODE-9532
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {noformat}
> org.apache.geode.cache30.DiskDistributedNoAckAsyncRegionDUnitTest >
> testNoDataSerializer 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 570
> [fatal 2021/06/15 17:11:03.722 GMT DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer> tid=2145]
> Fatal error from asynchronous flusher thread
> org.apache.geode.SerializationException: An IOException was thrown while
> serializing.
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2105)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2088)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getSerializedValue(VMCachedDeserializable.java:200)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.createValueWrapper(DiskEntry.java:753)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.createValueWrapperFromEntry(DiskEntry.java:807)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeToDisk(DiskEntry.java:825)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeToDisk(DiskEntry.java:815)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeEntryToDisk(DiskEntry.java:1493)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.doAsyncFlush(DiskEntry.java:1445)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.doAsyncFlush(DiskStoreImpl.java:1765)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.run(DiskStoreImpl.java:1723)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.NotSerializableException:
> org.apache.geode.cache30.MultiVMRegionTestCase$LongWrapper
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at
> org.apache.geode.internal.InternalDataSerializer.writeSerializableObject(InternalDataSerializer.java:2186)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2055)
> at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.util.BlobHelper.serializeToBlob(BlobHelper.java:54)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2103)
> ... 11 more
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 594
> [error 2021/06/15 17:11:03.734 GMT DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer> tid=2145] A
> DiskAccessException has occurred while writing to the disk for disk store
> DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer. The cache will
> be closed.
> org.apache.geode.cache.DiskAccessException: For DiskStore:
> DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer: Fatal error
> from asynchronous flusher thread, caused by
> org.apache.geode.SerializationException: An IOException was thrown while
> serializing.
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.doAsyncFlush(DiskStoreImpl.java:1809)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.run(DiskStoreImpl.java:1723)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.geode.SerializationException: An IOException was
> thrown while serializing.
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2105)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2088)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getSerializedValue(VMCachedDeserializable.java:200)
> at
>
[jira] [Commented] (GEODE-9369) Command to copy region entries from a WAN site to another.
[ https://issues.apache.org/jira/browse/GEODE-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406021#comment-17406021 ] ASF subversion and git services commented on GEODE-9369: Commit 48f3e620b86df5e0cdd5fc8b5389da0297bb3b15 in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=48f3e62 ] Revert "GEODE-9369: Command to copy region entries from a WAN site to another (#6601)" (#6811) This reverts commit c9d465b1e77dbc7bcc87eaea3522029530bb2b2b. > Command to copy region entries from a WAN site to another. > -- > > Key: GEODE-9369 > URL: https://issues.apache.org/jira/browse/GEODE-9369 > Project: Geode > Issue Type: New Feature > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > As described in RFC: > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN] > it is proposed to implement a command that copies the entries of a region in > a WAN site to the same region in another WAN site by using WAN replication. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9551) New SNI proxy API does not conform to standards.
[
https://issues.apache.org/jira/browse/GEODE-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405990#comment-17405990
]
ASF subversion and git services commented on GEODE-9551:
Commit 4ccd5f7d5f37728b83798b4ec2b5e7532bafc7b0 in geode-native's branch
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=4ccd5f7 ]
GEODE-9551: Fixes API return and parameter types. (#860)
> New SNI proxy API does not conform to standards.
>
>
> Key: GEODE-9551
> URL: https://issues.apache.org/jira/browse/GEODE-9551
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>
> APIs should be consistent with other APIs:
> All class/struct properties should be returned {{const &}} in getters and
> copied in setters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9551) New SNI proxy API does not conform to standards.
[
https://issues.apache.org/jira/browse/GEODE-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9551:
--
Labels: pull-request-available (was: )
> New SNI proxy API does not conform to standards.
>
>
> Key: GEODE-9551
> URL: https://issues.apache.org/jira/browse/GEODE-9551
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> APIs should be consistent with other APIs:
> All class/struct properties should be returned {{const &}} in getters and
> copied in setters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9551) New SNI proxy API does not conform to standards.
[
https://issues.apache.org/jira/browse/GEODE-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405991#comment-17405991
]
ASF GitHub Bot commented on GEODE-9551:
---
pdxcodemonkey merged pull request #860:
URL: https://github.com/apache/geode-native/pull/860
--
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
> New SNI proxy API does not conform to standards.
>
>
> Key: GEODE-9551
> URL: https://issues.apache.org/jira/browse/GEODE-9551
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>
> APIs should be consistent with other APIs:
> All class/struct properties should be returned {{const &}} in getters and
> copied in setters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9453) The server, once a user expires, should clean the user attributes from the server.
[ https://issues.apache.org/jira/browse/GEODE-9453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9453: --- Description: ClientUserAuths maintains a map of clientID to its user attributes (the logged in shiro subject etc), when user expires, we need to remove that entry from that map and log the shiro subject out to avoid resource leak. add all appropriate tests (unit, integration and dunit) The test should cover multi-server scenario, and make sure the expired subject entry is cleared in the map. was: ClientUserAuths maintains a map of clientID to its user attributes (the logged in shiro subject etc), when user expires, we need to remove that entry from that map and log the shiro subject out to avoid resource leak. make sure to include tests in multi-server cases > The server, once a user expires, should clean the user attributes from the > server. > -- > > Key: GEODE-9453 > URL: https://issues.apache.org/jira/browse/GEODE-9453 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > ClientUserAuths maintains a map of clientID to its user attributes (the > logged in shiro subject etc), when user expires, we need to remove that entry > from that map and log the shiro subject out to avoid resource leak. > > add all appropriate tests (unit, integration and dunit) > The test should cover multi-server scenario, and make sure the expired > subject entry is cleared in the map. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9458) Add tests for functions executions on servers when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9458: --- Description: The test should spin up multiple servers and test the functionService from the client: # function execution onServer/onMember # function execution onServers/onMembers # function execution onRegion and make sure the expired user would re-authenticate and continue to execute the functions in various cases and make sure the the subsequent successful function execution is done by the new user (not the expired one). test onServer, onServers, onRegions was: and make sure the behavior matches expectation. make sure to include tests in multi-server cases test onServer, onServers, onRegions > Add tests for functions executions on servers when authentication expires > - > > Key: GEODE-9458 > URL: https://issues.apache.org/jira/browse/GEODE-9458 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The test should spin up multiple servers and test the functionService from > the client: > # function execution onServer/onMember > # function execution onServers/onMembers > # function execution onRegion > and make sure the expired user would re-authenticate and continue to execute > the functions in various cases > and make sure the the subsequent successful function execution is done by the > new user (not the expired one). > > test onServer, onServers, onRegions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9521) Add test to cover multi-servers scenario for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9521: --- Description: The test should should spin up multiple servers and test: # client connect to one server directly # client connect to the locator and have locator allocate server connection of the client the test should check: # expiring users on all the servers would prevent client connect to the all the server. # on the same client, after it's connected and the user is expired, make sure no further operation will be allowed by this user (expired) even if the client's connection is re-directed to the other server. > Add test to cover multi-servers scenario for re-authentication > -- > > Key: GEODE-9521 > URL: https://issues.apache.org/jira/browse/GEODE-9521 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, security > Fix For: 1.15.0 > > > The test should should spin up multiple servers and test: > # client connect to one server directly > # client connect to the locator and have locator allocate server connection > of the client > the test should check: > # expiring users on all the servers would prevent client connect to the all > the server. > # on the same client, after it's connected and the user is expired, make > sure no further operation will be allowed by this user (expired) even if the > client's connection is re-directed to the other server. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-9521) Add test to cover multi-servers scenario for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reopened GEODE-9521: add more test to cover "client connects to locator" > Add test to cover multi-servers scenario for re-authentication > -- > > Key: GEODE-9521 > URL: https://issues.apache.org/jira/browse/GEODE-9521 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, security > Fix For: 1.15.0 > > > The test should should spin up multiple servers and test: > # client connect to one server directly > # client connect to the locator and have locator allocate server connection > of the client > the test should check: > # expiring users on all the servers would prevent client connect to the all > the server. > # on the same client, after it's connected and the user is expired, make > sure no further operation will be allowed by this user (expired) even if the > client's connection is re-directed to the other server. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9451) On demand authentication expiration and re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9451: --- Description: This is to implement the feature proposed in this RFC https://cwiki.apache.org/confluence/display/GEODE/On+Demand+Geode+Authentication+Expiration+and+Re-authentication > On demand authentication expiration and re-authentication > - > > Key: GEODE-9451 > URL: https://issues.apache.org/jira/browse/GEODE-9451 > Project: Geode > Issue Type: New Feature > Components: core, security >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > This is to implement the feature proposed in this RFC > https://cwiki.apache.org/confluence/display/GEODE/On+Demand+Geode+Authentication+Expiration+and+Re-authentication -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9452) The older version client should receive the AuthenticationRequiredException when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9452: --- Description: Currently, for older client, it's receiving a ClassNotFoundException, we need to add the serialization code to convert the AuthenticationExpiredException into this old exception type(AuthenticationRequiredException) that the older clients can understand. Note: when converting the exception, if we have the message to match what the older client expects, it can do re-authentication automatically, but we lost the original message that server has thrown. was: Currently, for older client, it's receiving a ClassNotFoundException, we need to add the serialization code to convert the AuthenticationExpiredException into this old exception type that the older clients can understand. Note: when converting the exception, if we have the message to match what the older client expects, it can do re-authentication automatically, but we lost the original message that server has thrown. (Need to consult the PM on what kind of behavior they want). > The older version client should receive the AuthenticationRequiredException > when authentication expires > --- > > Key: GEODE-9452 > URL: https://issues.apache.org/jira/browse/GEODE-9452 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.15.0 > > > Currently, for older client, it's receiving a ClassNotFoundException, we need > to add the serialization code to convert the AuthenticationExpiredException > into this old exception type(AuthenticationRequiredException) that the older > clients can understand. > > Note: when converting the exception, if we have the message to match what the > older client expects, it can do re-authentication automatically, but we lost > the original message that server has thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9456) Create AuthenticationExpiredException and have the client handle that exception for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9456: --- Description: Current: Geode doesn't support any credential expiration Desired: Optionally upon every authorization, Geode would check if the credential has expired or not, if AuthenticationExpiredException is thrown by the SecurityManager, Geode would throw the exception to the client. And the client, after receiving the exception, would call "authInitialize" to get a new set of credentials and try re-authenticating again. It should only try this once. was: Create AuthenticationExpiredException and have the client handle that exception for re-authentication > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > - > > Key: GEODE-9456 > URL: https://issues.apache.org/jira/browse/GEODE-9456 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > Current: Geode doesn't support any credential expiration > Desired: Optionally upon every authorization, Geode would check if the > credential has expired or not, if AuthenticationExpiredException is thrown by > the SecurityManager, Geode would throw the exception to the client. And the > client, after receiving the exception, would call "authInitialize" to get a > new set of credentials and try re-authenticating again. It should only try > this once. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9458) Add tests for functions executions on servers when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-9458: -- Assignee: Joris Melchior > Add tests for functions executions on servers when authentication expires > - > > Key: GEODE-9458 > URL: https://issues.apache.org/jira/browse/GEODE-9458 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > and make sure the behavior matches expectation. > > make sure to include tests in multi-server cases > > test onServer, onServers, onRegions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9452) The older version client should receive the AuthenticationRequiredException when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9452. Fix Version/s: 1.15.0 Resolution: Fixed > The older version client should receive the AuthenticationRequiredException > when authentication expires > --- > > Key: GEODE-9452 > URL: https://issues.apache.org/jira/browse/GEODE-9452 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.15.0 > > > Currently, for older client, it's receiving a ClassNotFoundException, we need > to add the serialization code to convert the AuthenticationExpiredException > into this old exception type that the older clients can understand. > > Note: when converting the exception, if we have the message to match what the > older client expects, it can do re-authentication automatically, but we lost > the original message that server has thrown. (Need to consult the PM on what > kind of behavior they want). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9521) Add test to cover multi-servers scenario for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9521. Fix Version/s: 1.15.0 Resolution: Fixed > Add test to cover multi-servers scenario for re-authentication > -- > > Key: GEODE-9521 > URL: https://issues.apache.org/jira/browse/GEODE-9521 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, security > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9456) Create AuthenticationExpiredException and have the client handle that exception for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9456. Fix Version/s: 1.15.0 Resolution: Fixed > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > - > > Key: GEODE-9456 > URL: https://issues.apache.org/jira/browse/GEODE-9456 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8326) CI Failure: FixedPartitioningWithTransactionDistributedTest.clientCanRollbackFunctionOnRegionWithoutFilterAndWithSingleHopEnabled times out waiting for client metadata
[
https://issues.apache.org/jira/browse/GEODE-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-8326.
-
Fix Version/s: 1.13.0
Resolution: Fixed
> CI Failure:
> FixedPartitioningWithTransactionDistributedTest.clientCanRollbackFunctionOnRegionWithoutFilterAndWithSingleHopEnabled
> times out waiting for client metadata
> ---
>
> Key: GEODE-8326
> URL: https://issues.apache.org/jira/browse/GEODE-8326
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Eric Shu
>Priority: Major
> Labels: caching-applications
> Fix For: 1.13.0
>
>
> CI Failure:
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.0-build.0296/test-results/distributedTest/1592846714/
> {noformat}
> org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningWithTransactionDistributedTest
> >
> clientCanRollbackFunctionOnRegionWithoutFilterAndWithSingleHopEnabled[ExecuteFunctionByObject]
> FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in
> org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningWithTransactionDistributedTest
> that uses org.apache.geode.cache.client.internal.ClientMetadataService was
> not fulfilled within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningWithTransactionDistributedTest.forceClientMetadataUpdate(FixedPartitioningWithTransactionDistributedTest.java:241)
> at
> org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningWithTransactionDistributedTest.doFunctionTransactionAndSuspend(FixedPartitioningWithTransactionDistributedTest.java:458)
> at
> org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningWithTransactionDistributedTest.clientCanRollbackFunctionOnRegionWithoutFilterAndWithSingleHopEnabled(FixedPartitioningWithTransactionDistributedTest.java:254)
> {noformat}
> The failure occurs after waiting 5 minutes for the ClientMetadataService to
> stabilize. See ClientMetadataService#isMetadataStable.
> The timeout occurs within a block of test code that was introduced by Jake in
> PR #3840:
> {noformat}
> GEODE-7006: Fixes function execution by id with transactions. (#3840)
> * Fixes test to force and wait for PR metadata to update.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9558) State in the documentation that function executions do not honor the conserve-sockets setting
Alberto Gomez created GEODE-9558: Summary: State in the documentation that function executions do not honor the conserve-sockets setting Key: GEODE-9558 URL: https://issues.apache.org/jira/browse/GEODE-9558 Project: Geode Issue Type: Bug Components: docs Reporter: Alberto Gomez According to [https://community.pivotal.io/s/article/GemFire-Function-Executions-and-conserve-sockets-behavior?language=en_US:] "even with conserve-sockets set to false, function executions do not use this setting and defaults to conserve-sockets=true behavior, regardless of the conserve-sockets setting. And according to: [https://medium.com/swlh/threads-used-in-apache-geode-function-execution-9dd707cf227c#bd8c] "a Function Execution Processor does not honor the conserve-sockets setting so a shared P2P message reader is used in the remote server" This information is not present in the current Geode documentation when describing the conserve-sockets property. This information must be added together with the information on how to set conserve-sockets in function executions (see the first link above). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9557) Consistenly state in the documentation the situations where conserve-sockets should not be set to true
[ https://issues.apache.org/jira/browse/GEODE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-9557: - Description: According to the current Geode documentation, in order to avoid hangs or distributed locks, it is not recommended to set conserve-sockets to true under the following conditions: * "When you have transactions operating on EMPTY, NORMAL or PARTITION regions, make sure that `conserve-sockets` is set to false to avoid distributed deadlocks." (see geode-docs/managing/monitor_tune/performance_controls_controlling_socket_use.html.md.erb). * On members that participate in a WAN deployment: "To avoid hangs related to WAN messaging, always use the default setting of conserve-sockets=false for <%=vars.product_name%> members that participate in a WAN deployment." (see geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb, geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb and geode-docs/reference/topics/gemfire_properties.html.md.erb) The following Geode documentation files have references to the conserve-sockets property: * geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb * geode-docs/managing/monitor_tune/slow_messages.html.md.erb * geode-docs/managing/monitor_tune/performance_controls_controlling_socket_use.html.md.erb * geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb * geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb * geode-docs/managing/logging/logging_categories.html.md.erb * geode-docs/basic_config/gemfire_properties/setting_distributed_properties.html.md.erb * geode-docs/configuring/running/firewalls_ports.html.md.erb * geode-docs/developing/events/how_cache_events_work.html.md.erb * geode-docs/reference/topics/memory_requirements_for_cache_data.html.md.erb * geode-docs/reference/topics/gemfire_properties.html.md.erb The situations where conserve-sockets should not be set to true must be described together (in the same place) and not in different documentation pages in order to avoid someone missing one of them for not reading all the documentation pages. Also, it would be desirable that the situations are described in just one documentation page to avoid duplication and future documentation consistency problems and have the rest of pages mentioning conserve-sockets refer to that page containing the full details of the property. was: According to the current Geode documentation in order to avoid hangs or distributed locks, it is not recommended to set conserve-sockets to false under the following conditions: * "When you have transactions operating on EMPTY, NORMAL or PARTITION regions" (see geode-docs/managing/monitor_tune/performance_controls_controlling_socket_use.html.md.erb). * On members that participate in a WAN deployment: "To avoid hangs related to WAN messaging, always use the default setting of conserve-sockets=false for <%=vars.product_name%> members that participate in a WAN deployment." (see geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb, geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb and geode-docs/reference/topics/gemfire_properties.html.md.erb) The following Geode documentation files have references to the conserve-sockets property: * geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb * geode-docs/managing/monitor_tune/slow_messages.html.md.erb * geode-docs/managing/monitor_tune/performance_controls_controlling_socket_use.html.md.erb * geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb * geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb * geode-docs/managing/logging/logging_categories.html.md.erb * geode-docs/basic_config/gemfire_properties/setting_distributed_properties.html.md.erb * geode-docs/configuring/running/firewalls_ports.html.md.erb * geode-docs/developing/events/how_cache_events_work.html.md.erb * geode-docs/reference/topics/memory_requirements_for_cache_data.html.md.erb * geode-docs/reference/topics/gemfire_properties.html.md.erb The situations where conserve-sockets should not be set to true must be described together (in the same place) and not in different documentation pages in order to avoid someone missing one of them for not reading all the documentation pages. Also, it would be desirable that the situations are described in just one documentation page to avoid duplication and future documentation consistency problems and have other the rest of pages mentioning conserve-sockets refer to the first page containing the full details of the property. > Consistenly state in the documentation the situations where conserve-sockets > should not be set to true >
[jira] [Created] (GEODE-9557) Consistenly state in the documentation the situations where conserve-sockets should not be set to true
Alberto Gomez created GEODE-9557: Summary: Consistenly state in the documentation the situations where conserve-sockets should not be set to true Key: GEODE-9557 URL: https://issues.apache.org/jira/browse/GEODE-9557 Project: Geode Issue Type: Improvement Components: docs Reporter: Alberto Gomez According to the current Geode documentation in order to avoid hangs or distributed locks, it is not recommended to set conserve-sockets to false under the following conditions: * "When you have transactions operating on EMPTY, NORMAL or PARTITION regions" (see geode-docs/managing/monitor_tune/performance_controls_controlling_socket_use.html.md.erb). * On members that participate in a WAN deployment: "To avoid hangs related to WAN messaging, always use the default setting of conserve-sockets=false for <%=vars.product_name%> members that participate in a WAN deployment." (see geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb, geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb and geode-docs/reference/topics/gemfire_properties.html.md.erb) The following Geode documentation files have references to the conserve-sockets property: * geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb * geode-docs/managing/monitor_tune/slow_messages.html.md.erb * geode-docs/managing/monitor_tune/performance_controls_controlling_socket_use.html.md.erb * geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb * geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb * geode-docs/managing/logging/logging_categories.html.md.erb * geode-docs/basic_config/gemfire_properties/setting_distributed_properties.html.md.erb * geode-docs/configuring/running/firewalls_ports.html.md.erb * geode-docs/developing/events/how_cache_events_work.html.md.erb * geode-docs/reference/topics/memory_requirements_for_cache_data.html.md.erb * geode-docs/reference/topics/gemfire_properties.html.md.erb The situations where conserve-sockets should not be set to true must be described together (in the same place) and not in different documentation pages in order to avoid someone missing one of them for not reading all the documentation pages. Also, it would be desirable that the situations are described in just one documentation page to avoid duplication and future documentation consistency problems and have other the rest of pages mentioning conserve-sockets refer to the first page containing the full details of the property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7460) CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs ForcedDisconnectException Failure
[ https://issues.apache.org/jira/browse/GEODE-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7460: Fix Version/s: (was: 1.15.0) (was: 1.14.0) > CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs > ForcedDisconnectException Failure > --- > > Key: GEODE-7460 > URL: https://issues.apache.org/jira/browse/GEODE-7460 > Project: Geode > Issue Type: Bug > Components: membership >Affects Versions: 1.13.0, 1.14.0 >Reporter: Robert Houghton >Assignee: Bill Burcham >Priority: Major > Fix For: 1.12.3, 1.13.3 > > Time Spent: 20m > Remaining Estimate: 0h > > From the failing job: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-results/distributedTest/1573784422/ > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-artifacts/1573784422/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0016.tgz > DistributedTest failure due to exception: > org.apache.geode.distributed.DistributedMemberDUnitTest > testGroupsInAllVMs > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.distributed.DistributedMemberDUnitTest$6.run in VM 0 running > on Host 3e09f1029b44 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579) > at org.apache.geode.test.dunit.VM.invoke(VM.java:406) > at > org.apache.geode.distributed.DistributedMemberDUnitTest.testGroupsInAllVMs(DistributedMemberDUnitTest.java:333) > Caused by: > org.apache.geode.SystemConnectException: One or more peers generated > exceptions during connection attempt > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1625) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:354) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:759) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:136) > at > org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3009) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:269) > at > org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:181) > at > org.apache.geode.distributed.DistributedMemberDUnitTest$6.run(DistributedMemberDUnitTest.java:339) > Caused by: > > org.apache.geode.distributed.DistributedSystemDisconnectedException: > DistributedSystem is shutting down, caused by > org.apache.geode.ForcedDisconnectException: Exiting due to possible network > partition event due to loss of 1 cache processes: > [172.17.0.14(myName:1):41001] > at > org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1591) > at > org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.send(GMSMembershipManager.java:1751) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1985) > at > org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:74) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1622) > ... 8 more > Caused by: > org.apache.geode.ForcedDisconnectException: Exiting due to > possible network partition event due to loss of 1 cache processes: > [172.17.0.14(myName:1):41001] > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect
[jira] [Updated] (GEODE-8173) Add test coverage for PartitionedRegionClear class
[ https://issues.apache.org/jira/browse/GEODE-8173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8173: Fix Version/s: (was: 1.14.0) > Add test coverage for PartitionedRegionClear class > -- > > Key: GEODE-8173 > URL: https://issues.apache.org/jira/browse/GEODE-8173 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI > > Add test coverage for PartitionedRegionClear class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9069) CI Failure: org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest > testConcurrentHExists_whileAddingValues FAILED
[
https://issues.apache.org/jira/browse/GEODE-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9069:
Fix Version/s: 1.14.0
> CI Failure: org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest >
> testConcurrentHExists_whileAddingValues FAILED
> ---
>
> Key: GEODE-9069
> URL: https://issues.apache.org/jira/browse/GEODE-9069
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest >
> testConcurrentHExists_whileAddingValues FAILED
> 00:56:20java.lang.RuntimeException:
> java.util.concurrent.ExecutionException:
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:77)
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.runInLockstep(ConcurrentLoopingThreads.java:96)
> 00:56:20at
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest.testConcurrentHExists_whileAddingValues(HExistsDUnitTest.java:121)
> 00:56:20
> 00:56:20Caused by:
> 00:56:20java.util.concurrent.ExecutionException:
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
> 00:56:20at
> java.util.concurrent.FutureTask.get(FutureTask.java:205)
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:73)
> 00:56:20... 2 more
> 00:56:20
> 00:56:20Caused by:
> 00:56:20org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 00:56:20at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 00:56:20at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 00:56:20at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 00:56:20at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 00:56:20at
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest.lambda$testConcurrentHExists_whileAddingValues$5(HExistsDUnitTest.java:120)
> 00:56:20
> 00:56:20Caused by:
> 00:56:20java.util.concurrent.TimeoutException
> 00:56:20at
> java.util.concurrent.FutureTask.get(FutureTask.java:204)
> 00:56:20at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
> 00:56:20at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
> 00:56:20at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:101)
> 00:56:20... 5 more {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161436/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161436/distributedtestfiles-OpenJDK11-1.15.0-build.0081.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8910) Native libraries should hash key objects similarly to their Java counterparts
[ https://issues.apache.org/jira/browse/GEODE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8910: Fix Version/s: (was: 1.15.0) 1.14.0 > Native libraries should hash key objects similarly to their Java counterparts > - > > Key: GEODE-8910 > URL: https://issues.apache.org/jira/browse/GEODE-8910 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Current not all the C++ or .NET types consistently hash to values consistent > with the Java server. This can result in multi hop operations. Also, not all > hashing algorithms are publicly accessible to in the library. > The C++ and .NET libraries should expose hashing functions consistent with > Java that are easy to use both internally and by user defined keys. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8694: Fix Version/s: 1.14.0 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Hale Bales >Priority: Trivial > Labels: pull-request-available > Fix For: 1.14.0 > > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8088) Refactor: Move packages in dunit test folder
[ https://issues.apache.org/jira/browse/GEODE-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8088: Fix Version/s: 1.14.0 > Refactor: Move packages in dunit test folder > > > Key: GEODE-8088 > URL: https://issues.apache.org/jira/browse/GEODE-8088 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Murtuza Boxwala >Assignee: Ray Ingles >Priority: Major > Fix For: 1.14.0 > > > Did some refactoring as a group. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8068) Revert GEODE-8033 and GEODE-8044
[ https://issues.apache.org/jira/browse/GEODE-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8068: Fix Version/s: 1.14.0 > Revert GEODE-8033 and GEODE-8044 > > > Key: GEODE-8068 > URL: https://issues.apache.org/jira/browse/GEODE-8068 > Project: Geode > Issue Type: New Feature >Reporter: Patrick Johnsn >Priority: Major > Fix For: 1.13.0, 1.14.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8054) Refactor Sadd and Srem DUnit tests to use ConcurrentLoopingThreads class
[ https://issues.apache.org/jira/browse/GEODE-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8054: Fix Version/s: (was: 1.13.0) 1.14.0 > Refactor Sadd and Srem DUnit tests to use ConcurrentLoopingThreads class > > > Key: GEODE-8054 > URL: https://issues.apache.org/jira/browse/GEODE-8054 > Project: Geode > Issue Type: Improvement > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > Fix For: 1.14.0 > > > Other concurrent DUnit and integration tests are utilizing the > ConcurrentLoopingThreads class to generate and run concurrent threads. We > wanted to be consistent across DUnit and integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7846) Clear in Partitioned Region should have its own stats
[ https://issues.apache.org/jira/browse/GEODE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7846: Fix Version/s: (was: 1.14.0) > Clear in Partitioned Region should have its own stats > - > > Key: GEODE-7846 > URL: https://issues.apache.org/jira/browse/GEODE-7846 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI, pull-request-available > > Clear operation in PR should have its own stats: > 1) clear operation executed. > 2) clear operation failed > 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405675#comment-17405675
]
Owen Nichols commented on GEODE-9139:
-
this was reverted on 1.13 and 1.14. I think we are still waiting for it to be
reverted on develop...? Or is it properly fixed on develop...?
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
