[jira] [Assigned] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales reassigned GEODE-10010:
--
Assignee: (was: Hale Bales)
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Priority: Major
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> 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)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9706) OutOfMemoryDUnitTest can be improved
[
https://issues.apache.org/jira/browse/GEODE-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-9706:
--
Assignee: Donal Evans
> OutOfMemoryDUnitTest can be improved
>
>
> Key: GEODE-9706
> URL: https://issues.apache.org/jira/browse/GEODE-9706
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Darrel Schneider
>Assignee: Donal Evans
>Priority: Minor
>
> Kirk Lund made the following suggestions for improving OutOfMemoryDUnitTest:
> You might want to consider using ExecutorServiceRule or
> DistributedExecutorServiceRule with a CompletableFuture instead of directly
> using a thread:
> {code:java}
> @Rule
> public ExecutorServiceRule executorServiceRule = new ExecutorServiceRule();
> CompletableFuture memoryPressure = executorServiceRule.runAsync(()
> -> {
> try {
> while (true) {
> Thread.sleep(1000);
> }
> } catch (InterruptedException e) {
> // done
> }
> });
> // do something
> memoryPressure.cancel(true);
> {code}
> The cancel(true) will interrupt the thread. If the test throws before that,
> ExecutorServiceRule will clean up any threads during tear down by invoking
> shutdownNow which will also interrupt any running threads. If the thread
> resists interrupt and hangs, the rule should print a stack trace for it as a
> test failure which would then make it easy to debug.
> ExecutorServiceRule will work well within the controller JVM. If you need a
> version of the rule that works within any JVM in a dunit test, then use
> DistributedExecutorServiceRule.
> Also when the test does a "join()" add a timeout like so:
> {code:java}
> join(GeodeAwaitility.getTimeout().getSeconds(), TimeUnit.SECONDS);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9833) SPOP Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486160#comment-17486160 ] ASF subversion and git services commented on GEODE-9833: Commit 64bf652dd057ff48bb0ce4405a20832f7e4bda48 in geode's branch refs/heads/support/1.15 from Kris10 [ https://gitbox.apache.org/repos/asf?p=geode.git;h=64bf652 ] GEODE-9833: SPOP Command Support (#7319) - Modified implementation of retrieving a random element from SizeableObjectOpenCustomHashSetWithCursor backing array (cherry picked from commit afa17f65ec57052b0ee110326385568df784ba1a) > SPOP Command Supported > -- > > Key: GEODE-9833 > URL: https://issues.apache.org/jira/browse/GEODE-9833 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SPOP command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. > > The current implementation of RedisSet spop and srandmember always copy the > entire MemberSet. So if you have a redis set with a million items, and than > ask for one random one, instead of it reading just one of the items out of > the set it first copies the entire set. > The call that makes the copy is "members.toArray". It should be pretty easy > to add spop and srandmember support to the MemberSet super class. Since > MemberSet uses a flat array to store its items it should work well with > supporting indexing of its array to get a random element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9833) SPOP Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristen resolved GEODE-9833. Resolution: Fixed > SPOP Command Supported > -- > > Key: GEODE-9833 > URL: https://issues.apache.org/jira/browse/GEODE-9833 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SPOP command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. > > The current implementation of RedisSet spop and srandmember always copy the > entire MemberSet. So if you have a redis set with a million items, and than > ask for one random one, instead of it reading just one of the items out of > the set it first copies the entire set. > The call that makes the copy is "members.toArray". It should be pretty easy > to add spop and srandmember support to the MemberSet super class. Since > MemberSet uses a flat array to store its items it should work well with > supporting indexing of its array to get a random element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9833) SPOP Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristen updated GEODE-9833: --- Fix Version/s: 1.15.0 1.16.0 > SPOP Command Supported > -- > > Key: GEODE-9833 > URL: https://issues.apache.org/jira/browse/GEODE-9833 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SPOP command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. > > The current implementation of RedisSet spop and srandmember always copy the > entire MemberSet. So if you have a redis set with a million items, and than > ask for one random one, instead of it reading just one of the items out of > the set it first copies the entire set. > The call that makes the copy is "members.toArray". It should be pretty easy > to add spop and srandmember support to the MemberSet super class. Since > MemberSet uses a flat array to store its items it should work well with > supporting indexing of its array to get a random element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9833) SPOP Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486146#comment-17486146 ] ASF subversion and git services commented on GEODE-9833: Commit afa17f65ec57052b0ee110326385568df784ba1a in geode's branch refs/heads/develop from Kris10 [ https://gitbox.apache.org/repos/asf?p=geode.git;h=afa17f6 ] GEODE-9833: SPOP Command Support (#7319) - Modified implementation of retrieving a random element from SizeableObjectOpenCustomHashSetWithCursor backing array > SPOP Command Supported > -- > > Key: GEODE-9833 > URL: https://issues.apache.org/jira/browse/GEODE-9833 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The SPOP command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. > > The current implementation of RedisSet spop and srandmember always copy the > entire MemberSet. So if you have a redis set with a million items, and than > ask for one random one, instead of it reading just one of the items out of > the set it first copies the entire set. > The call that makes the copy is "members.toArray". It should be pretty easy > to add spop and srandmember support to the MemberSet super class. Since > MemberSet uses a flat array to store its items it should work well with > supporting indexing of its array to get a random element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9994) Redis RENAME command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-9994: --- Fix Version/s: 1.16.0 > Redis RENAME command should be atomic > - > > Key: GEODE-9994 > URL: https://issues.apache.org/jira/browse/GEODE-9994 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Eric Zoerner >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The current implementation of RENAME in the geode-for-redis module is not > atomic, which could result in partially-applied renames if servers crash > during a rename. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the AbstractRenameExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9994) Redis RENAME command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Zoerner resolved GEODE-9994. - Fix Version/s: 1.15.0 Resolution: Fixed > Redis RENAME command should be atomic > - > > Key: GEODE-9994 > URL: https://issues.apache.org/jira/browse/GEODE-9994 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Eric Zoerner >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > The current implementation of RENAME in the geode-for-redis module is not > atomic, which could result in partially-applied renames if servers crash > during a rename. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the AbstractRenameExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9994) Redis RENAME command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486121#comment-17486121 ] ASF subversion and git services commented on GEODE-9994: Commit bff808245ab59e71a13e393a6301af444393abc4 in geode's branch refs/heads/support/1.15 from Eric Zoerner [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bff8082 ] GEODE-9994 Make Redis RENAME atomic (#7328) - change verification to allow for erroneous client retries - change error logging to warning level to prevent false negative test failure due to log (cherry picked from commit 6413c33d6b0050a1ebe7e88f9ea20295ab780cab) > Redis RENAME command should be atomic > - > > Key: GEODE-9994 > URL: https://issues.apache.org/jira/browse/GEODE-9994 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Eric Zoerner >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The current implementation of RENAME in the geode-for-redis module is not > atomic, which could result in partially-applied renames if servers crash > during a rename. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the AbstractRenameExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9994) Redis RENAME command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486118#comment-17486118 ] ASF subversion and git services commented on GEODE-9994: Commit 6413c33d6b0050a1ebe7e88f9ea20295ab780cab in geode's branch refs/heads/develop from Eric Zoerner [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6413c33 ] GEODE-9994 Make Redis RENAME atomic (#7328) - change verification to allow for erroneous client retries - change error logging to warning level to prevent false negative test failure due to log > Redis RENAME command should be atomic > - > > Key: GEODE-9994 > URL: https://issues.apache.org/jira/browse/GEODE-9994 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Eric Zoerner >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The current implementation of RENAME in the geode-for-redis module is not > atomic, which could result in partially-applied renames if servers crash > during a rename. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the AbstractRenameExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9634. - Fix Version/s: 1.15.0 Resolution: Fixed fixed in native client > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Blocker > Labels: pull-request-available > Fix For: 1.15.0 > > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9999) Update the Geode for Redis documentation
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486104#comment-17486104 ] ASF subversion and git services commented on GEODE-: Commit 254af1d67e93daf257840a62babbdb5d3fd4a676 in geode's branch refs/heads/support/1.15 from John Martin [ https://gitbox.apache.org/repos/asf?p=geode.git;h=254af1d ] GEODE-: Update the Geode for Redis documentation (#7326) (cherry picked from commit 064fe005297e82094a1ef68d754efa2579b3277a) > Update the Geode for Redis documentation > > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: John Martin >Assignee: John Martin >Priority: Major > Labels: backport, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > A few updates are needed to update the Geode for Redis documentation to > better reflect the current implementation of the Redis module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486103#comment-17486103
]
ASF subversion and git services commented on GEODE-10011:
-
Commit 41e4ef9014755a13f17dccc3fc83997fce37b5c6 in geode's branch
refs/heads/support/1.15 from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=41e4ef9 ]
GEODE-10011: Do not perform second scan if first scanned entire map (#7333)
- The test scanWithNoModificationsDoesNotReturnDuplicates in
SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest should
only perform a second scan if the first one was not a complete scan of
the map
Authored-by: Donal Evans
(cherry picked from commit dcba954c1e8060b409409f67b6a2e55a1e2c37b2)
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire map, but for small map sizes (the map in the failure above
> only has 2 keys) it's possible that the first scan will return all elements
> and a cursor value of 0, meaning that the second scan will also return all
> elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9999) Update the Geode for Redis documentation
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-: --- Fix Version/s: 1.15.0 1.16.0 > Update the Geode for Redis documentation > > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: John Martin >Assignee: John Martin >Priority: Major > Labels: backport, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > A few updates are needed to update the Geode for Redis documentation to > better reflect the current implementation of the Redis module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9999) Update the Geode for Redis documentation
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-. Resolution: Fixed > Update the Geode for Redis documentation > > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: John Martin >Assignee: John Martin >Priority: Major > Labels: backport, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > A few updates are needed to update the Geode for Redis documentation to > better reflect the current implementation of the Redis module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10011:
Fix Version/s: 1.15.0
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire map, but for small map sizes (the map in the failure above
> only has 2 keys) it's possible that the first scan will return all elements
> and a cursor value of 0, meaning that the second scan will also return all
> elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9999) Update the Geode for Redis documentation
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486101#comment-17486101 ] ASF subversion and git services commented on GEODE-: Commit 064fe005297e82094a1ef68d754efa2579b3277a in geode's branch refs/heads/develop from John Martin [ https://gitbox.apache.org/repos/asf?p=geode.git;h=064fe00 ] GEODE-: Update the Geode for Redis documentation (#7326) > Update the Geode for Redis documentation > > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: John Martin >Assignee: John Martin >Priority: Major > Labels: backport, blocks-1.15.0, pull-request-available > > A few updates are needed to update the Geode for Redis documentation to > better reflect the current implementation of the Redis module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10010:
---
Affects Version/s: 1.16.0
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Hale Bales
>Priority: Major
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> 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)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9907) Geode-for-redis example failed with JedisNoReachableClusterNodeException: No reachable node in cluster
[
https://issues.apache.org/jira/browse/GEODE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486098#comment-17486098
]
Geode Integration commented on GEODE-9907:
--
Seen on support/1.15 in [test-examples
#19|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-examples/jobs/test-examples/builds/19].
> Geode-for-redis example failed with JedisNoReachableClusterNodeException: No
> reachable node in cluster
> --
>
> Key: GEODE-9907
> URL: https://issues.apache.org/jira/browse/GEODE-9907
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: backport, blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
>
> {code:java}
> > Task :geodeForRedis:run FAILED
> Exception in thread "main"
> redis.clients.jedis.exceptions.JedisNoReachableClusterNodeException: No
> reachable node in cluster
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnection(JedisSlotBasedConnectionHandler.java:117)
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnectionFromSlot(JedisSlotBasedConnectionHandler.java:139)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:118)
> at redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.zadd(JedisCluster.java:1106)
> at
> org.apache.geode_examples.geodeForRedis.Example.populateSortedSet(Example.java:53)
> at org.apache.geode_examples.geodeForRedis.Example.main(Example.java:30)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geodeForRedis:run'.
> > Process 'command '/usr/lib/jvm/bellsoft-java8-amd64/bin/java'' finished
> >with non-zero exit value 1
> {code}
>
> This might be related to [https://github.com/apache/geode-examples/pull/110]
> due to the location of the failure of the test
> org.apache.geode_examples.geodeForRedis.Example.main.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10010:
---
Labels: (was: needsTriage)
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Hale Bales
>Priority: Major
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> 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)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486097#comment-17486097
]
Hale Bales commented on GEODE-10010:
This issue is not a 1.15 release blocker. We should look into accuracy of the
ops/sec measurement for the 1.16 release, but it is currently not the highest
priority since it is just the stats and changes to that later will not impact
users.
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> 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)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9999) Update the Geode for Redis documentation
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Martin reassigned GEODE-: -- Assignee: John Martin > Update the Geode for Redis documentation > > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: John Martin >Assignee: John Martin >Priority: Major > Labels: backport, blocks-1.15.0, pull-request-available > > A few updates are needed to update the Geode for Redis documentation to > better reflect the current implementation of the Redis module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9907) Geode-for-redis example failed with JedisNoReachableClusterNodeException: No reachable node in cluster
[
https://issues.apache.org/jira/browse/GEODE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9907:
Fix Version/s: 1.15.0
> Geode-for-redis example failed with JedisNoReachableClusterNodeException: No
> reachable node in cluster
> --
>
> Key: GEODE-9907
> URL: https://issues.apache.org/jira/browse/GEODE-9907
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: backport, blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
>
> {code:java}
> > Task :geodeForRedis:run FAILED
> Exception in thread "main"
> redis.clients.jedis.exceptions.JedisNoReachableClusterNodeException: No
> reachable node in cluster
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnection(JedisSlotBasedConnectionHandler.java:117)
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnectionFromSlot(JedisSlotBasedConnectionHandler.java:139)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:118)
> at redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.zadd(JedisCluster.java:1106)
> at
> org.apache.geode_examples.geodeForRedis.Example.populateSortedSet(Example.java:53)
> at org.apache.geode_examples.geodeForRedis.Example.main(Example.java:30)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geodeForRedis:run'.
> > Process 'command '/usr/lib/jvm/bellsoft-java8-amd64/bin/java'' finished
> >with non-zero exit value 1
> {code}
>
> This might be related to [https://github.com/apache/geode-examples/pull/110]
> due to the location of the failure of the test
> org.apache.geode_examples.geodeForRedis.Example.main.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9907) Geode-for-redis example failed with JedisNoReachableClusterNodeException: No reachable node in cluster
[
https://issues.apache.org/jira/browse/GEODE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486084#comment-17486084
]
ASF subversion and git services commented on GEODE-9907:
Commit 0ba9282f00d856831a7f98c1f951f064da1a7db2 in geode-examples's branch
refs/heads/support/1.15 from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=0ba9282 ]
GEODE-9907: Add larger timeout to JedisCluster in Redis example (#113)
Authored-by: Donal Evans
(cherry picked from commit 488a43d14af80868dbe82e8ca9fecb14934fab55)
> Geode-for-redis example failed with JedisNoReachableClusterNodeException: No
> reachable node in cluster
> --
>
> Key: GEODE-9907
> URL: https://issues.apache.org/jira/browse/GEODE-9907
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: backport, blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
>
> {code:java}
> > Task :geodeForRedis:run FAILED
> Exception in thread "main"
> redis.clients.jedis.exceptions.JedisNoReachableClusterNodeException: No
> reachable node in cluster
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnection(JedisSlotBasedConnectionHandler.java:117)
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnectionFromSlot(JedisSlotBasedConnectionHandler.java:139)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:118)
> at redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.zadd(JedisCluster.java:1106)
> at
> org.apache.geode_examples.geodeForRedis.Example.populateSortedSet(Example.java:53)
> at org.apache.geode_examples.geodeForRedis.Example.main(Example.java:30)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geodeForRedis:run'.
> > Process 'command '/usr/lib/jvm/bellsoft-java8-amd64/bin/java'' finished
> >with non-zero exit value 1
> {code}
>
> This might be related to [https://github.com/apache/geode-examples/pull/110]
> due to the location of the failure of the test
> org.apache.geode_examples.geodeForRedis.Example.main.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17486076#comment-17486076
]
ASF GitHub Bot commented on GEODE-10004:
mmartell opened a new pull request #917:
URL: https://github.com/apache/geode-native/pull/917
This PR is to update the cmake config files for tests/javaobject to allow
building javaobject.jar against geode versions that pre-date the addition of
throwing AuthenticationExpiredExceptions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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, 1.16.0
>Reporter: Hale Bales
>Priority: Major
>
> 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.1#820001)
[jira] [Updated] (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
]
ASF GitHub Bot updated GEODE-10004:
---
Labels: pull-request-available (was: )
> 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, 1.16.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.1#820001)
[jira] [Created] (GEODE-10014) Add support for building nativeclient against older geode releases
Michael Martell created GEODE-10014: --- Summary: Add support for building nativeclient against older geode releases Key: GEODE-10014 URL: https://issues.apache.org/jira/browse/GEODE-10014 Project: Geode Issue Type: Task Components: native client Reporter: Michael Martell Currently, the nativeclient's java test module (javaobject.jar) depends on a very recent version of geode (1.15.0-build.546 or higher). This ticket is to add support for building this jar file against older versions of geode which do not contain the new AuthenticationExpiredException. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486044#comment-17486044
]
ASF subversion and git services commented on GEODE-10011:
-
Commit dcba954c1e8060b409409f67b6a2e55a1e2c37b2 in geode's branch
refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dcba954 ]
GEODE-10011: Do not perform second scan if first scanned entire map (#7333)
- The test scanWithNoModificationsDoesNotReturnDuplicates in
SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest should
only perform a second scan if the first one was not a complete scan of
the map
Authored-by: Donal Evans
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire map, but for small map sizes (the map in the failure above
> only has 2 keys) it's possible that the first scan will return all elements
> and a cursor value of 0, meaning that the second scan will also return all
> elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9993) Redis SMOVE command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486043#comment-17486043 ] ASF subversion and git services commented on GEODE-9993: Commit c0eb58e055a16fd5bc5bb22ad97d88739d55ae02 in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c0eb58e ] GEODE-9993: Make SMOVE transactional (#7321) - Use lockedExecuteInTransaction method in SMoveExecutor - Refactor RedisSet.sadd and RedisSet.srem to not modify the list of members passed to them - Do not use Delta in AbstractRedisData.storeChanges() if operation is using a transaction Authored-by: Donal Evans > Redis SMOVE command should be atomic > > > Key: GEODE-9993 > URL: https://issues.apache.org/jira/browse/GEODE-9993 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The [documentation for the SMOVE command|https://redis.io/commands/SMOVE] > states that it is atomic. The current implementation in the geode-for-redis > module is not, which could result in partially-applied moves if servers crash > during a move. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the SMoveExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9835) SSCAN Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486042#comment-17486042 ] ASF subversion and git services commented on GEODE-9835: Commit da6043239eb637994eaba64c3d59cf327aac0f7d in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Bala Kaza Venkata [ https://gitbox.apache.org/repos/asf?p=geode.git;h=da60432 ] GEODE-9835: Add SSCAN to Redis supported commands (#7278) Co-authored-by: Bala Kaza Venkata Co-authored-by: Steve Sienkowski > SSCAN Command Supported > --- > > Key: GEODE-9835 > URL: https://issues.apache.org/jira/browse/GEODE-9835 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Wayne >Assignee: Steve Sienkowski >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The SSCAN command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10013) Remove unused code in Geode for Redis tests
[ https://issues.apache.org/jira/browse/GEODE-10013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10013: --- Labels: pull-request-available (was: ) > Remove unused code in Geode for Redis tests > --- > > Key: GEODE-10013 > URL: https://issues.apache.org/jira/browse/GEODE-10013 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.16.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > > Several Geode for Redis tests contain redundant server.stop() calls and > unnecessary "canStoreBinaryData" tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10013) Remove unused code in Geode for Redis tests
[ https://issues.apache.org/jira/browse/GEODE-10013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Ingles reassigned GEODE-10013: -- Assignee: Ray Ingles > Remove unused code in Geode for Redis tests > --- > > Key: GEODE-10013 > URL: https://issues.apache.org/jira/browse/GEODE-10013 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.16.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > > Several Geode for Redis tests contain redundant server.stop() calls and > unnecessary "canStoreBinaryData" tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ray Ingles updated GEODE-10005:
---
Priority: Minor (was: Blocker)
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Minor
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ray Ingles updated GEODE-10005:
---
Priority: Blocker (was: Minor)
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10013) Remove unused code in Geode for Redis tests
Ray Ingles created GEODE-10013: -- Summary: Remove unused code in Geode for Redis tests Key: GEODE-10013 URL: https://issues.apache.org/jira/browse/GEODE-10013 Project: Geode Issue Type: Improvement Components: redis Affects Versions: 1.16.0 Reporter: Ray Ingles Several Geode for Redis tests contain redundant server.stop() calls and unnecessary "canStoreBinaryData" tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9988) Log full exception when JNDI binding fails during cache creation
[
https://issues.apache.org/jira/browse/GEODE-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9988.
---
Fix Version/s: 1.16.0
Resolution: Fixed
> Log full exception when JNDI binding fails during cache creation
>
>
> Key: GEODE-9988
> URL: https://issues.apache.org/jira/browse/GEODE-9988
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> When a cache.xml is configured with a {{jndi-binding}} construct it may fail
> to bind but the log does not contain a useful error message, only something
> like:
> {noformat}
> [warn 2022/01/25 13:26:41.286 PST tid=0x1] jndi-binding creation of
> SimpleDataSource failed with:
> org.apache.geode.internal.datasource.DataSourceCreateException: Failed to
> connect to "SimpleDataSource". See log for details {noformat}
> The full exception stack would contain a the real cause of the problem. In
> this case:
> {noformat}
> java.sql.SQLNonTransientConnectionException: java.net.ConnectException :
> Error connecting to server localhost on port 1,528 with message Connection
> refused (Connection refused).
> at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at
> org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:111)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.getConnection(JNDIInvoker.java:429)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.validateAndBindDataSource(JNDIInvoker.java:413)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:392)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:366)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:3064)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3485)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:226)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2007)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:881)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1784)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2969)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:113)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:507)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:867)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:796)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:142)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:644)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:328)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:196)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:233)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4203)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1625)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1451)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at org.apache.geode.Jt
[jira] [Updated] (GEODE-9988) Log full exception when JNDI binding fails during cache creation
[
https://issues.apache.org/jira/browse/GEODE-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9988:
--
Affects Version/s: 1.16.0
> Log full exception when JNDI binding fails during cache creation
>
>
> Key: GEODE-9988
> URL: https://issues.apache.org/jira/browse/GEODE-9988
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> When a cache.xml is configured with a {{jndi-binding}} construct it may fail
> to bind but the log does not contain a useful error message, only something
> like:
> {noformat}
> [warn 2022/01/25 13:26:41.286 PST tid=0x1] jndi-binding creation of
> SimpleDataSource failed with:
> org.apache.geode.internal.datasource.DataSourceCreateException: Failed to
> connect to "SimpleDataSource". See log for details {noformat}
> The full exception stack would contain a the real cause of the problem. In
> this case:
> {noformat}
> java.sql.SQLNonTransientConnectionException: java.net.ConnectException :
> Error connecting to server localhost on port 1,528 with message Connection
> refused (Connection refused).
> at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at
> org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:111)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.getConnection(JNDIInvoker.java:429)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.validateAndBindDataSource(JNDIInvoker.java:413)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:392)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:366)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:3064)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3485)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:226)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2007)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:881)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1784)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2969)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:113)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:507)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:867)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:796)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:142)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:644)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:328)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:196)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:233)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4203)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1625)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1451)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at org.apache.geode.JtaDebug.insanity(JtaDebug.java:47)
> at sun.reflect.
[jira] [Commented] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485946#comment-17485946
]
ASF subversion and git services commented on GEODE-10011:
-
Commit dcba954c1e8060b409409f67b6a2e55a1e2c37b2 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dcba954 ]
GEODE-10011: Do not perform second scan if first scanned entire map (#7333)
- The test scanWithNoModificationsDoesNotReturnDuplicates in
SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest should
only perform a second scan if the first one was not a complete scan of
the map
Authored-by: Donal Evans
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire map, but for small map sizes (the map in the failure above
> only has 2 keys) it's possible that the first scan will return all elements
> and a cursor value of 0, meaning that the second scan will also return all
> elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10011.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire map, but for small map sizes (the map in the failure above
> only has 2 keys) it's possible that the first scan will return all elements
> and a cursor value of 0, meaning that the second scan will also return all
> elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket
[
https://issues.apache.org/jira/browse/GEODE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9990:
--
Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was:
GeodeOperationAPI blocks-1.15.0)
> Geode should handle certain DiskAccessException due to CacheClosedException
> when creating bucket
>
>
> Key: GEODE-9990
> URL: https://issues.apache.org/jira/browse/GEODE-9990
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Joris Melchior
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
>
> This exception is thrown to the node that tries to create the bucket to
> prevent it trying to create the bucket to next available server and fail the
> entry operation.
> {noformat}
> org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The
> disk store is closed
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-cli
[jira] [Updated] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
[ https://issues.apache.org/jira/browse/GEODE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10009: -- Labels: blocks-1.15.0 needsTriage pull-request-available (was: needsTriage pull-request-available) > The CacheClientProxy for a durable client can be terminated when it shouldn't > be > > > Key: GEODE-10009 > URL: https://issues.apache.org/jira/browse/GEODE-10009 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: blocks-1.15.0, needsTriage, pull-request-available > > When the client connection is closed but the server has not left or crashed > (e.g in the re-authentication failed case), its possible that two threads in > a durable client can interleave in a way that causes an extra durable task to > be created on the server that eventually causes the CacheClientProxy to be > terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
