[jira] [Resolved] (GEODE-9813) Move geode-for-redis properties to the geode-for-redis module
[ https://issues.apache.org/jira/browse/GEODE-9813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9813. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Move geode-for-redis properties to the geode-for-redis module > - > > Key: GEODE-9813 > URL: https://issues.apache.org/jira/browse/GEODE-9813 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Priority: Major > > The goal is that geode-core should have no references to geode-for-redis > gemfire properties. > This probably involves these steps: > * Change geode-core to support dynamically discovering modules that define > new gemfire properties, perhaps using a service loader or other mechanism. > Update the validation logic of gemfire properties to include these > dynamically discovered properties. > * Move the definition of the geode-for-redis properties to the > geode-for-redis module. This includes moving the public > ConfigurationProperties constants to some new public interface in the > geode-for-redis module. > We should consider deprecating and moving properties for other modules as > well - for example the memcached properties. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9752) Limit Memory Consumption for Read Operation
[ https://issues.apache.org/jira/browse/GEODE-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9752. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Limit Memory Consumption for Read Operation > --- > > Key: GEODE-9752 > URL: https://issues.apache.org/jira/browse/GEODE-9752 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > > The "read" commands can be made more memory friendly by streaming back their > result to netty a "batch" at a time. They can get the netty ByteBuf and write > the result directly to it. Once the buffer contains a certain number of bytes > (say 4k) it do a write and flush. Once that completes it can then use the > same buffer to send the next 4k bytes to the client. Writing the response > directly to the netty ByteBuf will also produce less garbage. The only > downside to it is that the writing will be done while holding the stripe > lock. This probably will not be any slower unless the buffer fills up while > we still hold the lock. The last buffer (the one that is not full) can be > done after the lock is released just as we currently do by returning a > RedisResponse outside the lock and then asking it to write itself to netty. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9275) Geode redis need to support memory usage command
[
https://issues.apache.org/jira/browse/GEODE-9275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9275.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Geode redis need to support memory usage command
>
>
> Key: GEODE-9275
> URL: https://issues.apache.org/jira/browse/GEODE-9275
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Eric Shu
>Priority: Major
>
> This is found when converting jedis client integrated test to use jedis
> cluster cleint.
> Native redis supports the memory usage command, but geode redis does not.
> {noformat}
> redis.clients.jedis.exceptions.JedisDataException: ERR unknown command
> `MEMORY`, with args beginning with: `usage`, `key`,
> at redis.clients.jedis.Protocol.processError(Protocol.java:132)
> at redis.clients.jedis.Protocol.process(Protocol.java:166)
> at redis.clients.jedis.Protocol.read(Protocol.java:220)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:283)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:225)
> at redis.clients.jedis.Jedis.memoryUsage(Jedis.java:3911)
> at redis.clients.jedis.JedisCluster$200.execute(JedisCluster.java:2275)
> at redis.clients.jedis.JedisCluster$200.execute(JedisCluster.java:2272)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:104)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:25)
> at redis.clients.jedis.JedisCluster.memoryUsage(JedisCluster.java:2277)
> at
> org.apache.geode.redis.internal.executor.string.AbstractAppendIntegrationTest.testAppend_actuallyIncreasesBucketSize(AbstractAppendIntegrationTest.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9970) Decouple Redis Module From Geode Core
[ https://issues.apache.org/jira/browse/GEODE-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9970. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Decouple Redis Module From Geode Core > - > > Key: GEODE-9970 > URL: https://issues.apache.org/jira/browse/GEODE-9970 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > > Decouple the Redis module from Geode Core to allow for the Redis module to > evolve and be released independently from Geode Core. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10004) Starting server should fail fast when server port and redis port are the same
[
https://issues.apache.org/jira/browse/GEODE-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-10004.
---
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Starting server should fail fast when server port and redis port are the same
> -
>
> Key: GEODE-10004
> URL: https://issues.apache.org/jira/browse/GEODE-10004
> Project: Geode
> Issue Type: Bug
> Components: gfsh, redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> When starting a cluster with GFSH with geode-for-redis enabled, starting a
> server fails when the geode-for-redis-port and server-port are set to the
> same port. It fails with the below stacktrace, but does not fail fast. We
> should be able to detect this issue before we reach the point of getting a
> bind exception.
> stacktrace:
> {code:java}
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred
> while starting a Server in /Users/hbales/workspace/geode/itch-proud-alpha on
> hbales-a01.vmware.com[6379]: Failed to create server socket on
> 192.168.0.4[6379]
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:863)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:258)
> Caused by: java.net.BindException: Failed to create server socket on
> 192.168.0.4[6379]
> 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.internal.net.SocketCreator.createServerSocket(SocketCreator.java:522)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:573)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:291)
> at
> org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:420)
> at
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:377)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:1039)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:837)
> ... 2 more
> Caused by: java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 10 more
> {code}
> series of GFSH commands that led to this error:
> {code:java}
> > start locator
> > start server --J=-Dgemfire.geode-for-redis-enabled=true
> > --J=-Dgemfire.geode-for-redis-port=6379 --server-port=6379
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-8976) Change thread monitoring service to detect hung redis threads
[ https://issues.apache.org/jira/browse/GEODE-8976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-8976. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Change thread monitoring service to detect hung redis threads > - > > Key: GEODE-8976 > URL: https://issues.apache.org/jira/browse/GEODE-8976 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Priority: Major > > In the same way that GEODE-8521 enhanced the thread monitoring service to > detect hung p2p reader threads, if a redis thread is hung processing a > request from a redis client then the thread monitoring service should issue a > warning. The monitoring should be suspended while the thread is waiting for > another request from a client. > Most of the work for this has been done in GEODE-8521 (see > https://github.com/apache/geode/pull/5763) so this improvement should be > pretty easy -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9614) Split ci/execute_redis_tests.sh into infra and execution
[
https://issues.apache.org/jira/browse/GEODE-9614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9614.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Split ci/execute_redis_tests.sh into infra and execution
>
>
> Key: GEODE-9614
> URL: https://issues.apache.org/jira/browse/GEODE-9614
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> In keeping with the way other tasks are typically executed, we should launch
> a large worker and execute the redis tcl tests there. This may seem
> unnecessary, but it does maintain consistency. In addition, it will allow
> actual changes to the scripts to be picked up as part of a PR run. Currently
> anything used under {{ci/}}, in the PR jobs, is only pulled from develop and
> is not referenced from the actual PR.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9992) Migrate Redis Unit Tests to Use of JUnit5
[ https://issues.apache.org/jira/browse/GEODE-9992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9992. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Migrate Redis Unit Tests to Use of JUnit5 > - > > Key: GEODE-9992 > URL: https://issues.apache.org/jira/browse/GEODE-9992 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > > Special attention must be made regarding JUnit4 Rules which are no longer > supported in JUnit5. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10051) Create Configuration for Keyspace Notifications
[ https://issues.apache.org/jira/browse/GEODE-10051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10051. --- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Create Configuration for Keyspace Notifications > --- > > Key: GEODE-10051 > URL: https://issues.apache.org/jira/browse/GEODE-10051 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > [Keyspace Notifications|https://redis.io/topics/notifications#configuration] > require a common infrastructure for configuration. > > +Acceptance Criteria+ > The infrastructure for Keyspace Notifications has been created along with the > appropriate unit testing and documentation updates. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9385) Test Radish using Spring's RedisTemplate
[ https://issues.apache.org/jira/browse/GEODE-9385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9385. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Test Radish using Spring's RedisTemplate > > > Key: GEODE-9385 > URL: https://issues.apache.org/jira/browse/GEODE-9385 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > > When using a Spring Session app with redis, we found that DUMP/RESTORE were > additional required commands. We should have a test that exercises the > RedisTemplate API to ensure nothing else is missing. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10244) Clean up synchronization in AbstractRedisData.fromDelta
[ https://issues.apache.org/jira/browse/GEODE-10244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10244. --- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Clean up synchronization in AbstractRedisData.fromDelta > --- > > Key: GEODE-10244 > URL: https://issues.apache.org/jira/browse/GEODE-10244 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Priority: Major > > Our use of synchronization when applying various delta types is inconsistent > and should be cleaned up - we should not need any synchronization when > applying deltas. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9571) Radish REMRANGE* DUnit tests may fail in stress-test
[
https://issues.apache.org/jira/browse/GEODE-9571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9571.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Radish REMRANGE* DUnit tests may fail in stress-test
>
>
> Key: GEODE-9571
> URL: https://issues.apache.org/jira/browse/GEODE-9571
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Fix For: 1.15.0
>
>
> Failures were seen in pre-checkin stress-new-test for
> ZRemRangeByScoreDUnitTest, ZRemRangeByRankDUnitTest and
> ZRemRangeByLexDUnitTest, all of which use similar test methods. The failures
> were seen in the *RemovesMembersFromSortedSetAfterPrimaryShutsDown() test and
> the *CanRemoveMembersFromSortedSetWhenPrimaryIsCrashed() test in a few
> different runs.
> The failures in *CanRemoveMembersFromSortedSetWhenPrimaryIsCrashed() were
> seen when the tests for both ZRemRangeByScoreDUnitTest and
> ZRemRangeByRankDUnitTest were being run at the same time due to both classes
> being changed. It's possibly relevant that the difference in the second
> assertion (expected:<[999]L> but was:<[498]L>) is exactly the incorrect
> number of members removed in the first assertion (expected:<[499]L> but
> was:<[501]L>):
> {noformat}
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest
> > zRemRangeByScoreCanRemoveMembersFromSortedSetWhenPrimaryIsCrashed FAILED
> java.util.concurrent.ExecutionException: org.junit.ComparisonFailure:
> expected:<[499]L> but was:<[501]L>
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest.zRemRangeByScoreCanRemoveMembersFromSortedSetWhenPrimaryIsCrashed(ZRemRangeByScoreDUnitTest.java:159)
> Caused by:
> org.junit.ComparisonFailure: expected:<[499]L> but was:<[501]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest.removeAllButFirstEntry(ZRemRangeByScoreDUnitTest.java:213)
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByRankDUnitTest >
> zRemRangeByRankCanRemoveMembersFromSortedSetWhenPrimaryIsCrashed FAILED
> java.util.concurrent.ExecutionException: org.junit.ComparisonFailure:
> expected:<[999]L> but was:<[498]L>
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByRankDUnitTest.zRemRangeByRankCanRemoveMembersFromSortedSetWhenPrimaryIsCrashed(ZRemRangeByRankDUnitTest.java:144)
> Caused by:
> org.junit.ComparisonFailure: expected:<[999]L> but was:<[498]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByRankDUnitTest.removeAllButFirstEntry(ZRemRangeByRankDUnitTest.java:206)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6803/test-results/repeatTest/1630442126/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6803/test-artifacts/1630442126/stressnewtestfiles-geode-pr-6803.tgz]
> The same failure was also seen in this second run, along with a failure in
> ZRemRangeByScoreDUnitTest >
> zRemRangeByScoreRemovesMembersFromSortedSetAfterPrimaryShutsDown due to the
> remove command not finding any members to remove:
> {noformat}
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest
> > zRemRangeByScoreRemovesMembersFromSortedSetAfterPrimaryShutsDown FAILED
> org.junit.ComparisonFailure: expected:<[50]0L> but was:<[]0L>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>
[jira] [Resolved] (GEODE-9726) Add Redis Command Context to Authorization
[ https://issues.apache.org/jira/browse/GEODE-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9726. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Add Redis Command Context to Authorization > -- > > Key: GEODE-9726 > URL: https://issues.apache.org/jira/browse/GEODE-9726 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > > As an enterprise security engineer, I would like to integrate Geode for Redis > with my corporate security system to determine if a user is authorized to > perform a specified command. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9437) Redis session dunit tests are flaky
[
https://issues.apache.org/jira/browse/GEODE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9437.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Redis session dunit tests are flaky
> ---
>
> Key: GEODE-9437
> URL: https://issues.apache.org/jira/browse/GEODE-9437
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> The Redis session-related DUnit tests will sometimes fail with errors such as:
> {noformat}
> org.apache.geode.redis.session.RedisSessionDUnitTest > should_storeSession
> FAILED
>
> org.springframework.web.client.HttpServerErrorException$InternalServerError:
> 500 Server Error: [no body]
> at
> org.springframework.web.client.HttpServerErrorException.create(HttpServerErrorException.java:100)
> at
> org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:188)
> at
> org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:125)
> at
> org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63)
> at
> org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:819)
> at
> org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:777)
> at
> org.springframework.web.client.RestTemplate.execute(RestTemplate.java:711)
> at
> org.springframework.web.client.RestTemplate.postForEntity(RestTemplate.java:468)
> at
> org.apache.geode.redis.session.SessionDUnitTest.createNewSessionWithNote0(SessionDUnitTest.java:207)
> at
> org.apache.geode.redis.session.SessionDUnitTest.lambda$createNewSessionWithNote$1(SessionDUnitTest.java:201)
> at
> io.github.resilience4j.retry.Retry.lambda$decorateCallable$5(Retry.java:306)
> at
> org.apache.geode.redis.session.SessionDUnitTest.createNewSessionWithNote(SessionDUnitTest.java:201)
> at
> org.apache.geode.redis.session.RedisSessionDUnitTest.should_storeSession(RedisSessionDUnitTest.java:88)
> org.apache.geode.redis.session.RedisSessionDUnitTest >
> should_propagateSession_toOtherServers FAILED
>
> org.springframework.web.client.HttpServerErrorException$InternalServerError:
> 500 Server Error:
> [{"timestamp":"2021-07-19T15:38:49.855+00:00","status":500,"error":"Internal
> Server Error","path":"/addSessionNote"}]
> at
> org.springframework.web.client.HttpServerErrorException.create(HttpServerErrorException.java:100)
> at
> org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:188)
> at
> org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:125)
> at
> org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63)
> at
> org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:819)
> at
> org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:777)
> at
> org.springframework.web.client.RestTemplate.execute(RestTemplate.java:711)
> at
> org.springframework.web.client.RestTemplate.postForEntity(RestTemplate.java:468)
> at
> org.apache.geode.redis.session.SessionDUnitTest.createNewSessionWithNote0(SessionDUnitTest.java:207)
> at
> org.apache.geode.redis.session.SessionDUnitTest.lambda$createNewSessionWithNote$1(SessionDUnitTest.java:201)
> at
> io.github.resilience4j.retry.Retry.lambda$decorateCallable$5(Retry.java:306)
> at
> org.apache.geode.redis.session.SessionDUnitTest.createNewSessionWithNote(SessionDUnitTest.java:201)
> at
> org.apache.geode.redis.session.RedisSessionDUnitTest.should_propagateSession_toOtherServers(RedisSessionDUnitTest.java:97)
> {noformat}
> It's unclear exactly what is causing the problem as it seems to be related to
> lettuce when servers stop/restart and lettuce tries to resubmit commands.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9283) Convert session related redis DUnit tests to be cluster-aware.
[ https://issues.apache.org/jira/browse/GEODE-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9283. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Convert session related redis DUnit tests to be cluster-aware. > -- > > Key: GEODE-9283 > URL: https://issues.apache.org/jira/browse/GEODE-9283 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9513) optimize redis SCAN commands cursor type
[
https://issues.apache.org/jira/browse/GEODE-9513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9513.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> optimize redis SCAN commands cursor type
>
>
> Key: GEODE-9513
> URL: https://issues.apache.org/jira/browse/GEODE-9513
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Darrel Schneider
>Priority: Major
>
> The geode SCAN commands implement the cursor with a BigInteger type. It seems
> like it could instead be a "long". The following are some discussions on
> slack about this:
> Darrel Schneider:
> Does anyone know why the redis HSCAN, SSCAN, and SCAN cursor in our
> implementation is a BigInteger? This seems like overkill. I would think in
> our implementation a 64-bit signed value would be big enough for the scan
> cursor.
> Donal Evans
> I think it's to ensure that our input values match native Redis. Redis takes
> values in the range of BigInteger for cursor, even though they have the same
> constraints on the number of elements in their collections that we do
> Darrel Schneider
> The redis docs say:
> {noformat}
> Calling SCAN with a broken, negative, out of range, or otherwise invalid
> cursor, will result into undefined behavior but never into a crash. What will
> be undefined is that the guarantees about the returned elements can no longer
> be ensured by the SCAN implementation.
> The only valid cursors to use are:
> The cursor value of 0 when starting an iteration.
> The cursor returned by the previous call to SCAN in order to continue the
> iteration.
> {noformat}
> Since we will never return a cursor larger than a signed 64-bit number is
> seems like if we see one come in we could immediately return an empty scan
> since that is what we will do anyway in our current implementation but we do
> a bunch of work to figure that out. Since we never return a cursor larger
> than Long.MAX_VALUE it seems like we could do some validation on the input
> and only if it looks like a valid cursor do a real scan. That would allow our
> scan impl to use a "long" instead of a BigInteger. Since BigInteger is
> immutable incrementing it produces a bunch of garbage. So it seems like we
> could be compatible with native redis without using a BigInteger all the
> time. Let me know if I'm missing something.
> Donal Evans
> I think that's a good idea, but we'd probably still have to create a
> BigInteger at least once, to cover all the bases. There are three cases we
> have to deal with here, I think: 1. the cursor is a valid positive Long, in
> which case we parse it and use it. 2. the cursor is a positive integer larger
> than Long.MAX_VALUE but smaller than the capacity of an unsigned long (which
> is the largest value Redis accepts) in which case we just return an empty
> scan 3. the cursor is negative, larger than the capacity of an unsigned long
> or not an integer, in which case we return an error. Telling the difference
> between cases 2 and 3 is where we might run into trouble, since we've been
> trying to exactly mirror Redis' behaviour when it comes to errors
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9700) ZUNIONSTORE and ZINTERSTORE need to work with regular sets as inputs
[ https://issues.apache.org/jira/browse/GEODE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9700. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > ZUNIONSTORE and ZINTERSTORE need to work with regular sets as inputs > > > Key: GEODE-9700 > URL: https://issues.apache.org/jira/browse/GEODE-9700 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Priority: Major > Labels: redis-triage > > Some of the Redis TCL tests fail when running against Geode due to > ZUNIONSTORE and ZINTERSTORE taking regular sets (as opposed to sorted sets) > as input. Geode returns the error "WRONGTYPE Operation against a key holding > the wrong kind of value" when native Redis succeeds. > The tests include: > * ZUNIONSTORE with a regular set and weights > * ZINTERSTORE with a regular set and weights > * ZINTERSTORE regression with two sets, intset+hashtable > * ZINTERSTORE #516 regression, mixed sets and ziplist zsets > Enable these tests as part of this fix. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9889.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Jens Deppe
>Priority: Major
> Labels: redis-triage
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9788) Develop PubSub Benchmark Tests
[ https://issues.apache.org/jira/browse/GEODE-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9788. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Develop PubSub Benchmark Tests > -- > > Key: GEODE-9788 > URL: https://issues.apache.org/jira/browse/GEODE-9788 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > > Develop a suite of benchmarking tests for the pubsub API that benchmark the > comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the pubsub that allows us to monitor the performance over time and compared > to native Redis. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10124) Refactor Geode-DUnit as a Class Library
[ https://issues.apache.org/jira/browse/GEODE-10124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10124. --- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Refactor Geode-DUnit as a Class Library > --- > > Key: GEODE-10124 > URL: https://issues.apache.org/jira/browse/GEODE-10124 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > > Refactor Dunit so that it can be used as a standalone class library. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-8927) Implement the Redis allkeys-lru eviction policy when OOM
[ https://issues.apache.org/jira/browse/GEODE-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-8927. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Implement the Redis allkeys-lru eviction policy when OOM > > > Key: GEODE-8927 > URL: https://issues.apache.org/jira/browse/GEODE-8927 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.14.0 >Reporter: Ray Ingles >Priority: Major > > Native Redis supports various eviction policies when running out of memory. > The default is "allkeys-lru", where the least-recently-used keys are evicted > to make room for new data. Geode Redis needs to implement this policy as that > is what Redis users will expect. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10091) Benchmark instability in RedisZaddAndZremBenchmark
[
https://issues.apache.org/jira/browse/GEODE-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-10091.
---
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Benchmark instability in RedisZaddAndZremBenchmark
> --
>
> Key: GEODE-10091
> URL: https://issues.apache.org/jira/browse/GEODE-10091
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Eric Zoerner
>Priority: Major
> Labels: redis-triage
>
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> RedisGetBenchmark avg ops/sec
> Baseline:428358.55 Test:446241.49 Difference: +4.2%
> avg latency
> Baseline: 1678809.55 Test: 1611045.34 Difference: -4.0%
> RedisHgetBenchmark avg ops/sec
> Baseline:438535.25 Test:441078.97 Difference: +0.6%
> avg latency
> Baseline: 1638968.92 Test: 1630999.16 Difference: -0.5%
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:191331.54 Test:186806.37 Difference: -2.4%
> avg latency
> Baseline: 3759694.09 Test: 3850396.04 Difference: +2.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:308079.41 Test:303715.78 Difference: -1.4%
> avg latency
> Baseline: 2332102.91 Test: 2367639.93 Difference: +1.5%
> RedisSetBenchmark avg ops/sec
> Baseline:318147.74 Test:326996.22 Difference: +2.8%
> avg latency
> Baseline: 2263687.57 Test: 2198181.68 Difference: -2.9%
> RedisWeightedHsetAndHgetBenchmark avg ops/sec
> Baseline:390383.79 Test:385565.48 Difference: -1.2%
> avg latency
> Baseline: 1842561.96 Test: 1864716.09 Difference: +1.2%
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:375078.82 Test:350886.03 Difference: -6.5%
> avg latency
> Baseline: 1917476.15 Test: 2049452.87 Difference: +6.9%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:124763.60 Test:118600.72 Difference: -4.9%
> avg latency
> Baseline: 5766048.34 Test: 6065491.13 Difference: +5.2%
> RedisZaddBenchmark avg ops/sec
> Baseline:432494.29 Test:438594.53 Difference: +1.4%
> avg latency
> Baseline: 1662639.09 Test: 1639906.18 Difference: -1.4%
> RedisZrangeBenchmark avg ops/sec
> Baseline:295523.77 Test:340381.87 Difference: +15.2%
> avg latency
> Baseline: 2433250.54 Test: 2112961.66 Difference: -13.2%
> RedisZrangeByScoreBenchmark avg ops/sec
> Baseline:285836.33 Test:356142.91 Difference: +24.6%
> avg latency
> Baseline: 2515708.23 Test: 2019249.68 Difference: -19.7%
> This is ITERATION 2 of benchmarking against baseline.
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:358570.33 Test:348012.02 Difference: -2.9%
> avg latency
> Baseline: 2005804.05 Test: 2066535.24 Difference: +3.0%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:122900.38 Test:115226.22 Difference: -6.2%
> avg latency
> Baseline: 5858357.13 Test: 6243018.38 Difference: +6.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:125677.36 Test:118359.94 Difference: -5.8%
> avg latency
> Baseline: 5721859.26 Test: 6082944.28 Difference: +6.3%
> This is ITERATION 4 of benchmarking
[jira] [Resolved] (GEODE-9938) Optimize SRANDMEMBER
[ https://issues.apache.org/jira/browse/GEODE-9938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9938. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Optimize SRANDMEMBER > > > Key: GEODE-9938 > URL: https://issues.apache.org/jira/browse/GEODE-9938 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > The SRANDMEMBER Command may require later optimization to minimally copy the > target members to the result set. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-7793) Refactor ExecutionHandlerContext to avoid 'feature-envy'
[
https://issues.apache.org/jira/browse/GEODE-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-7793.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Refactor ExecutionHandlerContext to avoid 'feature-envy'
>
>
> Key: GEODE-7793
> URL: https://issues.apache.org/jira/browse/GEODE-7793
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> What is feature envy? https://refactoring.guru/smells/feature-envy
> {{ExecutionHandlerContext}} should avoid exposing its internal data
> structures to Executors - essentially get rid of {{getPubSub}},
> {{getKeyRegistrar}}, and possibly {{getRegionProvider}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9170) Support ZGC
[ https://issues.apache.org/jira/browse/GEODE-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9170. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Support ZGC > --- > > Key: GEODE-9170 > URL: https://issues.apache.org/jira/browse/GEODE-9170 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > Our performance research indicated that throughput improved by 13% by using > the Z Garbage Collector. > In addition to use of ZGC, we also need to rework the ResourceManager. > The ResourceManager is monitoring the MBeans related to GC and trying to > guestimate how much memory is being used. Based upon heap usage, and user > configured thresholds, the user can configure eviction. > Exceeding the Critical threshold will stop puts. When can add support for > ZGC by looking at the correct MBeans for ZGC. Alternatively, we can stop > using the ResourceManager and find a new way of monitoring heap. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9728) Support COMMAND INFO
[ https://issues.apache.org/jira/browse/GEODE-9728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9728. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Support COMMAND INFO > - > > Key: GEODE-9728 > URL: https://issues.apache.org/jira/browse/GEODE-9728 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > Provide support for the [COMMAND INFO|https://redis.io/commands/command-info] > command. > > +Acceptance Criteria+ > The command has been implemented per specification along with appropriate > automated 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.20.7#820007)
[jira] [Resolved] (GEODE-9840) Improve Redundancy Level Log Message
[ https://issues.apache.org/jira/browse/GEODE-9840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9840. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Improve Redundancy Level Log Message > > > Key: GEODE-9840 > URL: https://issues.apache.org/jira/browse/GEODE-9840 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > The current log message > Configured redundancy of 2 copies has been restored to /GEODE_FOR_REDIS > > is confusing and not intuitive. This message should be changed to the > following: > "Configured redundancy of 2 copies has been restored to /region (1 primary > and 1 secondary copies)"? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10135) Redis Benchmarks
[ https://issues.apache.org/jira/browse/GEODE-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10135. --- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Redis Benchmarks > > > Key: GEODE-10135 > URL: https://issues.apache.org/jira/browse/GEODE-10135 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > Remove Redis benchmarks from the Geode benchmark job and the geode-benchmarks > repository > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9716) ZRemRangeByScoreDUnitTest.zRemRangeByScoreRemovesMembersFromSortedSetAfterPrimaryShutsDown fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-9716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9716.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> ZRemRangeByScoreDUnitTest.zRemRangeByScoreRemovesMembersFromSortedSetAfterPrimaryShutsDown
> fails intermittently
> ---
>
> Key: GEODE-9716
> URL: https://issues.apache.org/jira/browse/GEODE-9716
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Ray Ingles
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> zRemRangeByScoreRemovesMembersFromSortedSetAfterPrimaryShutsDown fails rarely
> with the following stack trace:
> {code:java}
> ZRemRangeByScoreDUnitTest >
> zRemRangeByScoreRemovesMembersFromSortedSetAfterPrimaryShutsDown FAILED
> org.opentest4j.AssertionFailedError:
> expected: 500L
> but was: 0L
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest.zRemRangeByScoreWithRetries(ZRemRangeByScoreDUnitTest.java:253)
> at
> org.apache.geode.redis.internal.executor.sortedset.ZRemRangeByScoreDUnitTest.doZRemRangeByScoreWithRetries(ZRemRangeByScoreDUnitTest.java:237)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9839) Ability to Set Log Level for Specific Package
[ https://issues.apache.org/jira/browse/GEODE-9839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9839. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Ability to Set Log Level for Specific Package > - > > Key: GEODE-9839 > URL: https://issues.apache.org/jira/browse/GEODE-9839 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > > As a user of Geode, I would like the ability to use the alter runtime > --log-level command to set the logging level for a specific package. This > would allow me to turn on debug level logging for just the redis packages, > org.apache.geode.redis. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9966) Update redis info 'expires' and 'avg_ttl' properties with computed values
[
https://issues.apache.org/jira/browse/GEODE-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9966.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Update redis info 'expires' and 'avg_ttl' properties with computed values
> -
>
> Key: GEODE-9966
> URL: https://issues.apache.org/jira/browse/GEODE-9966
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> We're currently setting both {{expires}} and {{avg_ttl}} values (from
> {{{}INFO{}}}) to {{{}0{}}}. This information could easily be updated from the
> {{{}PassiveExpirationManager{}}}. Although the values will not necessarily be
> exactly accurate, (dependent on the frequency at which the PEM runs), they
> will at least be more accurate than they are currently.
> Once the output of these values has been updated,
> {{geode_for_redis.html.md.erb}} should also be updated to remove the "always
> returns 0" note for {{expires}} and {{avg_ttl}} in the footnote for the INFO
> command, found below the list of supported commands.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9450) StringBytesGlossary has a large number of MakeImmutable annotations
[ https://issues.apache.org/jira/browse/GEODE-9450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9450. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > StringBytesGlossary has a large number of MakeImmutable annotations > --- > > Key: GEODE-9450 > URL: https://issues.apache.org/jira/browse/GEODE-9450 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Priority: Minor > > All of the byte array constants in StringBytesGlossary are annotated with > MakeImmutable. This annotation indicates that changes need to be made. > We could just change the annotation to Immutable but then we would still have > static fields that could actually be mutated. > In the case of StringBytesGlossary it seems like some of the byte array > constants in it could be encapsulated into an Enum constant. The Enum > constructor would take a byte array and store it the instance. But it would > not have methods that allow other classes to get a reference to the byte > array. Instead it could just have a "boolean equalsIgnoreCaseBytes(byte[])" > and any other comparison methods needed and only those methods would need to > be coded correctly to not modify the array. This would work fine for all the > redis keywords we need to identify. Instead of passing a byte array to the > constructor we could probably just use Enum.getName() in the constructor and > call stringToBytes on it. > But other constants in StringBytesGlossary are used for output to be sent > back the the client (for example see bPING_RESPONSE). For those we probably > should just mark the as Immutable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9563) Examples for Token Refresh/Reauthentication With Redis Clients
[ https://issues.apache.org/jira/browse/GEODE-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9563. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Examples for Token Refresh/Reauthentication With Redis Clients > -- > > Key: GEODE-9563 > URL: https://issues.apache.org/jira/browse/GEODE-9563 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > The Redis Server and clients do not directly support token refresh or > reauthentication. Write example code of how we can accomplish a forced > reauthentication using the existing Redis clients. > > _Acceptance Criteria_ > Example code has been written using the Jedis and Lettuce clients that > illustrate how to force these clients to reauthenticate. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9945) Override Equality Checking for Redis Lists
[ https://issues.apache.org/jira/browse/GEODE-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9945. -- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Override Equality Checking for Redis Lists > -- > > Key: GEODE-9945 > URL: https://issues.apache.org/jira/browse/GEODE-9945 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > Override methods in LinkedList that perform equality checking to account for > our usage of byte[] content. > > +Acceptance Criteria+ > At a minimum, the remove and indexof methods are overridden. > Appropriate unit testing is added. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9370) Remove unnecessary serialization constructs from Radish classes
[
https://issues.apache.org/jira/browse/GEODE-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9370.
--
Resolution: Won't Fix
Closing this issue because geode-for-redis was removed in GEODE-10278
> Remove unnecessary serialization constructs from Radish classes
> ---
>
> Key: GEODE-9370
> URL: https://issues.apache.org/jira/browse/GEODE-9370
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> Since we're not performing function execution anymore, a few of our classes
> don't need to implement any serialization mechanics:
> SetOptions
> SortedSetOptions
> Also revisit classes that are included in
> {{sanctioned-geode-apis-compatible-with-redis-serializables.txt}} as well as
> {{geode-apis-compatible-with-redis/src/integrationTest/resources/org/apache/geode/codeAnalysis/excludedClasses.txt}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10064) Native Redis Acceptance Test Separate Job
[ https://issues.apache.org/jira/browse/GEODE-10064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10064. --- Resolution: Won't Fix Closing this issue because geode-for-redis was removed in GEODE-10278 > Native Redis Acceptance Test Separate Job > - > > Key: GEODE-10064 > URL: https://issues.apache.org/jira/browse/GEODE-10064 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > Split out into separate job. Only run if changes occurred to geode-for-redis > integration test files. New sourceset name, integration-test-validation-test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10278) Remove geode-for-redis module
[ https://issues.apache.org/jira/browse/GEODE-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10278. --- Fix Version/s: 1.15.0 Assignee: Dan Smith Resolution: Fixed > Remove geode-for-redis module > - > > Key: GEODE-10278 > URL: https://issues.apache.org/jira/browse/GEODE-10278 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > There is consensus to remove the geode-for-redis module from geode, based on > this discussion thread - > [https://lists.apache.org/thread/7m23h9r0tf536g414bwjsplqh1qv2ct0] > This module was still experimental in Geode 1.14, so it can be removed > without breaking our API guarantees. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10278) Remove geode-for-redis module
Dan Smith created GEODE-10278: - Summary: Remove geode-for-redis module Key: GEODE-10278 URL: https://issues.apache.org/jira/browse/GEODE-10278 Project: Geode Issue Type: Improvement Components: redis Reporter: Dan Smith There is consensus to remove the geode-for-redis module from geode, based on this discussion thread - [https://lists.apache.org/thread/7m23h9r0tf536g414bwjsplqh1qv2ct0] This module was still experimental in Geode 1.14, so it can be removed without breaking our API guarantees. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10268) Peer-to-peer connection due to race condition overtakes the --server-port causing server to hang during startup
[
https://issues.apache.org/jira/browse/GEODE-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530836#comment-17530836
]
Dan Smith commented on GEODE-10268:
---
I think the membership-port-range determines the port that the server side of
the TCP socket is listening on.
What I see in your log statement is the port number of the client side of the
socket (where it says localport=37392). The port for the client side of a
socket comes from the ephemeral port range configured on your OS - usually
32768–60999 in linux.
[https://en.wikipedia.org/wiki/Ephemeral_port]
To avoid this problem, pick a --server-port that is less than 32768, or
reconfigure your OS to use a different ephemeral port range -
https://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html.
> Peer-to-peer connection due to race condition overtakes the --server-port
> causing server to hang during startup
> ---
>
> Key: GEODE-10268
> URL: https://issues.apache.org/jira/browse/GEODE-10268
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Attachments: reproducedBindRejectedDueToPeerToPeer.txt
>
>
> {color:#0e101a}The issue is reproduced
> ({color}[^reproducedBindRejectedDueToPeerToPeer.txt]{color:#0e101a} ) with
> the patch at creating the acceptor that tries to bind the port already used
> in peer-to-peer connection. The problem is that distributed system starts
> before the client/server connection acceptor listener. Because of that, a
> peer-to-peer connection may take the port configured in the --server-port
> parameter. Also, it seems that these peer-to-peer connections take ports
> outside the range configured {color}*{color:#0e101a}with the
> membership-port-range{color}* {color:#0e101a}parameter:{color}
> {code:java}
> [vm1] membership-port-range=41000-61000{code}
> The peer-to-peer connection:
> {color:#0e101a}[vm1] [debug 2022/05/02 *11:15:57.968* {color}CEST server-1
> tid=0x1a] starting peer-to-peer
> handshake on socket
> Socket[addr=/192.168.1.36,port=49913,{color:#de350b}*localport=37392*{color}]
> Server try to create acceptor later on:
> {code:java}
> [vm1] exeption for java.net.BindException: Failed to create server socket on
> 192.168.1.36[37392]
> [vm1] [info 2022/05/02 11:16:00.421 CEST server-1 Connection(1)-192.168.1.36> tid=0x1a] Got result: EXCEPTION_OCCURRED
> [vm1] java.lang.RuntimeException: unable to start server
> [vm1] at
> org.apache.geode.test.junit.rules.ServerStarterRule.startServer(ServerStarterRule.java:225)
> [vm1] at
> org.apache.geode.test.junit.rules.ServerStarterRule.before(ServerStarterRule.java:99)
> [vm1] at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startServerVM$6d6c10c2$1(ClusterStartupRule.java:284)
> [vm1] at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> [vm1] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm1] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm1] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm1] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm1] at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> [vm1] at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> [vm1] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm1] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm1] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm1] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm1] at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> [vm1] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm1] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm1] at java.security.AccessController.doPrivileged(Native Method)
> [vm1] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm1] at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> [vm1] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> [vm1] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> [vm1] at java.security.AccessController.doPrivileged(Native Method)
> [vm1] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> [vm1] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
[jira] [Assigned] (GEODE-10243) Old clients with durable queues should fail early if AuthenticationExpiredException is thrown
[
https://issues.apache.org/jira/browse/GEODE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-10243:
-
Assignee: Dan Smith
> Old clients with durable queues should fail early if
> AuthenticationExpiredException is thrown
> -
>
> Key: GEODE-10243
> URL: https://issues.apache.org/jira/browse/GEODE-10243
> Project: Geode
> Issue Type: Improvement
> Components: client queues
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
>
> As part of the changes for GEODE-9457, when an AuthenticationExpiredException
> is thrown from the SecurityManager during message dispatching, we send a
> message to 1.15 and newer clients asking them to re-authenticate.
> For 1.14 and older clients, we do not send a message. Instead, we just wait
> for the {color:#00875a}reauthenticate.wait.time{color} to elapse and then
> close the connection.
> The net effect of this is that if users are doing cache operations from 1.14
> and older clients, and their SecurityManager expires the credentials of the
> old clients, they will sometimes see their clients re-authenticate themselves
> in that time window. This will mislead users into thinking that
> re-authentication works with old clients and client queues, even though we
> [have documented that we don't support
> it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35].
> Instead of allowing re-authentication to sometimes work in this unsupported
> use case, we should always fail so that is clear to users that this use case
> is not supported.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10243) Old clients with durable queues should fail early if AuthenticationExpiredException is thrown
Dan Smith created GEODE-10243:
-
Summary: Old clients with durable queues should fail early if
AuthenticationExpiredException is thrown
Key: GEODE-10243
URL: https://issues.apache.org/jira/browse/GEODE-10243
Project: Geode
Issue Type: Improvement
Components: client queues
Reporter: Dan Smith
As part of the changes for GEODE-9457, when an AuthenticationExpiredException
is thrown from the SecurityManager during message dispatching, we send a
message to 1.15 and newer clients asking them to re-authenticate.
For 1.14 and older clients, we do not send a message. Instead, we just wait for
the {color:#00875a}reauthenticate.wait.time{color} to elapse and then close the
connection.
The net effect of this is that if users are doing cache operations from 1.14
and older clients, and their SecurityManager expires the credentials of the old
clients, they will sometimes see their clients re-authenticate themselves in
that time window. This will mislead users into thinking that re-authentication
works with old clients and client queues, even though we [have documented that
we don't support
it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35].
Instead of allowing re-authentication to sometimes work in this unsupported use
case, we should always fail so that is clear to users that this use case is not
supported.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10126) Refactor Configuration To Use System Properties
[ https://issues.apache.org/jira/browse/GEODE-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10126. --- Resolution: Fixed Benchmarks have been updated to use system properties. > Refactor Configuration To Use System Properties > --- > > Key: GEODE-10126 > URL: https://issues.apache.org/jira/browse/GEODE-10126 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The properties currently being used by the Redis module are defined in Geode > core. These properties need to be removed from Geode core and refactored to > system properties. > > Validators must also be added for the system properties to ensure that users > provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10126) Refactor Configuration To Use System Properties
[ https://issues.apache.org/jira/browse/GEODE-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reopened GEODE-10126: --- Assignee: Dan Smith (was: Jens Deppe) Re-opening this to fix the benchmarks as well, which need to use the new system properties. > Refactor Configuration To Use System Properties > --- > > Key: GEODE-10126 > URL: https://issues.apache.org/jira/browse/GEODE-10126 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The properties currently being used by the Redis module are defined in Geode > core. These properties need to be removed from Geode core and refactored to > system properties. > > Validators must also be added for the system properties to ensure that users > provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10151. --- Resolution: Fixed > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reopened GEODE-10151: --- Re-opening because the examples build is failing due to this change - https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/291 > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10151. --- Fix Version/s: 1.15.0 Resolution: Fixed > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-10151: - Assignee: Dan Smith > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-10151: -- Component/s: redis > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Priority: Major > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
Dan Smith created GEODE-10151: - Summary: Make geode-for-redis an optional dependency of a geode server Key: GEODE-10151 URL: https://issues.apache.org/jira/browse/GEODE-10151 Project: Geode Issue Type: Improvement Reporter: Dan Smith The geode-for-redis module and its related dependencies are on the classpath of the server by default when starting a server with gfsh start server or using the geode dependencies jar. We should make the module an optional dependencies, like some of our other extensions (for example, the tomcat http session modules). This would allow a user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10075) Fix support for jacoco code coverage in Geode build
[ https://issues.apache.org/jira/browse/GEODE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10075. --- Resolution: Fixed > Fix support for jacoco code coverage in Geode build > --- > > Key: GEODE-10075 > URL: https://issues.apache.org/jira/browse/GEODE-10075 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > We haven't been maintaining this gradle build support, but it is useful to be > able to get code coverage from distributed test runs, eg. > ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX > geode-core:jacocoDistributedTestReport > If you pass -PcodeCoverage it's currently failing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9925) Update LICENSE and notice for confluent connector
[ https://issues.apache.org/jira/browse/GEODE-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9925. -- Assignee: Dan Smith Resolution: Fixed > Update LICENSE and notice for confluent connector > - > > Key: GEODE-9925 > URL: https://issues.apache.org/jira/browse/GEODE-9925 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > > The geode-confluent-connector is bundling geode-core and it's third party > dependencies in the binary distribution. The LICENSE and NOTICE for the > binary distribution need to reflect this and include information related to > third party licenses. See the geode-core LICENSE and NOTICE files for example > - > [https://github.com/apache/geode/tree/develop/geode-assembly/src/main/dist.] > Perhaps we can just copy these in the geode-confluent-connectors LICENSE and > NOTICE? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10075) Fix support for jacoco code coverage in Geode build
[ https://issues.apache.org/jira/browse/GEODE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-10075: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Fix support for jacoco code coverage in Geode build > --- > > Key: GEODE-10075 > URL: https://issues.apache.org/jira/browse/GEODE-10075 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > We haven't been maintaining this gradle build support, but it is useful to be > able to get code coverage from distributed test runs, eg. > ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX > geode-core:jacocoDistributedTestReport > If you pass -PcodeCoverage it's currently failing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10075) Fix support for jacoco code coverage in Geode build
Dan Smith created GEODE-10075: - Summary: Fix support for jacoco code coverage in Geode build Key: GEODE-10075 URL: https://issues.apache.org/jira/browse/GEODE-10075 Project: Geode Issue Type: Bug Components: build Reporter: Dan Smith We haven't been maintaining this gradle build support, but it is useful to be able to get code coverage from distributed test runs, eg. ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX geode-core:jacocoDistributedTestReport If you pass -PcodeCoverage it's currently failing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9964) ExplicitMoveDirector incorrectly compares Member with InternalDistributedMember.
[
https://issues.apache.org/jira/browse/GEODE-9964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480188#comment-17480188
]
Dan Smith commented on GEODE-9964:
--
For the two places listed above, the customer visible impact is that they get a
less informative message with the IllegalStateException that is thrown in this
error case.
> ExplicitMoveDirector incorrectly compares Member with
> InternalDistributedMember.
>
>
> Key: GEODE-9964
> URL: https://issues.apache.org/jira/browse/GEODE-9964
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.2, 1.15.0
>Reporter: Jacob Barrett
>Priority: Major
>
> {{ExplicitMoveDirector}} incorrectly compares {{Member}} with
> {{InternalDistributedMember}} due use of raw types rather than generics. It
> is also likely there is either no testing for this failure case or the test
> is passing for the wrong reasons.
> See
> [here|https://github.com/apache/geode/blob/2b032440eb9d0f3c68a94602289cc41435c68fad/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/ExplicitMoveDirector.java#L93]
> See
> [here|https://github.com/apache/geode/blob/2b032440eb9d0f3c68a94602289cc41435c68fad/geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/rebalance/ExplicitMoveDirector.java#L99]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9925) Update LICENSE and notice for confluent connector
Dan Smith created GEODE-9925: Summary: Update LICENSE and notice for confluent connector Key: GEODE-9925 URL: https://issues.apache.org/jira/browse/GEODE-9925 Project: Geode Issue Type: Bug Components: extensions Reporter: Dan Smith The geode-confluent-connector is bundling geode-core and it's third party dependencies in the binary distribution. The LICENSE and NOTICE for the binary distribution need to reflect this and include information related to third party licenses. See the geode-core LICENSE and NOTICE files for example - [https://github.com/apache/geode/tree/develop/geode-assembly/src/main/dist.] Perhaps we can just copy these in the geode-confluent-connectors LICENSE and NOTICE? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9874) Users need to be able to set hostname-for-clients of the locator using a property
[ https://issues.apache.org/jira/browse/GEODE-9874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-9874: Assignee: Dan Smith > Users need to be able to set hostname-for-clients of the locator using a > property > - > > Key: GEODE-9874 > URL: https://issues.apache.org/jira/browse/GEODE-9874 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > > Currently, the only way to set hostname-for-clients on the locator is using > LocatorLauncher.Builder().setHostnameForClients(), or by passing the > --hostname-for-clients command line parameter. > This is not consistent with all of our other properties, which can be set in > gemfire properties. There is a jmx-hostname-for-clients in the gemfire > properties, but not a hostname-for-clients just for the locator. > We should make this property configurable using gemfire properties, or at > least a java system property. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9874) Users need to be able to set hostname-for-clients of the locator using a property
Dan Smith created GEODE-9874: Summary: Users need to be able to set hostname-for-clients of the locator using a property Key: GEODE-9874 URL: https://issues.apache.org/jira/browse/GEODE-9874 Project: Geode Issue Type: Improvement Reporter: Dan Smith Currently, the only way to set hostname-for-clients on the locator is using LocatorLauncher.Builder().setHostnameForClients(), or by passing the --hostname-for-clients command line parameter. This is not consistent with all of our other properties, which can be set in gemfire properties. There is a jmx-hostname-for-clients in the gemfire properties, but not a hostname-for-clients just for the locator. We should make this property configurable using gemfire properties, or at least a java system property. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies in the same redundancy zone
[ https://issues.apache.org/jira/browse/GEODE-9815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9815: - Summary: Recovering persistent members can result in extra copies of a bucket or two copies in the same redundancy zone (was: Recovering persistent members can result in extra copies of a bucket or two copies int the same redundancy zone) > Recovering persistent members can result in extra copies of a bucket or two > copies in the same redundancy zone > -- > > Key: GEODE-9815 > URL: https://issues.apache.org/jira/browse/GEODE-9815 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Dan Smith >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, needsTriage > > The fix in GEODE-9554 is incomplete for some cases, and it also introduces a > new issue when removing buckets that are over redundancy. > GEODE-9554 and these new issues are all related to using redundancy zones and > having persistent members. > With persistence, when we start up a member with persisted buckets, we always > recover the persisted buckets on startup, regardless of whether redundancy is > already met or what zone the existing buckets are on. This is necessary to > ensure that we can recover all colocated buckets that might be persisted on > the member. > Because recovering these persistent buckets may cause us to go over > redundancy, after we recover from disk, we run a "restore redundancy" task > that actually removes copies of buckets that are over redundancy. > GEODE-9554 addressed one case where we end up removing the last copy of a > bucket from one redundancy zone while leaving two copies in another > redundancy zone. It did so by disallowing the removal of a bucket if it is > the last copy in a redundancy zone. > There are a couple of issues with this approach. > *Problem 1:* We may end up with two copies of the bucket in one zone in some > cases > With a slight tweak to the scenario fixed with GEODE-9554 we can end up never > getting out of the situation where we have two copies of a bucket in the same > zone. > Steps: > 1. Start two redundancy zones A and B with two members each. Bucket 0 is on > member A1 and B1. > 2. Shutdown member A1. > 3. Rebalance - this will create bucket 0 on A2. > 4. Shutdown B1. Revoke it's disk store and delete the data > 5. Startup A1 - it will recover bucket 0. > 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that > situation. > *Problem 2:* We may never delete extra copies of a bucket > The fix for GEODE-9554 introduces a new problem if we have more than 2 > redundancy zones > Steps > 1. Start three redundancy zones A,B,C with one member each. Bucket 0 is on A1 > and B1 > 2. Shutdown A1 > 3. Rebalance - this will create Bucket 0 on C1 > 4. Startup A1 - this will recreate bucket 0 > 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. > I think the overall fix is probably to do something different than prevent > removing the last copy of a bucket from a redundancy zone. Instead, I think > we should do something like this: > 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* > buckets that have two copies in the same zone, as well as any buckets that > are actually over redundancy. > 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra > copies of a bucket in the same zone first > 3. Back out the changes for GEODE-9554 and let the last copy be deleted from > a zone. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies int the same redundancy zone
[ https://issues.apache.org/jira/browse/GEODE-9815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9815: - Description: The fix in GEODE-9554 is incomplete for some cases, and it also introduces a new issue when removing buckets that are over redundancy. GEODE-9554 and these new issues are all related to using redundancy zones and having persistent members. With persistence, when we start up a member with persisted buckets, we always recover the persisted buckets on startup, regardless of whether redundancy is already met or what zone the existing buckets are on. This is necessary to ensure that we can recover all colocated buckets that might be persisted on the member. Because recovering these persistent buckets may cause us to go over redundancy, after we recover from disk, we run a "restore redundancy" task that actually removes copies of buckets that are over redundancy. GEODE-9554 addressed one case where we end up removing the last copy of a bucket from one redundancy zone while leaving two copies in another redundancy zone. It did so by disallowing the removal of a bucket if it is the last copy in a redundancy zone. There are a couple of issues with this approach. *Problem 1:* We may end up with two copies of the bucket in one zone in some cases With a slight tweak to the scenario fixed with GEODE-9554 we can end up never getting out of the situation where we have two copies of a bucket in the same zone. Steps: 1. Start two redundancy zones A and B with two members each. Bucket 0 is on member A1 and B1. 2. Shutdown member A1. 3. Rebalance - this will create bucket 0 on A2. 4. Shutdown B1. Revoke it's disk store and delete the data 5. Startup A1 - it will recover bucket 0. 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that situation. *Problem 2:* We may never delete extra copies of a bucket The fix for GEODE-9554 introduces a new problem if we have more than 2 redundancy zones Steps 1. Start three redundancy zones A,B,C with one member each. Bucket 0 is on A1 and B1 2. Shutdown A1 3. Rebalance - this will create Bucket 0 on C1 4. Startup A1 - this will recreate bucket 0 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. I think the overall fix is probably to do something different than prevent removing the last copy of a bucket from a redundancy zone. Instead, I think we should do something like this: 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* buckets that have two copies in the same zone, as well as any buckets that are actually over redundancy. 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra copies of a bucket in the same zone first 3. Back out the changes for GEODE-9554 and let the last copy be deleted from a zone. was: The fix in GEODE-9554 is incomplete for some cases, and it also introduces a new issue when removing buckets that are over redundancy. GEODE-9554 and these new issues are all related to using redundancy zones and having persistent members. With persistence, when we start up a member with persisted buckets, we always recover the persisted buckets on startup, regardless of whether redundancy is already met or what zone the existing buckets are on. This is necessary to ensure that we can recover all colocated buckets that might be persisted on the member. Because recovering these persistent buckets may cause us to go over redundancy, after we recover from disk, we run a "restore redundancy" task that actually removes copies of buckets that are over redundancy. GEODE-9554 addressed one case where we end up removing the last copy of a bucket from one redundancy zone while leaving two copies in another redundancy zone. It did so by disallowing the removal of a bucket if it is the last copy in a redundancy zone. There are a couple of issues with this approach. *Problem 1:* We may end up with two copies of the bucket in one zone in some cases With a slight tweak to the scenario fixed with GEODE-9554 we can end up never getting out of the situation where we have two copies of a bucket in the same zone. Steps: 1. Start two redundancy zones A and B with two members each. Bucket 0 is on member A1 and B1. 2. Shutdown member A1. 3. Rebalance - this will create bucket 0 on A2. 4. Shutdown B1. Revoke it's disk store and delete the data 5. Startup A1 - it will recover bucket 0. 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that situation. *Problem 2:* We may never delete extra copies of a bucket The fix for GEODE-9554 introduces a new problem if we have more than 2 redundancy zones Steps 1. Start three redundancy zones A,B,C with two members each. Bucket 0 is on A1 and B1> 2. Shutdown A1 3. Rebalance - this will create Bucket 0 on C1 4. Startup A1 - this will recreate bucket 0 5. Now we have bucket 0 on A1, B1,
[jira] [Created] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies int the same redundancy zone
Dan Smith created GEODE-9815: Summary: Recovering persistent members can result in extra copies of a bucket or two copies int the same redundancy zone Key: GEODE-9815 URL: https://issues.apache.org/jira/browse/GEODE-9815 Project: Geode Issue Type: Bug Components: regions Affects Versions: 1.15.0 Reporter: Dan Smith The fix in GEODE-9554 is incomplete for some cases, and it also introduces a new issue when removing buckets that are over redundancy. GEODE-9554 and these new issues are all related to using redundancy zones and having persistent members. With persistence, when we start up a member with persisted buckets, we always recover the persisted buckets on startup, regardless of whether redundancy is already met or what zone the existing buckets are on. This is necessary to ensure that we can recover all colocated buckets that might be persisted on the member. Because recovering these persistent buckets may cause us to go over redundancy, after we recover from disk, we run a "restore redundancy" task that actually removes copies of buckets that are over redundancy. GEODE-9554 addressed one case where we end up removing the last copy of a bucket from one redundancy zone while leaving two copies in another redundancy zone. It did so by disallowing the removal of a bucket if it is the last copy in a redundancy zone. There are a couple of issues with this approach. *Problem 1:* We may end up with two copies of the bucket in one zone in some cases With a slight tweak to the scenario fixed with GEODE-9554 we can end up never getting out of the situation where we have two copies of a bucket in the same zone. Steps: 1. Start two redundancy zones A and B with two members each. Bucket 0 is on member A1 and B1. 2. Shutdown member A1. 3. Rebalance - this will create bucket 0 on A2. 4. Shutdown B1. Revoke it's disk store and delete the data 5. Startup A1 - it will recover bucket 0. 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that situation. *Problem 2:* We may never delete extra copies of a bucket The fix for GEODE-9554 introduces a new problem if we have more than 2 redundancy zones Steps 1. Start three redundancy zones A,B,C with two members each. Bucket 0 is on A1 and B1> 2. Shutdown A1 3. Rebalance - this will create Bucket 0 on C1 4. Startup A1 - this will recreate bucket 0 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. I think the overall fix is probably to do something different than prevent removing the last copy of a bucket from a redundancy zone. Instead, I think we should do something like this: 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* buckets that have two copies in the same zone, as well as any buckets that are actually over redundancy. 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra copies of a bucket in the same zone first> 3. Back out the changes for GEODE-9554 and let the last copy be deleted from a zone. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9814) Add an example of geode-for-redis to the geode examples project
Dan Smith created GEODE-9814: Summary: Add an example of geode-for-redis to the geode examples project Key: GEODE-9814 URL: https://issues.apache.org/jira/browse/GEODE-9814 Project: Geode Issue Type: Improvement Components: redis Reporter: Dan Smith h4. Add an example to the geode-examples project demonstrating how to turn on and use geode-for-redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9813) Move geode-for-redis properties to the geode-for-redis module
[ https://issues.apache.org/jira/browse/GEODE-9813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9813: - Component/s: redis > Move geode-for-redis properties to the geode-for-redis module > - > > Key: GEODE-9813 > URL: https://issues.apache.org/jira/browse/GEODE-9813 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Priority: Major > > The goal is that geode-core should have no references to geode-for-redis > gemfire properties. > This probably involves these steps: > * Change geode-core to support dynamically discovering modules that define > new gemfire properties, perhaps using a service loader or other mechanism. > Update the validation logic of gemfire properties to include these > dynamically discovered properties. > * Move the definition of the geode-for-redis properties to the > geode-for-redis module. This includes moving the public > ConfigurationProperties constants to some new public interface in the > geode-for-redis module. > We should consider deprecating and moving properties for other modules as > well - for example the memcached properties. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9813) Move geode-for-redis properties to the geode-for-redis module
Dan Smith created GEODE-9813: Summary: Move geode-for-redis properties to the geode-for-redis module Key: GEODE-9813 URL: https://issues.apache.org/jira/browse/GEODE-9813 Project: Geode Issue Type: Improvement Reporter: Dan Smith The goal is that geode-core should have no references to geode-for-redis gemfire properties. This probably involves these steps: * Change geode-core to support dynamically discovering modules that define new gemfire properties, perhaps using a service loader or other mechanism. Update the validation logic of gemfire properties to include these dynamically discovered properties. * Move the definition of the geode-for-redis properties to the geode-for-redis module. This includes moving the public ConfigurationProperties constants to some new public interface in the geode-for-redis module. We should consider deprecating and moving properties for other modules as well - for example the memcached properties. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9767) bump netty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-9767: Assignee: Dan Smith > bump netty to recommended version > - > > Key: GEODE-9767 > URL: https://issues.apache.org/jira/browse/GEODE-9767 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > latest is 4.1.69, we should be using 4.1.68 or 4.1.69 on all branches if > possible -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9050) Redis test fails with Netty 4.1.60 and later
[
https://issues.apache.org/jira/browse/GEODE-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440655#comment-17440655
]
Dan Smith commented on GEODE-9050:
--
I tracked this down in 1.14 so we can upgrade netty there. This bug exists in
geode 1.14 but not in the latest geode 1.15 develop. In 1.14, we are changing
the event loop group for a netty channel while threads maybe writing to the
channel in ExecutionHandlerContext.changeChannelEventLoopGroup. This leads to
the below assertion failure with netty 4.1.68 and above. It is unknown what
sort or problems this might cause with the earlier versions of netty without
the assertion:
This exception occurs when running
PubSubIntegrationTest.ensureOrderingOfPublishedMessages after upgrading to
netty 4.1.68 on support/1.14.
{noformat}
[warn 2021/10/27 22:34:47.657 GMT tid=0x3d4]
Failed to execute publish function java.lang.AssertionError
org.apache.geode.cache.execute.FunctionException: java.lang.AssertionError
at
org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.setException(LocalResultCollectorImpl.java:205)
at
org.apache.geode.internal.cache.execute.MemberFunctionResultSender.setException(MemberFunctionResultSender.java:233)
at
org.apache.geode.internal.cache.execute.AbstractExecution.handleException(AbstractExecution.java:504)
at
org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:353)
at
org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionOnLocalNode(AbstractExecution.java:307)
at
org.apache.geode.internal.cache.execute.MemberFunctionExecutor.executeFunction(MemberFunctionExecutor.java:136)
at
org.apache.geode.internal.cache.execute.MemberFunctionExecutor.executeFunction(MemberFunctionExecutor.java:191)
at
org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
at
org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:359)
at
org.apache.geode.redis.internal.pubsub.PubSubImpl.publish(PubSubImpl.java:76)
at
org.apache.geode.redis.internal.executor.pubsub.PublishExecutor.executeCommand(PublishExecutor.java:35)
at
org.apache.geode.redis.internal.RedisCommandType.executeCommand(RedisCommandType.java:335)
at
org.apache.geode.redis.internal.netty.Command.execute(Command.java:188)
at
org.apache.geode.redis.internal.netty.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:315)
at
org.apache.geode.redis.internal.netty.ExecutionHandlerContext.processCommandQueue(ExecutionHandlerContext.java:150)
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:829)
Caused by: java.lang.AssertionError
at
io.netty.handler.timeout.WriteTimeoutHandler.addWriteTimeoutTask(WriteTimeoutHandler.java:144)
at
io.netty.handler.timeout.WriteTimeoutHandler.scheduleTimeout(WriteTimeoutHandler.java:136)
at
io.netty.handler.timeout.WriteTimeoutHandler.write(WriteTimeoutHandler.java:110)
at
io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:717)
at
io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:764)
at
io.netty.channel.AbstractChannelHandlerContext$WriteTask.run(AbstractChannelHandlerContext.java:1071)
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
... 1 more {noformat}
Here is the full sequence of events with geode 1.14.
1. A subscription is created and marked ready to publish
2. In another thread A publish message comes in, starts writing to the channel
of the subscriber
3. Netty uses the executor for the channel to perform the write (executor A)
4. The subcription thread changes the exector of the channel in
changeChannelEventLoopGroup
5. The write eventually hits this assertion that the executor of the write
matches the current executor of the channel. But because we changed the
executor it no longer matches.
Since this is a hard to hit race
[jira] [Updated] (GEODE-9050) Redis test fails with Netty 4.1.60 and later
[
https://issues.apache.org/jira/browse/GEODE-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-9050:
-
Fix Version/s: 1.15.0
> Redis test fails with Netty 4.1.60 and later
>
>
> Key: GEODE-9050
> URL: https://issues.apache.org/jira/browse/GEODE-9050
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {{PubSubIntegrationTest > ensureOrderingOfPublishedMessages}}
> [fails|http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6153/test-results/integrationTest/1616031328/index.html]
> reliably, on both Linux and Windows, if I [bump
> Netty|https://github.com/apache/geode/pull/6153/commits/03b81f93b011377a5021a4b87acecacfa02b93a4]
> from 4.1.59.Final to 4.1.60.Final. It's important to keep up to date with
> latest versions of our 3rd-party dependencies but breaking this out
> separately so someone with redis knowledge can tackle it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9050) Redis test fails with Netty 4.1.60 and later
[
https://issues.apache.org/jira/browse/GEODE-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-9050:
-
Affects Version/s: 1.14.0
> Redis test fails with Netty 4.1.60 and later
>
>
> Key: GEODE-9050
> URL: https://issues.apache.org/jira/browse/GEODE-9050
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> {{PubSubIntegrationTest > ensureOrderingOfPublishedMessages}}
> [fails|http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6153/test-results/integrationTest/1616031328/index.html]
> reliably, on both Linux and Windows, if I [bump
> Netty|https://github.com/apache/geode/pull/6153/commits/03b81f93b011377a5021a4b87acecacfa02b93a4]
> from 4.1.59.Final to 4.1.60.Final. It's important to keep up to date with
> latest versions of our 3rd-party dependencies but breaking this out
> separately so someone with redis knowledge can tackle it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9752) Limit Memory Consumption for Read Operation
[ https://issues.apache.org/jira/browse/GEODE-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17436176#comment-17436176 ] Dan Smith commented on GEODE-9752: -- > it could be better if as we iterate over data structure we start writing the > result I guess I'm not sure if this is doable in a thread safe way or not. We don't want to hold the stripe locked while we are sending data to the client. But we also can't use an iterator from our non threadsafe data structures outside the lock. > Limit Memory Consumption for Read Operation > --- > > Key: GEODE-9752 > URL: https://issues.apache.org/jira/browse/GEODE-9752 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > > The "read" commands can be made more memory friendly by streaming back their > result to netty a "batch" at a time. They can get the netty ByteBuf and write > the result directly to it. Once the buffer contains a certain number of bytes > (say 4k) it do a write and flush. Once that completes it can then use the > same buffer to send the next 4k bytes to the client. Writing the response > directly to the netty ByteBuf will also produce less garbage. The only > downside to it is that the writing will be done while holding the stripe > lock. This probably will not be any slower unless the buffer fills up while > we still hold the lock. The last buffer (the one that is not full) can be > done after the lock is released just as we currently do by returning a > RedisResponse outside the lock and then asking it to write itself to netty. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9764) Request-Response Messaging Should Time Out
[
https://issues.apache.org/jira/browse/GEODE-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-9764:
Assignee: Bill Burcham
> Request-Response Messaging Should Time Out
> --
>
> Key: GEODE-9764
> URL: https://issues.apache.org/jira/browse/GEODE-9764
> Project: Geode
> Issue Type: Improvement
> Components: messaging
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
>
> There is a weakness in the P2P/DirectChannel messaging architecture, in that
> it never gives up on a request (in a request-response scenario). As a result
> a bug (software fault) anywhere from the point where the requesting thread
> hands off the {{DistributionMessage}} e.g. to
> {{ClusterDistributionManager.putOutgoing(DistributionMessage)}}, to the point
> where that request is ultimately fulfilled on a (one) receiver, can result in
> a hang (of some task on the send side, which is waiting for a response).
> Well it's a little worse than that because any code in the return (response)
> path can also cause disruption of the (response) flow, thereby leaving the
> requesting task hanging.
> If the code in the request path (primarily in P2P messaging) and the code in
> the response path (P2P messaging and TBD higher-level code) were perfect this
> might not be a problem. But there is a fair amount of code there and we have
> some evidence that it is currently not perfect, nor do we expect it to become
> perfect and stay that way. That being the case it seems prudent to institute
> response timeouts so that bugs of this sort (which disrupt request-response
> message flow) don't result in hangs.
> It's TBD if we want to go a step further and institute retries. The latter
> would entail introducing duplicate-suppression (conflation) in P2P messaging.
> We might also add exponential backoff (open-loop) or back-pressure
> (closed-loop) to prevent a flood of retries when the system is at or near the
> point of thrashing.
> But even without retries, a configurable timeout might have good ROI as a
> first step. This would entail:
> * adding a configuration parameter to specify the timeout value
> * changing ReplyProcessor21 and others TBD to "give up" after the timeout has
> elapsed
> * changing higher-level code dependent on request-reply messaging so it
> properly handles the situations where we might have to "give up"
> This issue affects all versions of Geode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9752) Limit Memory Consumption for Read Operation
[ https://issues.apache.org/jira/browse/GEODE-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430712#comment-17430712 ] Dan Smith commented on GEODE-9752: -- I think the current behavior in RedisSortedSet, where it returns a List, isn't so bad. Yes, the list can be long, but those byte[] objects are references to the existing members. I think the big problem is that later, when we start sending the response to the client, we serialize the whole thing into one ByteBuf. If we optimize that part of the code and only serlialize and send part of the list at a time I think we can avoid most OOME issues with a large zrange. > Limit Memory Consumption for Read Operation > --- > > Key: GEODE-9752 > URL: https://issues.apache.org/jira/browse/GEODE-9752 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > > The "read" commands can be made more memory friendly by streaming back their > result to netty a "batch" at a time. They can get the netty ByteBuf and write > the result directly to it. Once the buffer contains a certain number of bytes > (say 4k) it do a write and flush. Once that completes it can then use the > same buffer to send the next 4k bytes to the client. Writing the response > directly to the netty ByteBuf will also produce less garbage. The only > downside to it is that the writing will be done while holding the stripe > lock. This probably will not be any slower unless the buffer fills up while > we still hold the lock. The last buffer (the one that is not full) can be > done after the lock is released just as we currently do by returning a > RedisResponse outside the lock and then asking it to write itself to netty. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9740) Use DATA:READ permission for read only redis operations
Dan Smith created GEODE-9740: Summary: Use DATA:READ permission for read only redis operations Key: GEODE-9740 URL: https://issues.apache.org/jira/browse/GEODE-9740 Project: Geode Issue Type: Improvement Components: redis Reporter: Dan Smith We currently require the resource permission DATA:WRITE:GEODE_FOR_REDIS for all redis operations. We would like read only redis operations to only require DATA:READ:GEODE_FOR_REDIS permission. This more closely matches the gemfire operation permission model and allows for creating a user that has only read access to redis. Acceptance Criteria: Users with only DATA:READ permission can execute read only operations. They are denied access when trying to do write operations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9722) Remove the SHUTDOWN redis command
Dan Smith created GEODE-9722: Summary: Remove the SHUTDOWN redis command Key: GEODE-9722 URL: https://issues.apache.org/jira/browse/GEODE-9722 Project: Geode Issue Type: Improvement Components: redis Reporter: Dan Smith This redis command is one of the unsupported operations, which can only be enabled with a system property. Still, we don't want anyone to use this to shutdown a gemfire server and we never intend to add support for it, so we should just delete it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9718) The region is not created on all servers if commands are run in parallel
[ https://issues.apache.org/jira/browse/GEODE-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427785#comment-17427785 ] Dan Smith commented on GEODE-9718: -- I think maybe a better option might be to use a lock for the cluster configuration. We can make the request to get the cluster config wait until the update to the cluster config is completely applied. > The region is not created on all servers if commands are run in parallel > > > Key: GEODE-9718 > URL: https://issues.apache.org/jira/browse/GEODE-9718 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > We are using a system with a large number of servers. > While starting all servers, in parallel, we create a region through gfsh. > The problem is that on one of the servers region is not created. > It is started after the "create region" command is started, so it will not > get information to create a region on itself from the locator. Also, the > cluster configuration doesn't have that information yet, so the server cannot > read it from the received cluster configuration. > So, the problem is in changing cluster configuration whilst servers are > coming up. > The solutions are: > # Add to the documentation to not running commands that doing some changes > on cluster configuration while the server is in starting phase. > # Redesign all commands that can edit the cluster configuration to first > wrote changes to the cluster config and then distribute the commands to all > servers. > The second solution can lead to some problems. When the "create region" > command is executed it got all servers from the view and sends all of them to > start creating a region with parameters specified in the command. > The region creating is started on all servers and after it is finished, it > is added to the cluster configuration. In case there are some problems with > creating a region(wrong parameter used or something else) it will not create > a region on the existing servers and will not write anything in a cluster > configuration. > In case we decide to change order, it will write in the cluster config > before the command is successful, and then we should have some backup to > rollback cluster configuration. Also, this will affects all commands that do > changes in cluster config. > > Mail discussion: [Region is not created on one of the > servers|https://markmail.org/message/q4zanaklz7osgx4j#query:+page:1+mid:q4zanaklz7osgx4j+state:results] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9680) Newly Started/Restarted Locators are Susceptible to Split-Brains
[
https://issues.apache.org/jira/browse/GEODE-9680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-9680:
-
Labels: (was: needsTriage)
> Newly Started/Restarted Locators are Susceptible to Split-Brains
>
>
> Key: GEODE-9680
> URL: https://issues.apache.org/jira/browse/GEODE-9680
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> The issues described here are present in all versions of Geode (this is not
> new to 1.15.0)…
> Geode is built on the assumption that views progress linearly in a sequence.
> If that sequence ever forks into two or more parallel lines then we have a
> "split brain".
> In a split brain condition, each of the parallel views are independent. It's
> as if you have more than one system running concurrently. It's possible e.g.
> for some clients to connect to members of one view and other clients to
> connect to members of another view. Updates to members in one view are not
> seen by members of a parallel view.
> Geode views are produced by a coordinator. As long as only a single
> coordinator is running, there is no possibility of a split brain. Split brain
> arises when more than one coordinator is producing views at the same time.
> Each Geode member (peer) is started with the {{locators}} configuration
> parameter. That parameter specifies locator(s) to use to find the (already
> running!) coordinator (member) to join with.
> When a locator (member) starts, it goes through this sequence to find the
> coordinator:
> # it first tries to find the coordinator through one of the (other)
> configured locators
> # if it can't contact any of those, it tries contacting non-locator (cache
> server) members it has retrieved from the "view presistence" ({{.dat}}) file
> If it hasn't found a coordinator to join with, then the locator may _become_
> a coordinator.
> Sometimes this is ok. If no other coordinator is currently running then this
> behavior is fine. An example is when an [administrator is starting up a brand
> new
> cluster|https://geode.apache.org/docs/guide/114/configuring/running/running_the_locator.html].
> In that case we want the very first locator we start to become the
> coordinator.
> But there are a number of situations where there may already be another
> coordinator running but it cannot be reached:
> * if the administrator/operator is starting up a brand new cluster with
> multiple locators and…
> ** maybe Geode is running in a managed environment like Kubernetes and the
> locators hostnames are not (yet) resolvable in DNS
> ** maybe there is a network partition between the starting locators so they
> can't communicate
> ** maybe the existing locators or coordinator are running very slowly or the
> network is degraded. This is effectively the same as the network partition
> just mentioned
> * if a cluster is already running and the administrator/operator wants to
> scale it up by starting/adding a new locator Geode is susceptible to that
> same network partition issue
> * if a cluster is already running and the administrator/operator needs to
> restart a locator, e.g. for a rolling upgrade, if none of the locators in the
> {{locators}} configuration parameter are reachable (maybe they are not
> running, or maybe there is a network partition) and…
> ** if the "view persistence" {{.dat}} file is missing or deleted
> ** or if the current set of running Geode members has evolved so far that
> the coordinates (host+port) in the {{.dat}} file are completely out of date
> In each of those cases, the newly starting locator will become a coordinator
> and will start producing views. Now we'll have the old coordinator producing
> views at the same time as the new one.
> *When this ticket is complete*, Geode will offer a locator startup mode (via
> TBD {{LocatorLauncher}} startup parameter) that prevents that locator from
> becoming a coordinator. With that mode, it will be possible for an
> administrator/operator to avoid many of the problematic scenarios mentioned
> above, while retaining the ability to start a first locator which is allowed
> to become a coordinator.
> For purposes of discussion we'll call the startup mode that allows the
> locator to become a coordinator "seed" mode, and we'll call the new startup
> mode that prevents the locator from becoming a coordinator before first
> joining, "join-only" mode.
> To start a brand new cluster, an administrator/operator starts the first
> locator in "seed" mode. After that the operator starts all subsequent
> locators in "join only" mode. If network partitions occur during startup,
> those newly started nodes will exit with a failure status, but will not
[jira] [Commented] (GEODE-9680) Newly Started/Restarted Locators are Susceptible to Split-Brains
[
https://issues.apache.org/jira/browse/GEODE-9680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425195#comment-17425195
]
Dan Smith commented on GEODE-9680:
--
Not a blocker for 1.15.
> Newly Started/Restarted Locators are Susceptible to Split-Brains
>
>
> Key: GEODE-9680
> URL: https://issues.apache.org/jira/browse/GEODE-9680
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> The issues described here are present in all versions of Geode (this is not
> new to 1.15.0)…
> Geode is built on the assumption that views progress linearly in a sequence.
> If that sequence ever forks into two or more parallel lines then we have a
> "split brain".
> In a split brain condition, each of the parallel views are independent. It's
> as if you have more than one system running concurrently. It's possible e.g.
> for some clients to connect to members of one view and other clients to
> connect to members of another view. Updates to members in one view are not
> seen by members of a parallel view.
> Geode views are produced by a coordinator. As long as only a single
> coordinator is running, there is no possibility of a split brain. Split brain
> arises when more than one coordinator is producing views at the same time.
> Each Geode member (peer) is started with the {{locators}} configuration
> parameter. That parameter specifies locator(s) to use to find the (already
> running!) coordinator (member) to join with.
> When a locator (member) starts, it goes through this sequence to find the
> coordinator:
> # it first tries to find the coordinator through one of the (other)
> configured locators
> # if it can't contact any of those, it tries contacting non-locator (cache
> server) members it has retrieved from the "view presistence" ({{.dat}}) file
> If it hasn't found a coordinator to join with, then the locator may _become_
> a coordinator.
> Sometimes this is ok. If no other coordinator is currently running then this
> behavior is fine. An example is when an [administrator is starting up a brand
> new
> cluster|https://geode.apache.org/docs/guide/114/configuring/running/running_the_locator.html].
> In that case we want the very first locator we start to become the
> coordinator.
> But there are a number of situations where there may already be another
> coordinator running but it cannot be reached:
> * if the administrator/operator is starting up a brand new cluster with
> multiple locators and…
> ** maybe Geode is running in a managed environment like Kubernetes and the
> locators hostnames are not (yet) resolvable in DNS
> ** maybe there is a network partition between the starting locators so they
> can't communicate
> ** maybe the existing locators or coordinator are running very slowly or the
> network is degraded. This is effectively the same as the network partition
> just mentioned
> * if a cluster is already running and the administrator/operator wants to
> scale it up by starting/adding a new locator Geode is susceptible to that
> same network partition issue
> * if a cluster is already running and the administrator/operator needs to
> restart a locator, e.g. for a rolling upgrade, if none of the locators in the
> {{locators}} configuration parameter are reachable (maybe they are not
> running, or maybe there is a network partition) and…
> ** if the "view persistence" {{.dat}} file is missing or deleted
> ** or if the current set of running Geode members has evolved so far that
> the coordinates (host+port) in the {{.dat}} file are completely out of date
> In each of those cases, the newly starting locator will become a coordinator
> and will start producing views. Now we'll have the old coordinator producing
> views at the same time as the new one.
> *When this ticket is complete*, Geode will offer a locator startup mode (via
> TBD {{LocatorLauncher}} startup parameter) that prevents that locator from
> becoming a coordinator. With that mode, it will be possible for an
> administrator/operator to avoid many of the problematic scenarios mentioned
> above, while retaining the ability to start a first locator which is allowed
> to become a coordinator.
> For purposes of discussion we'll call the startup mode that allows the
> locator to become a coordinator "seed" mode, and we'll call the new startup
> mode that prevents the locator from becoming a coordinator before first
> joining, "join-only" mode.
> To start a brand new cluster, an administrator/operator starts the first
> locator in "seed" mode. After that the operator starts all subsequent
> locators in "join only" mode. If network partitions occur during startup,
> those newly started nodes will exit with
[jira] [Updated] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9636: - Labels: GeodeOperationAPI blocks-1.15.0 (was: GeodeOperationAPI) > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9585) Add support for the KEYSLOT command
[ https://issues.apache.org/jira/browse/GEODE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9585. -- Fix Version/s: 1.15.0 Resolution: Fixed > Add support for the KEYSLOT command > --- > > Key: GEODE-9585 > URL: https://issues.apache.org/jira/browse/GEODE-9585 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Spring data redis's JedisClusterKeyCommands class unfortunately is calling > the CLUSTER KEYSLOT command on the server to find the slot for a key when > performing rename or restore operations. Rename is used by spring session > data redis. > I'll file a PR against jedis, but in the meantime we should add support for > the KEYSLOT command to handle this and other weird client behaviors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9585) Add support for the KEYSLOT command
[ https://issues.apache.org/jira/browse/GEODE-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-9585: Assignee: Dan Smith (was: Eric Zoerner) > Add support for the KEYSLOT command > --- > > Key: GEODE-9585 > URL: https://issues.apache.org/jira/browse/GEODE-9585 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > > Spring data redis's JedisClusterKeyCommands class unfortunately is calling > the CLUSTER KEYSLOT command on the server to find the slot for a key when > performing rename or restore operations. Rename is used by spring session > data redis. > I'll file a PR against jedis, but in the meantime we should add support for > the KEYSLOT command to handle this and other weird client behaviors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9170) Support ZGC
[ https://issues.apache.org/jira/browse/GEODE-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9170: - Labels: (was: blocks-1.15.0) > Support ZGC > --- > > Key: GEODE-9170 > URL: https://issues.apache.org/jira/browse/GEODE-9170 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > Our performance research indicated that throughput improved by 13% by using > the Z Garbage Collector. > In addition to use of ZGC, we also need to rework the ResourceManager. > The ResourceManager is monitoring the MBeans related to GC and trying to > guestimate how much memory is being used. Based upon heap usage, and user > configured thresholds, the user can configure eviction. > Exceeding the Critical threshold will stop puts. When can add support for > ZGC by looking at the correct MBeans for ZGC. Alternatively, we can stop > using the ResourceManager and find a new way of monitoring heap. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9585) Add support for the KEYSLOT command
Dan Smith created GEODE-9585: Summary: Add support for the KEYSLOT command Key: GEODE-9585 URL: https://issues.apache.org/jira/browse/GEODE-9585 Project: Geode Issue Type: Improvement Components: redis Reporter: Dan Smith Spring data redis's JedisClusterKeyCommands class unfortunately is calling the CLUSTER KEYSLOT command on the server to find the slot for a key when performing rename or restore operations. Rename is used by spring session data redis. I'll file a PR against jedis, but in the meantime we should add support for the KEYSLOT command to handle this and other weird client behaviors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9320) CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406941#comment-17406941
]
Dan Smith commented on GEODE-9320:
--
The latest port conflict failure seems to be before we even get to the redis
container. It is trying to start the "ryuk" container, which I guess is used
for cleaning up after tests? However, this command itself is just passing a
list of exposed ports to docker and asking docker to assign random host ports
to these exposed ports. At a guess this looks like a docker bug.
This is the code in testcontainers that is failing.
{code:java}
String ryukContainerId = client.createContainerCmd(ryukImage)
.withHostConfig(new HostConfig().withAutoRemove(true))
.withExposedPorts(new ExposedPort(8080))
.withPublishAllPorts(true)
.withName("testcontainers-ryuk-" + DockerClientFactory.SESSION_ID)
.withLabels(Collections.singletonMap(DockerClientFactory.TESTCONTAINERS_LABEL,
"true"))
.withBinds(binds)
.withPrivileged(TestcontainersConfiguration.getInstance().isRyukPrivileged())
.exec()
.getId(); {code}
> CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
> ---
>
> Key: GEODE-9320
> URL: https://issues.apache.org/jira/browse/GEODE-9320
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: flaky-test
>
> {noformat}
> org.apache.geode.redis.internal.executor.string.SetNXNativeRedisAcceptanceTest
> > classMethod FAILED
> 13:40:47org.testcontainers.containers.ContainerLaunchException: Container
> startup failed
> 13:40:47at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.startAmbassadorContainers(DockerComposeContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:178)
> 13:40:47at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:85)
> 13:40:47at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 13:40:47at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 13:40:47at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
> 13:40:47at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
> 13:40:47at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
>
[jira] [Comment Edited] (GEODE-9320) CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404768#comment-17404768
]
Dan Smith edited comment on GEODE-9320 at 8/25/21, 11:30 PM:
-
Note, the most recent failure was not a port conflict but this error message.
Reopened GEODE-5252 for that. Leaving this open for the original port conflict
for now.
{noformat}
org.junit.ComparisonFailure: [Incorrect primary node count] expected:<[3]> but
was:<[2]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.redis.NativeRedisClusterTestRule.waitForPrimaries(NativeRedisClusterTestRule.java:156)
at
org.apache.geode.redis.NativeRedisClusterTestRule.access$100(NativeRedisClusterTestRule.java:44)
at
org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:91)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.lang.Thread.run(Thread.java:829)
{noformat}
was (Author: upthewaterspout):
Note, the most recent failure was not a port conflict but this error message
{noformat}
org.junit.ComparisonFailure: [Incorrect primary node count] expected:<[3]> but
was:<[2]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
[jira] [Reopened] (GEODE-9252) CI failure: NativeRedisClusterTestRule incorrect primary node count (expected 3 but was 2)
[
https://issues.apache.org/jira/browse/GEODE-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reopened GEODE-9252:
--
This happened again. Was reported against GEODE-9320 but is actually this issue.
Seen in [acceptance-test-openjdk11
#145|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/145]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0434/test-results/acceptanceTest/1629852506/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0434/test-artifacts/1629852506/acceptancetestfiles-openjdk11-1.15.0-build.0434.tgz].
> CI failure: NativeRedisClusterTestRule incorrect primary node count (expected
> 3 but was 2)
> --
>
> Key: GEODE-9252
> URL: https://issues.apache.org/jira/browse/GEODE-9252
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HashesNativeRedisAcceptanceTest
> > classMethod FAILED
> org.junit.ComparisonFailure: [Incorrect primary node count]
> expected:<[3]> but was:<[2]>
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:93)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9252) CI failure: NativeRedisClusterTestRule incorrect primary node count (expected 3 but was 2)
[
https://issues.apache.org/jira/browse/GEODE-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404778#comment-17404778
]
Dan Smith commented on GEODE-9252:
--
On the face of it, 5 seconds seems like too short of a time to avoid having
flaky tests on a CI machine. Maybe we should just up the timeout where we are
waiting for primary nodes?
> CI failure: NativeRedisClusterTestRule incorrect primary node count (expected
> 3 but was 2)
> --
>
> Key: GEODE-9252
> URL: https://issues.apache.org/jira/browse/GEODE-9252
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HashesNativeRedisAcceptanceTest
> > classMethod FAILED
> org.junit.ComparisonFailure: [Incorrect primary node count]
> expected:<[3]> but was:<[2]>
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:93)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9320) CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404768#comment-17404768
]
Dan Smith commented on GEODE-9320:
--
Note, the most recent failure was not a port conflict but this error message
{noformat}
org.junit.ComparisonFailure: [Incorrect primary node count] expected:<[3]> but
was:<[2]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.redis.NativeRedisClusterTestRule.waitForPrimaries(NativeRedisClusterTestRule.java:156)
at
org.apache.geode.redis.NativeRedisClusterTestRule.access$100(NativeRedisClusterTestRule.java:44)
at
org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:91)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.lang.Thread.run(Thread.java:829)
{noformat}
> CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
> ---
>
> Key: GEODE-9320
> URL: https://issues.apache.org/jira/browse/GEODE-9320
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: flaky-test
>
> {noformat}
>
[jira] [Updated] (GEODE-8719) CI Failure: org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest > givenServerCrashesDuringAPPEND_thenDataIsNotLost
[
https://issues.apache.org/jira/browse/GEODE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-8719:
-
Fix Version/s: 1.15.0
> CI Failure:
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost
> -
>
> Key: GEODE-8719
> URL: https://issues.apache.org/jira/browse/GEODE-8719
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Sarah Abbey
>Assignee: Jens Deppe
>Priority: Minor
> Labels: flaky-test
> Fix For: 1.15.0
>
>
> CI failure: https://concourse.apachegeode-ci.info/builds/207449
> {code:java}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 2
> running on Host e0e2f6af9445 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:460)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:268)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:261)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.startRedisVM(CrashAndNoRepeatDUnitTest.java:131)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.givenServerCrashesDuringAPPEND_thenDataIsNotLost(CrashAndNoRepeatDUnitTest.java:164)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> Redis Server using bind address: localhost/127.0.0.1 and port: 44579. Please
> make sure nothing else is running on this address/port combination.
> Caused by:
> java.net.BindException: Address already in use
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8719) CI Failure: org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest > givenServerCrashesDuringAPPEND_thenDataIsNotLost
[
https://issues.apache.org/jira/browse/GEODE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-8719.
--
Resolution: Won't Fix
This test was deleted a while ago as part of
198f66489d842994abbcbabd621c3ed6f4d8c730. Closing this ticket.
> CI Failure:
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost
> -
>
> Key: GEODE-8719
> URL: https://issues.apache.org/jira/browse/GEODE-8719
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Sarah Abbey
>Assignee: Jens Deppe
>Priority: Minor
> Labels: flaky-test
>
> CI failure: https://concourse.apachegeode-ci.info/builds/207449
> {code:java}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 2
> running on Host e0e2f6af9445 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:460)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:268)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:261)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.startRedisVM(CrashAndNoRepeatDUnitTest.java:131)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.givenServerCrashesDuringAPPEND_thenDataIsNotLost(CrashAndNoRepeatDUnitTest.java:164)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> Redis Server using bind address: localhost/127.0.0.1 and port: 44579. Please
> make sure nothing else is running on this address/port combination.
> Caused by:
> java.net.BindException: Address already in use
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9509) CI Failure: RedisPartitionResolverDUnitTest fails with suspect strings
[
https://issues.apache.org/jira/browse/GEODE-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-9509:
-
Fix Version/s: 1.15.0
> CI Failure: RedisPartitionResolverDUnitTest fails with suspect strings
> --
>
> Key: GEODE-9509
> URL: https://issues.apache.org/jira/browse/GEODE-9509
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.internal.cluster.RedisPartitionResolverDUnitTest >
> classMethod 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 713
> [fatal 2021/08/14 18:02:15.696 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 777
> [fatal 2021/08/14 18:02:28.025 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 785
> [fatal 2021/08/14 18:02:28.028 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 793
> [fatal 2021/08/14 18:02:28.064 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Hit occurrence limit of 5 for this string.
> Further reporting of this type of error will be suppressed.
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
>
[jira] [Resolved] (GEODE-9509) CI Failure: RedisPartitionResolverDUnitTest fails with suspect strings
[
https://issues.apache.org/jira/browse/GEODE-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9509.
--
Resolution: Duplicate
This is a duplicate of GEODE-9537. I double checked the progress files, as Jens
suggested, and I see that CqDataUsingPoolOptimizedExecuteDUnitTest was running
at the same time, which will cause this "Improperly configured client" error
message.
> CI Failure: RedisPartitionResolverDUnitTest fails with suspect strings
> --
>
> Key: GEODE-9509
> URL: https://issues.apache.org/jira/browse/GEODE-9509
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> org.apache.geode.redis.internal.cluster.RedisPartitionResolverDUnitTest >
> classMethod 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 713
> [fatal 2021/08/14 18:02:15.696 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 777
> [fatal 2021/08/14 18:02:28.025 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 785
> [fatal 2021/08/14 18:02:28.028 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 793
> [fatal 2021/08/14 18:02:28.064 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Hit occurrence limit of 5 for this string.
> Further reporting of this type of error will be suppressed.
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
[jira] [Resolved] (GEODE-9319) CI failure: session.NativeRedisSessionExpirationAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-9319.
--
Fix Version/s: 1.15.0
Resolution: Duplicate
Resolving this as a duplicate of GEODE-9490. This is the same suspect string
from the RedisProxy, which will now be ignored after with the fix for
GEODE-9490.
> CI failure: session.NativeRedisSessionExpirationAcceptanceTest > classMethod
> FAILED
> ---
>
> Key: GEODE-9319
> URL: https://issues.apache.org/jira/browse/GEODE-9319
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: flaky-test
> Fix For: 1.15.0
>
>
> {noformat}
> session.NativeRedisSessionExpirationAcceptanceTest > classMethod FAILED
> 14:17:23java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 14:17:23Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 14:17:23
> ---
> 14:17:23Found suspect string in 'dunit_suspect-local.log' at line 287
> 14:17:23
> 14:17:23[error 2021/05/26 21:17:10.762 UTC tid=92]
> Failed to return response on inboundChannel
> 14:17:23io.netty.channel.StacklessClosedChannelException
> 14:17:23 at
> io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object,
> ChannelPromise)(Unknown Source)
> 14:17:23at org.junit.Assert.fail(Assert.java:89)
> 14:17:23at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> 14:17:23at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:185)
> 14:17:23at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:69)
> 14:17:23at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:140)
> 14:17:23at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 14:17:23at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 14:17:23at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 14:17:23at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 14:17:23at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 14:17:23at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 14:17:23at java.lang.reflect.Method.invoke(Method.java:566)
> 14:17:23at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 14:17:23at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 14:17:23at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
> 14:17:23at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
> 14:17:23at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
> 14:17:23at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 14:17:23at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 14:17:23at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 14:17:23at java.lang.reflect.Method.invoke(Method.java:566)
> 14:17:23at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 14:17:23at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 14:17:23at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
> 14:17:23at
>
[jira] [Updated] (GEODE-9547) Enable Redis Server to Authorize Using Security Manager
[ https://issues.apache.org/jira/browse/GEODE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9547: - Description: Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. The ResourcePermission passed to the authorize method should be the same for all operations. The actual permission string is TBD - perhaps DATA:WRITE:REDIS_DATA ?? In the future we may provide more fine grained support with different ResourcePermissions for different redis operations. +Acceptance Criteria+ TBD was: Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. The ResourcePermission passed to the authorize method should be the same for all operations. The actual permission string is TBD - perhaps DATA:*:GEODE_FOR_REDIS_DATA ?? In the future we may provide more find grained support with different ResourcePermissions for different redis operations. +Acceptance Criteria+ TBD > Enable Redis Server to Authorize Using Security Manager > --- > > Key: GEODE-9547 > URL: https://issues.apache.org/jira/browse/GEODE-9547 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > Every Redis Command/API invocation must be authorized against the customer > provided Security Manager. > > The SecurityManager.authorize method must be called for every Redis API call > using the principal returned by the SecurityManager.authenticate method > during the authentication process. > The ResourcePermission passed to the authorize method should be the same for > all operations. The actual permission string is TBD - perhaps > DATA:WRITE:REDIS_DATA ?? In the future we may provide more fine grained > support with different ResourcePermissions for different redis operations. > +Acceptance Criteria+ > TBD > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9546: - Description: The Redis [AUTH|https://redis.io/commands/auth] command must be integrated with the Geode SecurityManager. # Remove the Geode property compatible-with-redis-password that currently being used for the Redis password. # Add a new geode property for the Redis default user ID, compatible-with-redis-username # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the user (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. If the AUTH command was called without a user the value of compatible-with-redis-user should be used. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ When a security manager is configured, redis clients that don't AUTH with a valid password cannot perform operations. Redis clients that do AUTH with a valid password can perform redis operations. was: The Redis [AUTH|https://redis.io/commands/auth] command must be integrated with the Geode SecurityManager. # Remove the Geode property _compatible-with-redis-password_, that is currently being used for the Redis password. # Add a new geode property for the Redis default user ID, _compatible-with-redis-user_ # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the Redis user (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException.** # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. ** When the AUTH command is provided with a single argument, e.g. _AUTH xx_, the +xx+ is interpreted as a password and the default Redis user is used for authentication. When the command is provided with two arguments, e.g. AUTH xx yy, xx is interpreted as a user name and yy is interpreted as the password. +Acceptance Criteria+ When a security manager is configured, Redis clients that don't AUTH with a valid password cannot perform operations. Redis clients that do AUTH with a valid password can perform Redis operations. Until we support ACLs, issuing the AUTH command with more than two arguments is invalid. Appropriate tests written to ensure correct behavior and avoid regressions. > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > The Redis [AUTH|https://redis.io/commands/auth] command must be integrated > with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID, > compatible-with-redis-username > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the user (security-username > property) and the user provided password (security-password property) and > properly handle the AuthenticationFailedException. If the AUTH command was > called without a user the value of compatible-with-redis-user should be used. > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > +Acceptance Criteria+ > > When a security manager is configured, redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform redis operations. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9546: - Description: The Redis [AUTH|https://redis.io/commands/auth] command must be integrated with the Geode SecurityManager. # Remove the Geode property compatible-with-redis-password that currently being used for the Redis password. # Add a new geode property for the Redis default user ID, compatible-with-redis-user # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the user (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. If the AUTH command was called without a user the value of compatible-with-redis-user should be used. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ When a security manager is configured, redis clients that don't AUTH with a valid password cannot perform operations. Redis clients that do AUTH with a valid password can perform redis operations. was: The Redis [AUTH|https://redis.io/commands/auth] command must be integrated with the Geode SecurityManager. # Remove the Geode property compatible-with-redis-password that currently being used for the Redis password. # Add a new geode property for the Redis default user ID, compatible-with-redis-user # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ When a security manager is configured, redis clients that don't AUTH with a valid password cannot perform operations. Redis clients that do AUTH with a valid password can perform redis operations. > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > The Redis [AUTH|https://redis.io/commands/auth] command must be integrated > with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID, > compatible-with-redis-user > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the user (security-username > property) and the user provided password (security-password property) and > properly handle the AuthenticationFailedException. If the AUTH command was > called without a user the value of compatible-with-redis-user should be used. > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > +Acceptance Criteria+ > > When a security manager is configured, redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform redis operations. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9547) Enable Redis Server to Authorize Using Security Manager
[ https://issues.apache.org/jira/browse/GEODE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9547: - Description: Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. The ResourcePermission passed to the authorize method should be the same for all operations. The actual permission string is TBD - perhaps DATA:*:GEODE_FOR_REDIS_DATA ?? In the future we may provide more find grained support with different ResourcePermissions for different redis operations. +Acceptance Criteria+ TBD was: Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. +Acceptance Criteria+ TBD > Enable Redis Server to Authorize Using Security Manager > --- > > Key: GEODE-9547 > URL: https://issues.apache.org/jira/browse/GEODE-9547 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > Every Redis Command/API invocation must be authorized against the customer > provided Security Manager. > > The SecurityManager.authorize method must be called for every Redis API call > using the principal returned by the SecurityManager.authenticate method > during the authentication process. > The ResourcePermission passed to the authorize method should be the same for > all operations. The actual permission string is TBD - perhaps > DATA:*:GEODE_FOR_REDIS_DATA ?? In the future we may provide more find grained > support with different ResourcePermissions for different redis operations. > +Acceptance Criteria+ > TBD > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9546: - Description: The Redis [AUTH|https://redis.io/commands/auth] command must be implemented and and integrated with the Geode SecurityManager. # Remove the Geode property compatible-with-redis-password that currently being used for the Redis password. # Add a new geode property for the Redis default user ID. # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ When a security manager is configured, redis clients that don't AUTH with a valid password cannot perform operations. Redis clients that do AUTH with a valid password can perform redis operations. was: The Redis [AUTH|https://redis.io/commands/auth] command must be implemented and and integrated with the Geode SecurityManager. # Remove the system property currently being used for the Redis password. # Add a new system property for the Redis default user ID. # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ TBD > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > The Redis [AUTH|https://redis.io/commands/auth] command must be implemented > and and integrated with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID. > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the default Redis User > (security-username property) and the user provided password > (security-password property) and properly handle the > AuthenticationFailedException. > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > +Acceptance Criteria+ > > When a security manager is configured, redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform redis operations. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9544) Update Certificate Used by Redis Server when Keystore Changes
[ https://issues.apache.org/jira/browse/GEODE-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9544: - Description: When the TLS/SSL Certificate changes in the Java keystore, we want to be able to automatically update the certificate, used by the server for TLS/SSL, without requiring a restart of the server. Although some changes will be necessary, we should be able to reuse much of the work already implemented by the as part of GEODE-9017 and translate to the appropriate Netty semantics. _Acceptance Criteria_ A change in the TLS/SSL Certificate, in the keystore, is detected and automatically applied to the server without requiring a server restart. Appropriate tests are written to ensure that this feature works and is not regressed. was: When the TLS/SSL Certificate changes in the Java keystore, we want to be able to automatically update the certificate, used by the server for TLS/SSL, without requiring a restart of the server. Although some changes will be necessary, we should be able to reuse much of the work already implemented by the [K8s team|http://https//issues.apache.org/jira/browse/GEODE-9017] and translate to the appropriate Netty semantics. _Acceptance Criteria_ A change in the TLS/SSL Certificate, in the keystore, is detected and automatically applied to the server without requiring a server restart. Appropriate tests are written to ensure that this feature works and is not regressed. > Update Certificate Used by Redis Server when Keystore Changes > - > > Key: GEODE-9544 > URL: https://issues.apache.org/jira/browse/GEODE-9544 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the TLS/SSL Certificate changes in the Java keystore, we want to be able > to automatically update the certificate, used by the server for TLS/SSL, > without requiring a restart of the server. > Although some changes will be necessary, we should be able to reuse much of > the work already implemented by the as part of GEODE-9017 and translate to > the appropriate Netty semantics. > > _Acceptance Criteria_ > A change in the TLS/SSL Certificate, in the keystore, is detected and > automatically applied to the server without requiring a server restart. > > Appropriate tests are written to ensure that this feature works and is not > regressed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9542: - Description: When the ssl-require-authentication Geode property is set to true, we should validate the Redis client's certificate against the configured ssl-truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the Geode property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. was: When the ssl-require-authentication gemfire property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the system property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the ssl-require-authentication Geode property is set to true, we should > validate the Redis client's certificate against the configured ssl-truststore > to ensure that the client certificate is issued by a trusted Certificate > Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the Geode property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9542: - Description: When the ssl-require-authentication gemfire property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the system property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. was: When the ssl-require-authentication system property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the system property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the ssl-require-authentication gemfire property is set to true, we > should validate the Redis client's certificate against the Java truststore to > ensure that the client certificate is issued by a trusted Certificate > Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the system property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9530) CI Failure: ClassNotFoundException in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
[
https://issues.apache.org/jira/browse/GEODE-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403931#comment-17403931
]
Dan Smith commented on GEODE-9530:
--
I suggest we remove this as a 1.14 blocker. This looks like a test and/or
pipeline issue - the test didn't even get a chance to run - it got a
ClassNotFoundException on the test class itself!
I also wonder if this was fixed by later build changes. For example
3c3cbe4721f7b4d2d8f37182e90ae2061bcb742f fixed some dependencies in the build
for upgradeTests - maybe related?
> CI Failure: ClassNotFoundException in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> -
>
> Key: GEODE-9530
> URL: https://issues.apache.org/jira/browse/GEODE-9530
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: blocks-1.14.0
>
> {noformat}
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> > initializationError FAILED
> java.lang.ClassNotFoundException:
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:67)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
>
[jira] [Commented] (GEODE-9463) Default serialization filter rejects SerializableRegionRedundancyStatusImpl
[
https://issues.apache.org/jira/browse/GEODE-9463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17390803#comment-17390803
]
Dan Smith commented on GEODE-9463:
--
Eric and I tracked this down. This restore redundancy operation has had this
problem since it was added in 1.13. The problem is that this
SerializableRegionRedundancyStatusImpl is nested inside of an OperationState.
OperationState is java serializable *only* - it is not
DataSerializableFixedID. Because OperationState is java serializable, anything
nested inside it is also uses java serialization.
Someone added OperationState to the sanctioned-geode-core-serializables.txt.
That is why we don't see a failure for that class.
We really should not ever use java serialization in the product. Unfortunately
because we have already released this code with java serialization, we may have
to simply add SerializableRegionRedundancyStatusImpl to the
sanctioned-geode-core-serializables.txt.
There is a test to reproduce this issue here -
https://github.com/upthewaterspout/geode/pull/new/feature/restore-serializable-filter-block-GEODE-9463
> Default serialization filter rejects SerializableRegionRedundancyStatusImpl
> ---
>
> Key: GEODE-9463
> URL: https://issues.apache.org/jira/browse/GEODE-9463
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Aaron Lindsey
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0
> Attachments: logs-1.tgz, logs-2.tgz
>
>
> When validate-serializable-objects=true, there are exceptions in the logs
> related to serializing the class SerializableRegionRedundancyStatusImpl. This
> is an internal class which should be allowed by the default serializable
> object filter.
> We saw this issue happen on Kubernetes while invoking rebalance and restore
> redundancy operations on the cluster. I attached logs from 2 separate test
> failures due to this issue.
> {code:java}
> [fatal 2021/07/22 00:14:31.392 GMT system-test-gemfire-locator-1
> tid=0x51] Serialization filter is rejecting class
> org.apache.geode.internal.cache.control.SerializableRegionRedundancyStatusImpljava.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy23.checkInput(Unknown Source)at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:451)
>at java.base/java.util.HashMap.readObject(HashMap.java:1460)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
> java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1175)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2325)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2464)
> at
> java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2358)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2196)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> at
> java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:493)
> at
