[jira] [Commented] (GEODE-8671) Two threads calling get and retrieve the same PdxInstance, resulting in corruption
[ https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294960#comment-17294960 ] ASF subversion and git services commented on GEODE-8671: Commit 6b85568cc21678d5854fb89f2fdaecd2a22ccd2f in geode's branch refs/heads/support/1.14 from Jianxia Chen [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6b85568 ] GEODE-8671: Two threads calling get and retrieve the same PdxInstance, resulting in corruption (#5925) For PdxInstance, return a new reference in LocalRegion.optimizedGetObject(), instead of using the value in the Future. This is to avoid Pdx corruption when multiple threads share the same reference of PdxInstance. (cherry picked from commit dabb610b74bb0b27603d7803ec3cdd1cbb16c43f) > Two threads calling get and retrieve the same PdxInstance, resulting in > corruption > -- > > Key: GEODE-8671 > URL: https://issues.apache.org/jira/browse/GEODE-8671 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Dan Smith >Assignee: Jianxia Chen >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > Even if copy-on-read is set to true, two threads calling get on a partitioned > region can end up with the same PdxInstance object. > This is problematic because some PdxInstances methods are not thread safe. > Although the underlying bytes are immutatable, the PDXInstance has a > ByteSource with a position field that changes. That means two threads doing > serialization or calling toString on the PdxInstance could result in one or > more threads getting a corrupt read. > It looks like they are ending up with the same instance because of the > behavior in LocalRegion.optimizedGetObject. We use futures to make sure there > is only 1 get that goes through, and both threads receive the same value. > > Ending up in optimizedGetObject requires a race with the put, because if the > value was in the cache at the beginning of the get it would be returned > earlier in the get process. > I put a test that reproduces this issue here - > https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8624) Improve INCRBYFLOAT accuracy for very large values
[
https://issues.apache.org/jira/browse/GEODE-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294958#comment-17294958
]
ASF subversion and git services commented on GEODE-8624:
Commit d201090a6ae6ef4d591e936ffce776b3f8919e89 in geode's branch
refs/heads/support/1.14 from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d201090 ]
GEODE-8624: Support Redis HINCRBYFLOAT command (#5986)
- Switch to using BigDecimal instead of double for increment value.
- Improve HINCRBYFLOAT output accuracy for very large values.
- Add concurrency tests.
- Mark HINCRBYFLOAT as supported.
(cherry-picked from 8a0dc1aae8636a44c4fa4d5d30dcbc0efafb4430)
> Improve INCRBYFLOAT accuracy for very large values
> --
>
> Key: GEODE-8624
> URL: https://issues.apache.org/jira/browse/GEODE-8624
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.14.0
>
>
> Currently native redis appears to be able to apply {{INCRBYFLOAT}} on values
> that are below the max of unsigned long long (18446744073709551615). However,
> since we're treating numbers as {{double}}s we can lose precision for very
> large values. For example:
> {noformat}
> set val 18446744073709551614
> incrbyfloat val 1{noformat}
> incorrectly returns {{18446744073709552000}}
> Native redis produces a correct result.
> We should consider switching to using {{BigInteger}} for all commands which
> perform calculations: {{INCR, INCR, INCRBYFLOAT, HINCRBY, HINCRBYFLOAT}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8894) Allow individual deltas to trigger bucket size recalculation
[ https://issues.apache.org/jira/browse/GEODE-8894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294956#comment-17294956 ] ASF subversion and git services commented on GEODE-8894: Commit d1b8319d7bc46de6b10480ebb0c9df41aeae894e in geode's branch refs/heads/support/1.14 from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d1b8319 ] GEODE-8894 allow individual deltas to trigger bucket size recalculation (#5978) * add interface for forcing size recalculation on buckets * Allow individual deltas to trigger bucket size recalculation * remove all deprecated methods and redundant tests * update Javadoc and remove Event instance variable * add EntryEventImpl unit tests for size recalc * remove unused classes/code * remove unused TestKey * reorganize and clarify region creation Co-authored-by: Ray Ingles (cherry-picked from 3a21c2852746f19755ac302f584ca5b8908eae2e) > Allow individual deltas to trigger bucket size recalculation > > > Key: GEODE-8894 > URL: https://issues.apache.org/jira/browse/GEODE-8894 > Project: Geode > Issue Type: New Feature > Components: core, serialization >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0 > > > The Redis subsystem uses Deltas heavily, but by default deltas do not trigger > an update to the size of their buckets. This leads to incorrect memory usage > accounting over the long term, especially with the use of Redis commands like > "APPEND". > It is possible to set the system property "DELTAS_RECALCULATE_SIZE", but this > is a global value that would affect the processing of all deltas, including > non-Redis operations. > Instead, we will add a new default method to the Delta interface, that can be > overridden by individual Delta implementations (such as Redis). This will > trigger the same behavior as DELTAS_RECALCULATE_SIZE, but on a per-delta > basis. Thus, other Geode operations will not force bucket size recalculations > unless the global property is set, but Redis statistics will be correct. > Other types of delta operations may find this useful in the future. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8865) Create additional dunit and integration tests for Redis HMGET
[ https://issues.apache.org/jira/browse/GEODE-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294957#comment-17294957 ] ASF subversion and git services commented on GEODE-8865: Commit 944d7969b72cc4aab1a4e5786a34981d389f7c0d in geode's branch refs/heads/support/1.14 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=944d796 ] GEODE-8865: Create additional dunit and integration tests for Redis HMGET (#5945) (cherry-picked from commit bba1935d98328c7b767adebded577f433e49ba87) > Create additional dunit and integration tests for Redis HMGET > - > > Key: GEODE-8865 > URL: https://issues.apache.org/jira/browse/GEODE-8865 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0 > > > Write integration tests for the following command: > * HMGET > *A.C.* > * NativeRedisAcceptanceTest file present to run our tests against native > Redis > * Tests are passing, _or_ > * Stories in the backlog to fix the identified issues (with JIRA tickets) > and problem tests ignored -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8933) Report max memory setting in Geode Redis statistics
[ https://issues.apache.org/jira/browse/GEODE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294955#comment-17294955 ] ASF subversion and git services commented on GEODE-8933: Commit 453e298cbeaf847b5cb7dd6136858be212f9237f in geode's branch refs/heads/support/1.14 from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=453e298 ] GEODE-8933: update INFO to return maxmemory field (#6019) * Also fix fragmentation ratio Co-authored-by: Ray Ingles (cherry-picked from ab5ef9d46b24bd686d91c920bdbd3dc0a5026e26) > Report max memory setting in Geode Redis statistics > --- > > Key: GEODE-8933 > URL: https://issues.apache.org/jira/browse/GEODE-8933 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0 > > > In order to implement eviction for Redis data, the INFO command will need to > report at least one new field, "maxmemory". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294947#comment-17294947 ] ASF subversion and git services commented on GEODE-8996: Commit b7a931e4bc55694438da8e7ec61b79d206d96b5b in geode's branch refs/heads/support/1.14 from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b7a931e ] GEODE-8996: Fixed rebalance gfsh and REST API in mixed version mode (#6080) * Moved new child RebalanceFunction and CacheRealizationFunction to pre 1.12.0 locations. * While talking to pre-1.12.0 servers, the locators send the function from the old package. * While talking to 1.12.0 server, the new package function is used. * For RebalanceFunction and CacheRealizationFunction the serialVersionUID is set to the one created by 1.11.0 for old package location and serialVersionUID created by 1.12.0 for the latter. (cherry picked from commit 3faf283c038880755a7356fe570a4f92a46826cd) > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294946#comment-17294946 ] ASF subversion and git services commented on GEODE-8996: Commit ef10a36b0bbee6053b2b5293362285198be976da in geode's branch refs/heads/support/1.13 from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ef10a36 ] GEODE-8996: Fixed rebalance gfsh and REST API in mixed version mode (#6087) * Moved new child RebalanceFunction and CacheRealizationFunction to pre 1.12.0 locations. * While talking to pre-1.12.0 servers, the locators send the function from the old package. * While talking to 1.12.0 server, the new package function is used. * For RebalanceFunction and CacheRealizationFunction the serialVersionUID is set to the one created by 1.11.0 for old package location and serialVersionUID created by 1.12.0 for the latter. (cherry picked from commit 3faf283c038880755a7356fe570a4f92a46826cd) > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294945#comment-17294945 ] ASF GitHub Bot commented on GEODE-8996: --- onichols-pivotal merged pull request #6087: URL: https://github.com/apache/geode/pull/6087 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8943) Filterrs (Interest and CQ) is processed multiple times with transactional operation on PR
[ https://issues.apache.org/jira/browse/GEODE-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294943#comment-17294943 ] ASF GitHub Bot commented on GEODE-8943: --- lgtm-com[bot] commented on pull request #6075: URL: https://github.com/apache/geode/pull/6075#issuecomment-790233665 This pull request **introduces 2 alerts** when merging 21b6de7598fa690f65fe918e5a24ee37840913c5 into c650095d74ca0b88a33a1089a0e0caa331b42ea0 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-890925863de2981aa1a6e086fb1e785d68b098c7) **new alerts:** * 2 for Dereferenced variable may be null 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Filterrs (Interest and CQ) is processed multiple times with transactional > operation on PR > - > > Key: GEODE-8943 > URL: https://issues.apache.org/jira/browse/GEODE-8943 > Project: Geode > Issue Type: Bug > Components: cq, regions >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The Filters (interest and CQ) could be getting processed multiple times when > transactional operation is performed. > By design on PR the filters are processed on primary bucket where the data is > applied/changed and adjunct message with interested clients are sent to > remote servers (where the subscription queues are hosted) and replicas; thus > performing filter processing once and sending the message to remote servers > only if the filters are satisfied; it looks like currently the filter > processing is happening both at the primary and secondary buckets for TX > operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294936#comment-17294936 ] ASF GitHub Bot commented on GEODE-8996: --- nabarunnag opened a new pull request #6087: URL: https://github.com/apache/geode/pull/6087 * Moved new child RebalanceFunction and CacheRealizationFunction to pre 1.12.0 locations. * While talking to pre-1.12.0 servers, the locators send the function from the old package. * While talking to 1.12.0 server, the new package function is used. * For RebalanceFunction and CacheRealizationFunction the serialVersionUID is set to the one created by 1.11.0 for old package location and serialVersionUID created by 1.12.0 for the latter. (cherry picked from commit 3faf283c038880755a7356fe570a4f92a46826cd) Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[ https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294914#comment-17294914 ] ASF subversion and git services commented on GEODE-8998: Commit c650095d74ca0b88a33a1089a0e0caa331b42ea0 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c650095 ] GEODE-8998: fix NPE caused by thread-monitor-enabled=false (#6083) If thread monitoring is enable, the Connection class will not get a DummyExecutor instead of null thus preventing the NPE. > setting thread-monitoring-enabled to false causes NullPointerException > -- > > Key: GEODE-8998 > URL: https://issues.apache.org/jira/browse/GEODE-8998 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > If you set the geode property thread-monitoring-enabled to false then any > geode cluster messaging is broken. As cluster messages are read the p2p > reader thread throws a NullPointerException. > This bug was introduced in GEODE-8521 so it has not yet been released. > I have a test that reproduces the NPE and this fix will be simple. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[ https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8998. - Fix Version/s: 1.15.0 Resolution: Fixed > setting thread-monitoring-enabled to false causes NullPointerException > -- > > Key: GEODE-8998 > URL: https://issues.apache.org/jira/browse/GEODE-8998 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > If you set the geode property thread-monitoring-enabled to false then any > geode cluster messaging is broken. As cluster messages are read the p2p > reader thread throws a NullPointerException. > This bug was introduced in GEODE-8521 so it has not yet been released. > I have a test that reproduces the NPE and this fix will be simple. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[ https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294913#comment-17294913 ] ASF GitHub Bot commented on GEODE-8998: --- dschneider-pivotal merged pull request #6083: URL: https://github.com/apache/geode/pull/6083 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > setting thread-monitoring-enabled to false causes NullPointerException > -- > > Key: GEODE-8998 > URL: https://issues.apache.org/jira/browse/GEODE-8998 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > If you set the geode property thread-monitoring-enabled to false then any > geode cluster messaging is broken. As cluster messages are read the p2p > reader thread throws a NullPointerException. > This bug was introduced in GEODE-8521 so it has not yet been released. > I have a test that reproduces the NPE and this fix will be simple. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294911#comment-17294911 ] ASF subversion and git services commented on GEODE-8996: Commit 3faf283c038880755a7356fe570a4f92a46826cd in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3faf283 ] GEODE-8996: Fixed rebalance gfsh and REST API in mixed version mode (#6080) * Moved new child RebalanceFunction and CacheRealizationFunction to pre 1.12.0 locations. * While talking to pre-1.12.0 servers, the locators send the function from the old package. * While talking to 1.12.0 server, the new package function is used. * For RebalanceFunction and CacheRealizationFunction the serialVersionUID is set to the one created by 1.11.0 for old package location and serialVersionUID created by 1.12.0 for the latter. > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294910#comment-17294910 ] ASF GitHub Bot commented on GEODE-8996: --- nabarunnag merged pull request #6080: URL: https://github.com/apache/geode/pull/6080 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8999) When max-threads is specified for a cache server its reader threads may be reported as Stuck
[
https://issues.apache.org/jira/browse/GEODE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8999.
---
Resolution: Not A Problem
After talking with Darrel I think the thread was stuck. It was reported during
a network partition and the client had invalidated the server and was closing
connections to it.
> When max-threads is specified for a cache server its reader threads may be
> reported as Stuck
>
>
> Key: GEODE-8999
> URL: https://issues.apache.org/jira/browse/GEODE-8999
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> We noticed this report of a stuck thread in a test that enabled max-threads
> in a cache server:
> {noformat}
> [warn 2021/03/02 19:54:31.041 PST bridgep2_host2_17822
> tid=0x1b] Thread <104> (0x68) that was executed at <02 Mar 2021 19:53:44 PST>
> has been stuck for <46.356 seconds> and number of thread monitor iteration <1>
> Thread Name state
> Executor Group
> Monitored metric
> Thread stack:
> sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> sun.nio.ch.IOUtil.read(IOUtil.java:192)
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378)
> org.apache.geode.internal.cache.tier.sockets.Message.readWrappedHeaders(Message.java:1237)
> org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:859)
> org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(Message.java:698)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1213)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1229)
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:816)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:777)
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:73)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1185)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:710)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$351/1357226696.invoke(Unknown
> Source)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$88/1800187767.run(Unknown
> Source)
> java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cache server should suspend thread monitoring before reading from a
> socket and resume monitoring afterward. An example of this can be found in
> org.apache.geode.internal.tcp.Connection.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8999) When max-threads is specified for a cache server its reader threads may be reported as Stuck
[
https://issues.apache.org/jira/browse/GEODE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt closed GEODE-8999.
-
> When max-threads is specified for a cache server its reader threads may be
> reported as Stuck
>
>
> Key: GEODE-8999
> URL: https://issues.apache.org/jira/browse/GEODE-8999
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> We noticed this report of a stuck thread in a test that enabled max-threads
> in a cache server:
> {noformat}
> [warn 2021/03/02 19:54:31.041 PST bridgep2_host2_17822
> tid=0x1b] Thread <104> (0x68) that was executed at <02 Mar 2021 19:53:44 PST>
> has been stuck for <46.356 seconds> and number of thread monitor iteration <1>
> Thread Name state
> Executor Group
> Monitored metric
> Thread stack:
> sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> sun.nio.ch.IOUtil.read(IOUtil.java:192)
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378)
> org.apache.geode.internal.cache.tier.sockets.Message.readWrappedHeaders(Message.java:1237)
> org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:859)
> org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(Message.java:698)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1213)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1229)
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:816)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:777)
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:73)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1185)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:710)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$351/1357226696.invoke(Unknown
> Source)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$88/1800187767.run(Unknown
> Source)
> java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cache server should suspend thread monitoring before reading from a
> socket and resume monitoring afterward. An example of this can be found in
> org.apache.geode.internal.tcp.Connection.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8958) Tombstone expiration: in the event that a version timestamp is too far in the future, expire the tombstone
[ https://issues.apache.org/jira/browse/GEODE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294889#comment-17294889 ] ASF subversion and git services commented on GEODE-8958: Commit 3ffc6a6aaaf9a0ed9245d7069dd6cfdc68d5c936 in geode's branch refs/heads/support/1.12 from Mark Hanson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3ffc6a6 ] GEODE-8958: When timestamps get corrupted. Fixing an import issue. (cherry picked from commit 3e1e3b0a7114801c3ce832a6e164e35ff9edd7d7) > Tombstone expiration: in the event that a version timestamp is too far in the > future, expire the tombstone > -- > > Key: GEODE-8958 > URL: https://issues.apache.org/jira/browse/GEODE-8958 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > We are seeing a bug where for some reason, the version timestamp on the > tombstone is too far into the future to be realistic. > > In such a case, we are going to expire the tombstone as soon as we see it. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8958) Tombstone expiration: in the event that a version timestamp is too far in the future, expire the tombstone
[ https://issues.apache.org/jira/browse/GEODE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294888#comment-17294888 ] ASF subversion and git services commented on GEODE-8958: Commit 3e1e3b0a7114801c3ce832a6e164e35ff9edd7d7 in geode's branch refs/heads/support/1.13 from Mark Hanson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3e1e3b0 ] GEODE-8958: When timestamps get corrupted. Fixing an import issue. > Tombstone expiration: in the event that a version timestamp is too far in the > future, expire the tombstone > -- > > Key: GEODE-8958 > URL: https://issues.apache.org/jira/browse/GEODE-8958 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > We are seeing a bug where for some reason, the version timestamp on the > tombstone is too far into the future to be realistic. > > In such a case, we are going to expire the tombstone as soon as we see it. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8999) When max-threads is specified for a cache server its reader threads may be reported as Stuck
[
https://issues.apache.org/jira/browse/GEODE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294880#comment-17294880
]
Darrel Schneider commented on GEODE-8999:
-
On second thought it seems like this should work. When max-threads is set
ServerConnection.run should not be called until we have detected that the
client socket has something on it to read. It then only does a single message
and returns itself to the Selector waiting to be run again. Is it possible in
the above stack that the client started to write a message and for some reason
did not finish writing it? If that happened then the Selector would have
detected a read event on the socket; asked the thread pool to execute the
ServerConnection; and then been stuck in it trying to read the complete message.
> When max-threads is specified for a cache server its reader threads may be
> reported as Stuck
>
>
> Key: GEODE-8999
> URL: https://issues.apache.org/jira/browse/GEODE-8999
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> We noticed this report of a stuck thread in a test that enabled max-threads
> in a cache server:
> {noformat}
> [warn 2021/03/02 19:54:31.041 PST bridgep2_host2_17822
> tid=0x1b] Thread <104> (0x68) that was executed at <02 Mar 2021 19:53:44 PST>
> has been stuck for <46.356 seconds> and number of thread monitor iteration <1>
> Thread Name state
> Executor Group
> Monitored metric
> Thread stack:
> sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> sun.nio.ch.IOUtil.read(IOUtil.java:192)
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378)
> org.apache.geode.internal.cache.tier.sockets.Message.readWrappedHeaders(Message.java:1237)
> org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:859)
> org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(Message.java:698)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1213)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1229)
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:816)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:777)
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:73)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1185)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:710)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$351/1357226696.invoke(Unknown
> Source)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$88/1800187767.run(Unknown
> Source)
> java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cache server should suspend thread monitoring before reading from a
> socket and resume monitoring afterward. An example of this can be found in
> org.apache.geode.internal.tcp.Connection.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8907) CI Failure: ClientServerTransactionCCEDUnitTest.testTxRemoveAll
[
https://issues.apache.org/jira/browse/GEODE-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294879#comment-17294879
]
ASF GitHub Bot commented on GEODE-8907:
---
pivotal-eshu commented on a change in pull request #6054:
URL: https://github.com/apache/geode/pull/6054#discussion_r586866920
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
##
@@ -3782,13 +3790,15 @@ public Object call() throws Exception {
@Override
public Object call() throws Exception {
TXManagerImpl mgr = getGemfireCache().getTxManager();
+mgr.resume(txid);
Review comment:
After you resume the transaction, the following code trying to resume
can be safely removed.
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
##
@@ -3749,14 +3756,15 @@ public Object call() throws Exception {
lr.validatedPut(event, System.currentTimeMillis());
lr.validatedPut(event, System.currentTimeMillis());
lr.validatedPut(event, System.currentTimeMillis());
-return null;
+return mgr.suspend();
}
});
server.invoke(new SerializableCallable() {
@Override
public Object call() throws Exception {
TXManagerImpl mgr = getGemfireCache().getTxManager();
+// mgr.resume(txid2);
Review comment:
You may want to clean up this commented out line.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI Failure: ClientServerTransactionCCEDUnitTest.testTxRemoveAll
> ---
>
> Key: GEODE-8907
> URL: https://issues.apache.org/jira/browse/GEODE-8907
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Assignee: Louis R. Jacome
>Priority: Major
> Labels: pull-request-available
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/794]
> reported a test failure
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest >
> testTxRemoveAll FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$34.call in VM 2
> running on Host c44a375b0bbd with 4 VMs
> Caused by:
> java.lang.IllegalStateException: Thread does not have an active
> transaction
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 0
> running on Host c44a375b0bbd with 4 VMs
> Caused by:
> java.lang.AssertionError: Event never occurred after 3 ms:
> {noformat}
>
> Logs available at
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0655/test-results/distributedTest/1612232803/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0655/test-artifacts/1612232803/distributedtestfiles-OpenJDK8-1.14.0-build.0655.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294875#comment-17294875
]
ASF GitHub Bot commented on GEODE-8998:
---
dschneider-pivotal commented on a change in pull request #6083:
URL: https://github.com/apache/geode/pull/6083#discussion_r586860552
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImplDummy.java
##
@@ -32,9 +32,17 @@ public boolean startMonitor(Mode mode) {
@Override
public void endMonitor() {}
+ private static class DummyAbstractExecutor extends AbstractExecutor {
Review comment:
done
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> setting thread-monitoring-enabled to false causes NullPointerException
> --
>
> Key: GEODE-8998
> URL: https://issues.apache.org/jira/browse/GEODE-8998
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> If you set the geode property thread-monitoring-enabled to false then any
> geode cluster messaging is broken. As cluster messages are read the p2p
> reader thread throws a NullPointerException.
> This bug was introduced in GEODE-8521 so it has not yet been released.
> I have a test that reproduces the NPE and this fix will be simple.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294874#comment-17294874
]
ASF GitHub Bot commented on GEODE-8998:
---
dschneider-pivotal commented on a change in pull request #6083:
URL: https://github.com/apache/geode/pull/6083#discussion_r586860430
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImplDummy.java
##
@@ -32,9 +32,17 @@ public boolean startMonitor(Mode mode) {
@Override
public void endMonitor() {}
+ private static class DummyAbstractExecutor extends AbstractExecutor {
+private static final DummyAbstractExecutor SINGLETON = new
DummyAbstractExecutor();
+
+private DummyAbstractExecutor() {
+ super("dummyExecutorGroup", 0L);
Review comment:
done
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> setting thread-monitoring-enabled to false causes NullPointerException
> --
>
> Key: GEODE-8998
> URL: https://issues.apache.org/jira/browse/GEODE-8998
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> If you set the geode property thread-monitoring-enabled to false then any
> geode cluster messaging is broken. As cluster messages are read the p2p
> reader thread throws a NullPointerException.
> This bug was introduced in GEODE-8521 so it has not yet been released.
> I have a test that reproduces the NPE and this fix will be simple.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8999) When max-threads is specified for a cache server its reader threads may be reported as Stuck
[
https://issues.apache.org/jira/browse/GEODE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294872#comment-17294872
]
Darrel Schneider commented on GEODE-8999:
-
I think this bug should be fixed by no longer monitoring these threads.
We have another ticket to improve the monitoring by included all server
connection threads (see GEODE-8761).
For this ticket (which may have been around since thread monitoring was added)
I think we should just change initializeServerConnectionThreadPool to pass null
instead of getThreadMonitorObj() when it creates selector thread pool
> When max-threads is specified for a cache server its reader threads may be
> reported as Stuck
>
>
> Key: GEODE-8999
> URL: https://issues.apache.org/jira/browse/GEODE-8999
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> We noticed this report of a stuck thread in a test that enabled max-threads
> in a cache server:
> {noformat}
> [warn 2021/03/02 19:54:31.041 PST bridgep2_host2_17822
> tid=0x1b] Thread <104> (0x68) that was executed at <02 Mar 2021 19:53:44 PST>
> has been stuck for <46.356 seconds> and number of thread monitor iteration <1>
> Thread Name state
> Executor Group
> Monitored metric
> Thread stack:
> sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> sun.nio.ch.IOUtil.read(IOUtil.java:192)
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378)
> org.apache.geode.internal.cache.tier.sockets.Message.readWrappedHeaders(Message.java:1237)
> org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:859)
> org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(Message.java:698)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1213)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1229)
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:816)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:777)
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:73)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1185)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:710)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$351/1357226696.invoke(Unknown
> Source)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$88/1800187767.run(Unknown
> Source)
> java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cache server should suspend thread monitoring before reading from a
> socket and resume monitoring afterward. An example of this can be found in
> org.apache.geode.internal.tcp.Connection.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8999) When max-threads is specified for a cache server its reader threads may be reported as Stuck
[
https://issues.apache.org/jira/browse/GEODE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8999:
--
Component/s: membership
> When max-threads is specified for a cache server its reader threads may be
> reported as Stuck
>
>
> Key: GEODE-8999
> URL: https://issues.apache.org/jira/browse/GEODE-8999
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> We noticed this report of a stuck thread in a test that enabled max-threads
> in a cache server:
> {noformat}
> [warn 2021/03/02 19:54:31.041 PST bridgep2_host2_17822
> tid=0x1b] Thread <104> (0x68) that was executed at <02 Mar 2021 19:53:44 PST>
> has been stuck for <46.356 seconds> and number of thread monitor iteration <1>
> Thread Name state
> Executor Group
> Monitored metric
> Thread stack:
> sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> sun.nio.ch.IOUtil.read(IOUtil.java:192)
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378)
> org.apache.geode.internal.cache.tier.sockets.Message.readWrappedHeaders(Message.java:1237)
> org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:859)
> org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(Message.java:698)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1213)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1229)
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:816)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:777)
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:73)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1185)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:710)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$351/1357226696.invoke(Unknown
> Source)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$88/1800187767.run(Unknown
> Source)
> java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cache server should suspend thread monitoring before reading from a
> socket and resume monitoring afterward. An example of this can be found in
> org.apache.geode.internal.tcp.Connection.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294870#comment-17294870
]
ASF GitHub Bot commented on GEODE-8998:
---
Bill commented on a change in pull request #6083:
URL: https://github.com/apache/geode/pull/6083#discussion_r586849213
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImplDummy.java
##
@@ -32,9 +32,17 @@ public boolean startMonitor(Mode mode) {
@Override
public void endMonitor() {}
+ private static class DummyAbstractExecutor extends AbstractExecutor {
+private static final DummyAbstractExecutor SINGLETON = new
DummyAbstractExecutor();
+
+private DummyAbstractExecutor() {
+ super("dummyExecutorGroup", 0L);
Review comment:
From looking at other group names they are typically capitalized like
class names and don't end in the word `Group`. So I recommend:
`"DummyExecutor"`
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImplDummy.java
##
@@ -32,9 +32,17 @@ public boolean startMonitor(Mode mode) {
@Override
public void endMonitor() {}
+ private static class DummyAbstractExecutor extends AbstractExecutor {
Review comment:
I think this new class is not meant to be subclassed so I recommend
removing `Abstract` from the name.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> setting thread-monitoring-enabled to false causes NullPointerException
> --
>
> Key: GEODE-8998
> URL: https://issues.apache.org/jira/browse/GEODE-8998
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> If you set the geode property thread-monitoring-enabled to false then any
> geode cluster messaging is broken. As cluster messages are read the p2p
> reader thread throws a NullPointerException.
> This bug was introduced in GEODE-8521 so it has not yet been released.
> I have a test that reproduces the NPE and this fix will be simple.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8997) remove protobuf client server code
[ https://issues.apache.org/jira/browse/GEODE-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-8997: --- Assignee: Bill Burcham > remove protobuf client server code > -- > > Key: GEODE-8997 > URL: https://issues.apache.org/jira/browse/GEODE-8997 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Darrel Schneider >Assignee: Bill Burcham >Priority: Major > > The protobuf based client/server project is essentially dead but code for it > is still part of geode. > This complicates the implementation. For example I was working on an > improvement to have the thread monitor detect stuck server connection threads > and found myself trying to figure out how to make this work for > ProtobufServerConnection. > I think it would be best to remove the dead protobuf code. I'm not sure what > all of it is but here is what I have found so far: > ProtobufServerConnection > package org.apache.geode.internal.cache.client.protocol > package org.apache.geode.internal.protocol.protobuf.v1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8958) Tombstone expiration: in the event that a version timestamp is too far in the future, expire the tombstone
[ https://issues.apache.org/jira/browse/GEODE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294866#comment-17294866 ] ASF subversion and git services commented on GEODE-8958: Commit 15af30d4f0a89df4168dcd5d80697143da944936 in geode's branch refs/heads/support/1.12 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=15af30d ] GEODE-8958: When tombstone timestamps get corrupted. (#6042) - The system would wait, now it does expires it and moves on. (cherry picked from commit 1fdcf3220704c858b64b053b0c27fb37c481b4a8) > Tombstone expiration: in the event that a version timestamp is too far in the > future, expire the tombstone > -- > > Key: GEODE-8958 > URL: https://issues.apache.org/jira/browse/GEODE-8958 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > We are seeing a bug where for some reason, the version timestamp on the > tombstone is too far into the future to be realistic. > > In such a case, we are going to expire the tombstone as soon as we see it. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8958) Tombstone expiration: in the event that a version timestamp is too far in the future, expire the tombstone
[ https://issues.apache.org/jira/browse/GEODE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294865#comment-17294865 ] ASF subversion and git services commented on GEODE-8958: Commit a125d370cc737e87514ce97226b065362cb33a0b in geode's branch refs/heads/support/1.13 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a125d37 ] GEODE-8958: When tombstone timestamps get corrupted. (#6042) - The system would wait, now it does expires it and moves on. (cherry picked from commit 465ff56ccc7430ee7676bc8e8ae354e35fed3b3e) > Tombstone expiration: in the event that a version timestamp is too far in the > future, expire the tombstone > -- > > Key: GEODE-8958 > URL: https://issues.apache.org/jira/browse/GEODE-8958 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > We are seeing a bug where for some reason, the version timestamp on the > tombstone is too far into the future to be realistic. > > In such a case, we are going to expire the tombstone as soon as we see it. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8965) Implement Redis "noevict" policy for Geode Redis
[ https://issues.apache.org/jira/browse/GEODE-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8965: -- Labels: blocks-1.14.0 pull-request-available (was: blocks-1.14.0) > Implement Redis "noevict" policy for Geode Redis > > > Key: GEODE-8965 > URL: https://issues.apache.org/jira/browse/GEODE-8965 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Raymond Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > Redis supports the "noevict" eviction policy. When this is selected, Redis > returns an OOM error when commands that consume new memory are attempted. New > data cannot be written to the cache until either TTL expiration or explicit > deletion of keys has freed enough memory to allow write operations again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8965) Implement Redis "noevict" policy for Geode Redis
[ https://issues.apache.org/jira/browse/GEODE-8965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294851#comment-17294851 ] ASF GitHub Bot commented on GEODE-8965: --- ringles opened a new pull request #6085: URL: https://github.com/apache/geode/pull/6085 This allows behavior simulating the Redis "noevict" out-of-memory policy. Operations that exceed the Geode configuration value of "critical-heap-percentage" will return a Redis-style "OOM" error message, which clients can respond to. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Implement Redis "noevict" policy for Geode Redis > > > Key: GEODE-8965 > URL: https://issues.apache.org/jira/browse/GEODE-8965 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Raymond Ingles >Priority: Major > Labels: blocks-1.14.0 > > Redis supports the "noevict" eviction policy. When this is selected, Redis > returns an OOM error when commands that consume new memory are attempted. New > data cannot be written to the cache until either TTL expiration or explicit > deletion of keys has freed enough memory to allow write operations again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8999) When max-threads is specified for a cache server its reader threads may be reported as Stuck
[
https://issues.apache.org/jira/browse/GEODE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8999:
--
Issue Type: Bug (was: Test)
> When max-threads is specified for a cache server its reader threads may be
> reported as Stuck
>
>
> Key: GEODE-8999
> URL: https://issues.apache.org/jira/browse/GEODE-8999
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> We noticed this report of a stuck thread in a test that enabled max-threads
> in a cache server:
> {noformat}
> [warn 2021/03/02 19:54:31.041 PST bridgep2_host2_17822
> tid=0x1b] Thread <104> (0x68) that was executed at <02 Mar 2021 19:53:44 PST>
> has been stuck for <46.356 seconds> and number of thread monitor iteration <1>
> Thread Name state
> Executor Group
> Monitored metric
> Thread stack:
> sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> sun.nio.ch.IOUtil.read(IOUtil.java:192)
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378)
> org.apache.geode.internal.cache.tier.sockets.Message.readWrappedHeaders(Message.java:1237)
> org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:859)
> org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(Message.java:698)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1213)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1229)
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:816)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:777)
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:73)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1185)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:710)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$351/1357226696.invoke(Unknown
> Source)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$88/1800187767.run(Unknown
> Source)
> java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cache server should suspend thread monitoring before reading from a
> socket and resume monitoring afterward. An example of this can be found in
> org.apache.geode.internal.tcp.Connection.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8999) When max-threads is specified for a cache server its reader threads may be reported as Stuck
[
https://issues.apache.org/jira/browse/GEODE-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8999:
--
Affects Version/s: 1.14.0
> When max-threads is specified for a cache server its reader threads may be
> reported as Stuck
>
>
> Key: GEODE-8999
> URL: https://issues.apache.org/jira/browse/GEODE-8999
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> We noticed this report of a stuck thread in a test that enabled max-threads
> in a cache server:
> {noformat}
> [warn 2021/03/02 19:54:31.041 PST bridgep2_host2_17822
> tid=0x1b] Thread <104> (0x68) that was executed at <02 Mar 2021 19:53:44 PST>
> has been stuck for <46.356 seconds> and number of thread monitor iteration <1>
> Thread Name state
> Executor Group
> Monitored metric
> Thread stack:
> sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> sun.nio.ch.IOUtil.read(IOUtil.java:192)
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378)
> org.apache.geode.internal.cache.tier.sockets.Message.readWrappedHeaders(Message.java:1237)
> org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:859)
> org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(Message.java:698)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1213)
> org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1229)
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:816)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:777)
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:73)
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1185)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:710)
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$351/1357226696.invoke(Unknown
> Source)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$88/1800187767.run(Unknown
> Source)
> java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cache server should suspend thread monitoring before reading from a
> socket and resume monitoring afterward. An example of this can be found in
> org.apache.geode.internal.tcp.Connection.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8958) Tombstone expiration: in the event that a version timestamp is too far in the future, expire the tombstone
[ https://issues.apache.org/jira/browse/GEODE-8958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294849#comment-17294849 ] ASF subversion and git services commented on GEODE-8958: Commit 1986468212d50ae7c91d839209bf24c89449f1ac in geode's branch refs/heads/support/1.14 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1986468 ] GEODE-8958: When tombstone timestamps get corrupted. (#6042) - The system would wait, now it does expires it and moves on. (cherry picked from commit ab59830ecf754957b76e5fba068f653b03d467a9) > Tombstone expiration: in the event that a version timestamp is too far in the > future, expire the tombstone > -- > > Key: GEODE-8958 > URL: https://issues.apache.org/jira/browse/GEODE-8958 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > We are seeing a bug where for some reason, the version timestamp on the > tombstone is too far into the future to be realistic. > > In such a case, we are going to expire the tombstone as soon as we see it. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8999) When max-threads is specified for a cache server its reader threads may be reported as Stuck
Bruce J Schuchardt created GEODE-8999:
-
Summary: When max-threads is specified for a cache server its
reader threads may be reported as Stuck
Key: GEODE-8999
URL: https://issues.apache.org/jira/browse/GEODE-8999
Project: Geode
Issue Type: Test
Components: client/server
Reporter: Bruce J Schuchardt
We noticed this report of a stuck thread in a test that enabled max-threads in
a cache server:
{noformat}
[warn 2021/03/02 19:54:31.041 PST bridgep2_host2_17822
tid=0x1b] Thread <104> (0x68) that was executed at <02 Mar 2021 19:53:44 PST>
has been stuck for <46.356 seconds> and number of thread monitor iteration <1>
Thread Name state
Executor Group
Monitored metric
Thread stack:
sun.nio.ch.FileDispatcherImpl.read0(Native Method)
sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
sun.nio.ch.IOUtil.read(IOUtil.java:192)
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:378)
org.apache.geode.internal.cache.tier.sockets.Message.readWrappedHeaders(Message.java:1237)
org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:859)
org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(Message.java:698)
org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1213)
org.apache.geode.internal.cache.tier.sockets.Message.receive(Message.java:1229)
org.apache.geode.internal.cache.tier.sockets.BaseCommand.readRequest(BaseCommand.java:816)
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:777)
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:73)
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1185)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:710)
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$$Lambda$351/1357226696.invoke(Unknown
Source)
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$88/1800187767.run(Unknown
Source)
java.lang.Thread.run(Thread.java:748)
{noformat}
The cache server should suspend thread monitoring before reading from a socket
and resume monitoring afterward. An example of this can be found in
org.apache.geode.internal.tcp.Connection.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8859) Redis data structures may not accurately reflect their size in Geode stats
[
https://issues.apache.org/jira/browse/GEODE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8859:
--
Labels: blocks-1.14.0 pull-request-available release-blocker (was:
blocks-1.14.0 release-blocker)
> Redis data structures may not accurately reflect their size in Geode stats
> --
>
> Key: GEODE-8859
> URL: https://issues.apache.org/jira/browse/GEODE-8859
> Project: Geode
> Issue Type: Bug
> Components: redis, statistics
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Raymond Ingles
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available, release-blocker
>
> Here is a comment from Darrel regarding this issue. For some background, the
> Redis structures implement {{Delta}}.
>
> {quote}I was playing around with RedisInsight and was able to get most the
> the overview dashboard and the data browser working with geode redis. But I
> found a problem with how we are using geode that causes the geode stats that
> track how much data is stored in a partitioned region to be wrong and the
> bucket sizes used for rebalancing are also wrong. Basically when we do create
> ops on the region the stats track it okay. But when we do updates then geode
> always thinks that nothing (size wise) changed. So for example I created a
> string by doing a redis “set” command. I saw the size of the string accounted
> for in dataStoreBytesInUse. But then I kept doing redis “append” commands on
> that key and the dataStoreBytesInUse did not change at all. I think the
> problem is in how we are updating the data structure in place instead of
> getting a copy, modifying it, and then putting the copy into the region.
> Avoiding this copy gives us MUCH better performance but it messes up geode
> when it is trying to calculate the memory increase or decrease. It is
> possible that this is only an issue on the primary and that the secondary
> sizing may be correct. If so that could lead to other problems because for a
> given bucket our primary size would be different than the secondary. The
> bucket sizes are used when you do a rebalance but basically we can have a
> bunch of memory that is “untracked” so we might see the JVM heaps unbalanced
> but geode will think the buckets are balanced. I’m not sure what we should do
> about this.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8859) Redis data structures may not accurately reflect their size in Geode stats
[
https://issues.apache.org/jira/browse/GEODE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294840#comment-17294840
]
ASF GitHub Bot commented on GEODE-8859:
---
jhutchison opened a new pull request #6084:
URL: https://github.com/apache/geode/pull/6084
…e reporting
-implement default getForceReCalculateSize in RedisData interface
-expose dataStoreBytesInUse on GeodeRedisServer
-expose dataStoreBytesInUse on GeodeRedisService
-expose dataStoreBytesInUse on RedisClusterStartupRule
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Redis data structures may not accurately reflect their size in Geode stats
> --
>
> Key: GEODE-8859
> URL: https://issues.apache.org/jira/browse/GEODE-8859
> Project: Geode
> Issue Type: Bug
> Components: redis, statistics
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Raymond Ingles
>Priority: Major
> Labels: blocks-1.14.0, release-blocker
>
> Here is a comment from Darrel regarding this issue. For some background, the
> Redis structures implement {{Delta}}.
>
> {quote}I was playing around with RedisInsight and was able to get most the
> the overview dashboard and the data browser working with geode redis. But I
> found a problem with how we are using geode that causes the geode stats that
> track how much data is stored in a partitioned region to be wrong and the
> bucket sizes used for rebalancing are also wrong. Basically when we do create
> ops on the region the stats track it okay. But when we do updates then geode
> always thinks that nothing (size wise) changed. So for example I created a
> string by doing a redis “set” command. I saw the size of the string accounted
> for in dataStoreBytesInUse. But then I kept doing redis “append” commands on
> that key and the dataStoreBytesInUse did not change at all. I think the
> problem is in how we are updating the data structure in place instead of
> getting a copy, modifying it, and then putting the copy into the region.
> Avoiding this copy gives us MUCH better performance but it messes up geode
> when it is trying to calculate the memory increase or decrease. It is
> possible that this is only an issue on the primary and that the secondary
> sizing may be correct. If so that could lead to other problems because for a
> given bucket our primary size would be different than the secondary. The
> bucket sizes are used when you do a rebalance but basically we can have a
> bunch of memory that is “untracked” so we might see the JVM heaps unbalanced
> but geode will think the buckets are balanced. I’m not sure what we should do
> about this.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8907) CI Failure: ClientServerTransactionCCEDUnitTest.testTxRemoveAll
[
https://issues.apache.org/jira/browse/GEODE-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294828#comment-17294828
]
ASF GitHub Bot commented on GEODE-8907:
---
pivotal-eshu commented on a change in pull request #6054:
URL: https://github.com/apache/geode/pull/6054#discussion_r586752182
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
##
@@ -2076,10 +2078,11 @@ public Object call() throws Exception {
}
});
-client.invoke(new SerializableCallable() {
+TXId txid2 = (TXId) client.invoke(new SerializableCallable() {
Review comment:
There is no need to have a new txId here, unless you want to assert this
is the same as txId. There is only one transaction. Probably just ignore the
return value here. And later resume the original txId instead of txid2.
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/RemoteTransactionDUnitTest.java
##
@@ -3010,50 +3024,82 @@ public Object call() throws Exception {
}
});
-SerializableCallable testFnOnDs = new SerializableCallable() {
- @Override
- public Object call() throws Exception {
-TXManagerImpl mgr = getGemfireCache().getTXMgr();
-PartitionedRegion pr = (PartitionedRegion)
getGemfireCache().getRegion(CUSTOMER);
-CustId keyOnDs = getKeyOnMember(pr.getMyId(), pr);
-mgr.begin();
-pr.get(keyOnDs);
-Set filter = new HashSet();
-filter.add(keyOnDs);
-
FunctionService.onRegion(pr).withFilter(filter).execute(TXFunction.id).getResult();
-assertEquals(expectedCustomer, pr.get(expectedCustId));
-TXStateProxy tx = mgr.pauseTransaction();
-assertNull(pr.get(expectedCustId));
-mgr.unpauseTransaction(tx);
-return null;
- }
-};
-SerializableCallable closeTx = new SerializableCallable() {
- @Override
- public Object call() throws Exception {
-Region custRegion = getGemfireCache().getRegion(CUSTOMER);
-CacheTransactionManager mgr = getGemfireCache().getTXMgr();
-mgr.commit();
-assertEquals(expectedCustomer, custRegion.get(expectedCustId));
-custRegion.destroy(expectedCustId);
-return null;
- }
-};
-
if (owner.equals(ds1)) {
- datastore1.invoke(testFnOnDs);
+ TXId dsTxId = (TXId) datastore1.invoke(
Review comment:
Should not duplicate the code here, should reuse the existing callables.
To pass in different txIds in the callable, you can see how DoOpsInTX is
implemented.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI Failure: ClientServerTransactionCCEDUnitTest.testTxRemoveAll
> ---
>
> Key: GEODE-8907
> URL: https://issues.apache.org/jira/browse/GEODE-8907
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Assignee: Louis R. Jacome
>Priority: Major
> Labels: pull-request-available
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/794]
> reported a test failure
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest >
> testTxRemoveAll FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$34.call in VM 2
> running on Host c44a375b0bbd with 4 VMs
> Caused by:
> java.lang.IllegalStateException: Thread does not have an active
> transaction
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 0
> running on Host c44a375b0bbd with 4 VMs
> Caused by:
> java.lang.AssertionError: Event never occurred after 3 ms:
> {noformat}
>
> Logs available at
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0655/test-results/distributedTest/1612232803/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0655/test-artifacts/1612232803/distributedtestfiles-OpenJDK8-1.14.0-build.0655.tgz
> {noformat}
--
This message was s
[jira] [Updated] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[ https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8998: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > setting thread-monitoring-enabled to false causes NullPointerException > -- > > Key: GEODE-8998 > URL: https://issues.apache.org/jira/browse/GEODE-8998 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > If you set the geode property thread-monitoring-enabled to false then any > geode cluster messaging is broken. As cluster messages are read the p2p > reader thread throws a NullPointerException. > This bug was introduced in GEODE-8521 so it has not yet been released. > I have a test that reproduces the NPE and this fix will be simple. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[ https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294782#comment-17294782 ] ASF GitHub Bot commented on GEODE-8998: --- dschneider-pivotal opened a new pull request #6083: URL: https://github.com/apache/geode/pull/6083 The P2PReaderExecutorGroup is now called directly since the p2p reader always needs a non-null instance. When thread monitoring is disabled, the p2p reader will still call suspend and resume even though the P2PReaderExecutorGroup is not being monitored. But these calls are very cheap so it is better to call them instead of doing a bunch of null checks. Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > setting thread-monitoring-enabled to false causes NullPointerException > -- > > Key: GEODE-8998 > URL: https://issues.apache.org/jira/browse/GEODE-8998 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > If you set the geode property thread-monitoring-enabled to false then any > geode cluster messaging is broken. As cluster messages are read the p2p > reader thread throws a NullPointerException. > This bug was introduced in GEODE-8521 so it has not yet been released. > I have a test that reproduces the NPE and this fix will be simple. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[
https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294773#comment-17294773
]
ASF GitHub Bot commented on GEODE-8996:
---
onichols-pivotal commented on a change in pull request #6080:
URL: https://github.com/apache/geode/pull/6080#discussion_r586726019
##
File path:
geode-assembly/src/distributedTest/java/org/apache/geode/rest/internal/web/controllers/RestAPICompatibilityTest.java
##
@@ -0,0 +1,196 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ *
+ */
+package org.apache.geode.rest.internal.web.controllers;
+
+import static org.junit.Assert.assertTrue;
+
+import java.io.BufferedReader;
+import java.io.InputStream;
+import java.io.InputStreamReader;
+import java.util.Collection;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+import com.fasterxml.jackson.core.JsonProcessingException;
+import com.fasterxml.jackson.databind.JsonNode;
+import com.fasterxml.jackson.databind.ObjectMapper;
+import org.apache.http.HttpEntity;
+import org.apache.http.client.methods.CloseableHttpResponse;
+import org.apache.http.client.methods.HttpGet;
+import org.apache.http.client.methods.HttpPost;
+import org.apache.http.entity.ContentType;
+import org.apache.http.entity.StringEntity;
+import org.apache.http.impl.client.CloseableHttpClient;
+import org.apache.http.impl.client.HttpClients;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+import org.junit.runner.RunWith;
+import org.junit.runners.Parameterized;
+
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.management.configuration.DiskStore;
+import org.apache.geode.management.operation.RebalanceOperation;
+import org.apache.geode.management.operation.RestoreRedundancyRequest;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.categories.BackwardCompatibilityTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import org.apache.geode.test.junit.rules.MemberStarterRule;
+import org.apache.geode.test.version.TestVersion;
+import org.apache.geode.test.version.VersionManager;
+import org.apache.geode.util.internal.GeodeJsonMapper;
+
+@Category({BackwardCompatibilityTest.class})
+@RunWith(Parameterized.class)
+public class RestAPICompatibilityTest {
+ private final String oldVersion;
+ private static ObjectMapper mapper = GeodeJsonMapper.getMapper();
+
+ @Parameterized.Parameters(name = "{0}")
+ public static Collection data() {
+List result =
VersionManager.getInstance().getVersionsWithoutCurrent();
+result.removeIf(s -> TestVersion.compare(s, "1.11.0") < 0);
+return result;
+ }
+
+ @Rule
+ public ClusterStartupRule cluster = new ClusterStartupRule();
+
+ @Rule
+ public GfshCommandRule gfsh = new GfshCommandRule();
+
+ public RestAPICompatibilityTest(String oldVersion) throws
JsonProcessingException {
+this.oldVersion = oldVersion;
+DiskStore diskStore = new DiskStore();
+diskStore.setName("diskStore");
+postRESTAPICalls = new HashMap<>();
+// {REST endpoint,{Body, Successful Status Message, Introduced in version}}
+postRESTAPICalls.put("/management/v1/operations/rebalances",
+new String[] {mapper.writeValueAsString(new RebalanceOperation()),
"Operation started",
+"1.11.0"});
+postRESTAPICalls.put("/management/v1/operations/restoreRedundancy",
+new String[] {mapper.writeValueAsString(new
RestoreRedundancyRequest()),
+"Operation started", "1.13.1"});
+ }
+
+ private static Map postRESTAPICalls;
+
+
+ private static final String[][] getRESTAPICalls = {
+ // REST endpoint , status
+ {"/geode-mgmt/v1/management/commands?cmd=rebalance", "OK"}
+ };
+
+ @Test
+ public void restCommandExecutedOnLatestLocatorShouldBeBackwardsCompatible()
throws Exception {
+// Initialize all cluster members with old versions
+MemberVM locator1 =
+cluster.startLocatorVM(0, 0, oldVersion,
MemberStarterRule::withHttpService);
+int locatorPort1 = locator1.getPort();
+
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[ https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294772#comment-17294772 ] ASF GitHub Bot commented on GEODE-8864: --- jhutchison commented on pull request #5954: URL: https://github.com/apache/geode/pull/5954#issuecomment-790004759 @sabbey (for some reason this particular comment won't let me reply on it ) regarding the test givenCount_returnsAllEntriesWithoutDuplicates() mentioned above- that test seemed not super valuable like it was (testing that the entire set was returned), so I changed it a little and moved it to the (concrete) HScanIntegrationTest (since our implementation doesn't really match native Redis' exactly. ). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > finish implementation of Redis HScan Command > > > Key: GEODE-8864 > URL: https://issues.apache.org/jira/browse/GEODE-8864 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: blocks-1.14.0, pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender
[
https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294767#comment-17294767
]
ASF GitHub Bot commented on GEODE-8971:
---
kirklund commented on a change in pull request #6052:
URL: https://github.com/apache/geode/pull/6052#discussion_r586714691
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegionQueue.java
##
@@ -453,21 +454,22 @@ public Object peek() {
* If a matching object also fulfills the endPredicate then the method
* stops looking for more matching objects.
*/
- public List getElementsMatching(Predicate matchingPredicate,
Predicate endPredicate) {
+ public List getElementsMatching(Predicate
matchingPredicate,
Review comment:
You might want to change from `GatewaySenderEventImpl` to your new
`InternalGatewaySenderEvent` everywhere you've added new code. I don't see
anything that would obviously break, and it would be great to start using that
new interface in newer code.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Batches with incomplete transactions when stopping the gateway sender
> -
>
> Key: GEODE-8971
> URL: https://issues.apache.org/jira/browse/GEODE-8971
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> When the gateway sender is stopped there is a high probability that batches
> with incomplete transactions are sent even if group-transaction-events is
> enabled.
> The reason is that once the stop command reaches the gateway sender, it
> immediately stops queueing events, and this could happen in the middle of
> receiving events for the same transaction. If this is the case, some events
> for the transaction may have reached the queue right before the stop command
> was received and the rest of events for that transaction would not make it to
> the queue (they would be dropped) because they arrived right after the stop
> command was received at the gateway sender.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender
[
https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294765#comment-17294765
]
ASF GitHub Bot commented on GEODE-8971:
---
kirklund commented on a change in pull request #6052:
URL: https://github.com/apache/geode/pull/6052#discussion_r586714691
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegionQueue.java
##
@@ -453,21 +454,22 @@ public Object peek() {
* If a matching object also fulfills the endPredicate then the method
* stops looking for more matching objects.
*/
- public List getElementsMatching(Predicate matchingPredicate,
Predicate endPredicate) {
+ public List getElementsMatching(Predicate
matchingPredicate,
Review comment:
You might want to change from `GatewaySenderEventImpl` to your new
`InternalGatewaySenderEvent` everywhere you've added new code. I don't see
anything that would obviously break.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Batches with incomplete transactions when stopping the gateway sender
> -
>
> Key: GEODE-8971
> URL: https://issues.apache.org/jira/browse/GEODE-8971
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> When the gateway sender is stopped there is a high probability that batches
> with incomplete transactions are sent even if group-transaction-events is
> enabled.
> The reason is that once the stop command reaches the gateway sender, it
> immediately stops queueing events, and this could happen in the middle of
> receiving events for the same transaction. If this is the case, some events
> for the transaction may have reached the queue right before the stop command
> was received and the rest of events for that transaction would not make it to
> the queue (they would be dropped) because they arrived right after the stop
> command was received at the gateway sender.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[ https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-8998: Labels: GeodeOperationAPI (was: ) > setting thread-monitoring-enabled to false causes NullPointerException > -- > > Key: GEODE-8998 > URL: https://issues.apache.org/jira/browse/GEODE-8998 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > If you set the geode property thread-monitoring-enabled to false then any > geode cluster messaging is broken. As cluster messages are read the p2p > reader thread throws a NullPointerException. > This bug was introduced in GEODE-8521 so it has not yet been released. > I have a test that reproduces the NPE and this fix will be simple. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
Darrel Schneider created GEODE-8998: --- Summary: setting thread-monitoring-enabled to false causes NullPointerException Key: GEODE-8998 URL: https://issues.apache.org/jira/browse/GEODE-8998 Project: Geode Issue Type: Bug Components: core Reporter: Darrel Schneider If you set the geode property thread-monitoring-enabled to false then any geode cluster messaging is broken. As cluster messages are read the p2p reader thread throws a NullPointerException. This bug was introduced in GEODE-8521 so it has not yet been released. I have a test that reproduces the NPE and this fix will be simple. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8998) setting thread-monitoring-enabled to false causes NullPointerException
[ https://issues.apache.org/jira/browse/GEODE-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-8998: --- Assignee: Darrel Schneider > setting thread-monitoring-enabled to false causes NullPointerException > -- > > Key: GEODE-8998 > URL: https://issues.apache.org/jira/browse/GEODE-8998 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > If you set the geode property thread-monitoring-enabled to false then any > geode cluster messaging is broken. As cluster messages are read the p2p > reader thread throws a NullPointerException. > This bug was introduced in GEODE-8521 so it has not yet been released. > I have a test that reproduces the NPE and this fix will be simple. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[
https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294750#comment-17294750
]
ASF GitHub Bot commented on GEODE-8996:
---
kirklund commented on a change in pull request #6080:
URL: https://github.com/apache/geode/pull/6080#discussion_r586693423
##
File path:
geode-assembly/src/distributedTest/java/org/apache/geode/rest/internal/web/controllers/RestAPICompatibilityTest.java
##
@@ -0,0 +1,196 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ *
+ */
+package org.apache.geode.rest.internal.web.controllers;
+
+import static org.junit.Assert.assertTrue;
+
+import java.io.BufferedReader;
+import java.io.InputStream;
+import java.io.InputStreamReader;
+import java.util.Collection;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+import com.fasterxml.jackson.core.JsonProcessingException;
+import com.fasterxml.jackson.databind.JsonNode;
+import com.fasterxml.jackson.databind.ObjectMapper;
+import org.apache.http.HttpEntity;
+import org.apache.http.client.methods.CloseableHttpResponse;
+import org.apache.http.client.methods.HttpGet;
+import org.apache.http.client.methods.HttpPost;
+import org.apache.http.entity.ContentType;
+import org.apache.http.entity.StringEntity;
+import org.apache.http.impl.client.CloseableHttpClient;
+import org.apache.http.impl.client.HttpClients;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+import org.junit.runner.RunWith;
+import org.junit.runners.Parameterized;
+
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.management.configuration.DiskStore;
+import org.apache.geode.management.operation.RebalanceOperation;
+import org.apache.geode.management.operation.RestoreRedundancyRequest;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.categories.BackwardCompatibilityTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import org.apache.geode.test.junit.rules.MemberStarterRule;
+import org.apache.geode.test.version.TestVersion;
+import org.apache.geode.test.version.VersionManager;
+import org.apache.geode.util.internal.GeodeJsonMapper;
+
+@Category({BackwardCompatibilityTest.class})
+@RunWith(Parameterized.class)
+public class RestAPICompatibilityTest {
+ private final String oldVersion;
+ private static ObjectMapper mapper = GeodeJsonMapper.getMapper();
+
+ @Parameterized.Parameters(name = "{0}")
+ public static Collection data() {
+List result =
VersionManager.getInstance().getVersionsWithoutCurrent();
+result.removeIf(s -> TestVersion.compare(s, "1.11.0") < 0);
+return result;
+ }
+
+ @Rule
+ public ClusterStartupRule cluster = new ClusterStartupRule();
+
+ @Rule
+ public GfshCommandRule gfsh = new GfshCommandRule();
+
+ public RestAPICompatibilityTest(String oldVersion) throws
JsonProcessingException {
+this.oldVersion = oldVersion;
+DiskStore diskStore = new DiskStore();
+diskStore.setName("diskStore");
+postRESTAPICalls = new HashMap<>();
+// {REST endpoint,{Body, Successful Status Message, Introduced in version}}
+postRESTAPICalls.put("/management/v1/operations/rebalances",
+new String[] {mapper.writeValueAsString(new RebalanceOperation()),
"Operation started",
+"1.11.0"});
+postRESTAPICalls.put("/management/v1/operations/restoreRedundancy",
+new String[] {mapper.writeValueAsString(new
RestoreRedundancyRequest()),
+"Operation started", "1.13.1"});
+ }
+
+ private static Map postRESTAPICalls;
+
+
+ private static final String[][] getRESTAPICalls = {
+ // REST endpoint , status
+ {"/geode-mgmt/v1/management/commands?cmd=rebalance", "OK"}
+ };
+
+ @Test
+ public void restCommandExecutedOnLatestLocatorShouldBeBackwardsCompatible()
throws Exception {
+// Initialize all cluster members with old versions
+MemberVM locator1 =
+cluster.startLocatorVM(0, 0, oldVersion,
MemberStarterRule::withHttpService);
+int locatorPort1 = locator1.getPort();
+Memb
[jira] [Commented] (GEODE-8992) When a GatewaySenderEventImpl is serialized, its operationDetail field is not included
[
https://issues.apache.org/jira/browse/GEODE-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294738#comment-17294738
]
ASF GitHub Bot commented on GEODE-8992:
---
boglesby opened a new pull request #6082:
URL: https://github.com/apache/geode/pull/6082
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> When a GatewaySenderEventImpl is serialized, its operationDetail field is not
> included
> --
>
> Key: GEODE-8992
> URL: https://issues.apache.org/jira/browse/GEODE-8992
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: blocks-1.15.0
>
> This causes the operation to become less specific when the
> {{GatewaySenderEventImpl}} is deserialized.
> Here is an example.
> If the original {{GatewaySenderEventImpl}} is a *PUTALL_CREATE* like:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=PUTALL_CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Then, when the {{GatewaySenderEventImpl}} is serialized and deserialized, its
> operation becomes a *CREATE*:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Thats because {{GatewaySenderEventImpl.getOperation}} uses both *action* and
> *operationDetail* to determine its operation:
> {noformat}
> public Operation getOperation() {
> Operation op = null;
> switch (this.action) {
> case CREATE_ACTION:
> switch (this.operationDetail) {
> case ...
> case OP_DETAIL_PUTALL:
> op = Operation.PUTALL_CREATE;
> break;
> default:
> op = Operation.CREATE;
> break;
> }
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8992) When a GatewaySenderEventImpl is serialized, its operationDetail field is not included
[
https://issues.apache.org/jira/browse/GEODE-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8992:
--
Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0)
> When a GatewaySenderEventImpl is serialized, its operationDetail field is not
> included
> --
>
> Key: GEODE-8992
> URL: https://issues.apache.org/jira/browse/GEODE-8992
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> This causes the operation to become less specific when the
> {{GatewaySenderEventImpl}} is deserialized.
> Here is an example.
> If the original {{GatewaySenderEventImpl}} is a *PUTALL_CREATE* like:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=PUTALL_CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Then, when the {{GatewaySenderEventImpl}} is serialized and deserialized, its
> operation becomes a *CREATE*:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Thats because {{GatewaySenderEventImpl.getOperation}} uses both *action* and
> *operationDetail* to determine its operation:
> {noformat}
> public Operation getOperation() {
> Operation op = null;
> switch (this.action) {
> case CREATE_ACTION:
> switch (this.operationDetail) {
> case ...
> case OP_DETAIL_PUTALL:
> op = Operation.PUTALL_CREATE;
> break;
> default:
> op = Operation.CREATE;
> break;
> }
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8992) When a GatewaySenderEventImpl is serialized, its operationDetail field is not included
[
https://issues.apache.org/jira/browse/GEODE-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294740#comment-17294740
]
ASF subversion and git services commented on GEODE-8992:
Commit 97c95520e6eabdb1bb8cfa6708e0b812da8b2c17 in geode's branch
refs/heads/feature/GEODE-8992 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=97c9552 ]
GEODE-8992: Added operationDetail to toData/fromData
> When a GatewaySenderEventImpl is serialized, its operationDetail field is not
> included
> --
>
> Key: GEODE-8992
> URL: https://issues.apache.org/jira/browse/GEODE-8992
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> This causes the operation to become less specific when the
> {{GatewaySenderEventImpl}} is deserialized.
> Here is an example.
> If the original {{GatewaySenderEventImpl}} is a *PUTALL_CREATE* like:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=PUTALL_CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Then, when the {{GatewaySenderEventImpl}} is serialized and deserialized, its
> operation becomes a *CREATE*:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Thats because {{GatewaySenderEventImpl.getOperation}} uses both *action* and
> *operationDetail* to determine its operation:
> {noformat}
> public Operation getOperation() {
> Operation op = null;
> switch (this.action) {
> case CREATE_ACTION:
> switch (this.operationDetail) {
> case ...
> case OP_DETAIL_PUTALL:
> op = Operation.PUTALL_CREATE;
> break;
> default:
> op = Operation.CREATE;
> break;
> }
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8979) CI Failure: SSLSocketHostNameVerificationIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294713#comment-17294713
]
ASF GitHub Bot commented on GEODE-8979:
---
echobravopapa commented on a change in pull request #6079:
URL: https://github.com/apache/geode/pull/6079#discussion_r586663171
##
File path:
geode-core/src/integrationTest/java/org/apache/geode/internal/net/SSLSocketHostNameVerificationIntegrationTest.java
##
@@ -211,18 +211,17 @@ private Thread startServerNIO(final ServerSocket
serverSocket, int timeoutMillis
} catch (Throwable throwable) {
serverException = throwable;
} finally {
-if (engine != null && socket != null) {
+if (engine != null) {
Review comment:
what a helpful tool!
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI Failure: SSLSocketHostNameVerificationIntegrationTest
>
>
> Key: GEODE-8979
> URL: https://issues.apache.org/jira/browse/GEODE-8979
> Project: Geode
> Issue Type: Test
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> This test failed in a CI IntegrationTest run with this exception:
> {noformat}
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest >
> nioHandshakeValidatesHostName[hasSAN=true and doEndPointIdentification=true]
> FAILED
> org.apache.geode.GemFireIOException: exception closing SSL session
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:409)
> at
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest.lambda$startServerNIO$3(SSLSocketHostNameVerificationIntegrationTest.java:216)
> Caused by:
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470)
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:403)
> ... 1 more
> {noformat}
> It looks like the test needs to have a try/catch for IOException when closing
> the NioSslEngine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-8943) Filterrs (Interest and CQ) is processed multiple times with transactional operation on PR
[ https://issues.apache.org/jira/browse/GEODE-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291974#comment-17291974 ] Eric Shu edited comment on GEODE-8943 at 3/3/21, 6:12 PM: -- Compute interested client on remote node (far side from tx host) exists earlier before 1.14 as register interest can occur after tx committed on tx host. GEODE-8559 to address a race condition that LocalRegion.generateLocalFilterRouting can not compute correct interested clients during tx commit on the remote node. I do not see a valid way to address this issue without re-compute it again to avoid data inconsistency between client and server without this change. was (Author: eshu): GEODE-8559 to address a race condition that LocalRegion.generateLocalFilterRouting can not compute correct interested clients during tx commit. I do not see a valid way to address this issue without re-compute it again to avoid data inconsistency between client and server without this change. > Filterrs (Interest and CQ) is processed multiple times with transactional > operation on PR > - > > Key: GEODE-8943 > URL: https://issues.apache.org/jira/browse/GEODE-8943 > Project: Geode > Issue Type: Bug > Components: cq, regions >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The Filters (interest and CQ) could be getting processed multiple times when > transactional operation is performed. > By design on PR the filters are processed on primary bucket where the data is > applied/changed and adjunct message with interested clients are sent to > remote servers (where the subscription queues are hosted) and replicas; thus > performing filter processing once and sending the message to remote servers > only if the filters are satisfied; it looks like currently the filter > processing is happening both at the primary and secondary buckets for TX > operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-8943) Filterrs (Interest and CQ) is processed multiple times with transactional operation on PR
[ https://issues.apache.org/jira/browse/GEODE-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291974#comment-17291974 ] Eric Shu edited comment on GEODE-8943 at 3/3/21, 6:07 PM: -- GEODE-8559 to address a race condition that LocalRegion.generateLocalFilterRouting can not compute correct interested clients during tx commit. I do not see a valid way to address this issue without re-compute it again to avoid data inconsistency between client and server without this change. was (Author: eshu): This is introduced in GEODE-8559 to address a race condition that LocalRegion.generateLocalFilterRouting can not compute correct interested clients during tx commit. I do not see a valid way to address this issue without re-compute it again to avoid data inconsistency between client and server without this change. > Filterrs (Interest and CQ) is processed multiple times with transactional > operation on PR > - > > Key: GEODE-8943 > URL: https://issues.apache.org/jira/browse/GEODE-8943 > Project: Geode > Issue Type: Bug > Components: cq, regions >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The Filters (interest and CQ) could be getting processed multiple times when > transactional operation is performed. > By design on PR the filters are processed on primary bucket where the data is > applied/changed and adjunct message with interested clients are sent to > remote servers (where the subscription queues are hosted) and replicas; thus > performing filter processing once and sending the message to remote servers > only if the filters are satisfied; it looks like currently the filter > processing is happening both at the primary and secondary buckets for TX > operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[
https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294703#comment-17294703
]
ASF GitHub Bot commented on GEODE-8996:
---
nabarunnag commented on a change in pull request #6080:
URL: https://github.com/apache/geode/pull/6080#discussion_r586648043
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/operation/RebalanceOperationPerformer.java
##
@@ -445,6 +448,20 @@ RebalanceResult executeRebalanceOnDS(ManagementService
managementService,
return rebalanceResult;
}
+ @NotNull
+ private Function getRebalanceFunction(InternalDistributedMember dsMember) {
+Function rebalanceFunction;
+System.out.println("NABA " + dsMember.getVersion().toString());
Review comment:
removed.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Rebalance GFSH commands and restore redundancy commands were not backward
> compatible
>
>
> Key: GEODE-8996
> URL: https://issues.apache.org/jira/browse/GEODE-8996
> Project: Geode
> Issue Type: Bug
> Components: gfsh, rest (admin)
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> Issue:
> * Rebalance command when executed with 1.12.0+ locator and older servers,
> the command failed
> * This was because the Rebalance function moved to a new package
> * Similar problem with REST calls because of moving CacheRealizationFunction
> to a new package
> * There was another problem where Serializable classes with UIDs were
> changed in couple of releases
> * The variation of the UIDs caused deserialization issues when REST commands
> were executed from new locators and old servers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294702#comment-17294702 ] ASF GitHub Bot commented on GEODE-7309: --- karensmolermiller commented on a change in pull request #6076: URL: https://github.com/apache/geode/pull/6076#discussion_r586647844 ## File path: geode-docs/tools_modules/lucene_integration.html.md.erb ## @@ -334,6 +334,7 @@ Lucene indexes created for all members. # Requirements and Caveats - Join queries between regions are not supported. +- Executing queries is possible after all members are at the same version. Review comment: This statement is not quite specific enough. I'm guessing that all members must be at the same minor version number (not necessarily the same patch version within the minor). I'm also guessing that this is just for Lucene queries. If I'm correct in my guesses, an attempt at better wording might be > All cluster members must be running the same minor version in order to execute Lucene queries. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[
https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294695#comment-17294695
]
ASF GitHub Bot commented on GEODE-8996:
---
dickcav commented on a change in pull request #6080:
URL: https://github.com/apache/geode/pull/6080#discussion_r586640274
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/operation/RebalanceOperationPerformer.java
##
@@ -445,6 +448,20 @@ RebalanceResult executeRebalanceOnDS(ManagementService
managementService,
return rebalanceResult;
}
+ @NotNull
+ private Function getRebalanceFunction(InternalDistributedMember dsMember) {
+Function rebalanceFunction;
+System.out.println("NABA " + dsMember.getVersion().toString());
Review comment:
Remove this?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Rebalance GFSH commands and restore redundancy commands were not backward
> compatible
>
>
> Key: GEODE-8996
> URL: https://issues.apache.org/jira/browse/GEODE-8996
> Project: Geode
> Issue Type: Bug
> Components: gfsh, rest (admin)
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> Issue:
> * Rebalance command when executed with 1.12.0+ locator and older servers,
> the command failed
> * This was because the Rebalance function moved to a new package
> * Similar problem with REST calls because of moving CacheRealizationFunction
> to a new package
> * There was another problem where Serializable classes with UIDs were
> changed in couple of releases
> * The variation of the UIDs caused deserialization issues when REST commands
> were executed from new locators and old servers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8997) remove protobuf client server code
[ https://issues.apache.org/jira/browse/GEODE-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294685#comment-17294685 ] Bruce J Schuchardt commented on GEODE-8997: --- also these subprojects: geode-protobuf geode-protobuf-messages geode-experimental-driver > remove protobuf client server code > -- > > Key: GEODE-8997 > URL: https://issues.apache.org/jira/browse/GEODE-8997 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Darrel Schneider >Priority: Major > > The protobuf based client/server project is essentially dead but code for it > is still part of geode. > This complicates the implementation. For example I was working on an > improvement to have the thread monitor detect stuck server connection threads > and found myself trying to figure out how to make this work for > ProtobufServerConnection. > I think it would be best to remove the dead protobuf code. I'm not sure what > all of it is but here is what I have found so far: > ProtobufServerConnection > package org.apache.geode.internal.cache.client.protocol > package org.apache.geode.internal.protocol.protobuf.v1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8997) remove protobuf client server code
Darrel Schneider created GEODE-8997: --- Summary: remove protobuf client server code Key: GEODE-8997 URL: https://issues.apache.org/jira/browse/GEODE-8997 Project: Geode Issue Type: Improvement Components: client/server Reporter: Darrel Schneider The protobuf based client/server project is essentially dead but code for it is still part of geode. This complicates the implementation. For example I was working on an improvement to have the thread monitor detect stuck server connection threads and found myself trying to figure out how to make this work for ProtobufServerConnection. I think it would be best to remove the dead protobuf code. I'm not sure what all of it is but here is what I have found so far: ProtobufServerConnection package org.apache.geode.internal.cache.client.protocol package org.apache.geode.internal.protocol.protobuf.v1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8671) Two threads calling get and retrieve the same PdxInstance, resulting in corruption
[ https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294672#comment-17294672 ] ASF subversion and git services commented on GEODE-8671: Commit dabb610b74bb0b27603d7803ec3cdd1cbb16c43f in geode's branch refs/heads/develop from Jianxia Chen [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dabb610 ] GEODE-8671: Two threads calling get and retrieve the same PdxInstance, resulting in corruption (#5925) For PdxInstance, return a new reference in LocalRegion.optimizedGetObject(), instead of using the value in the Future. This is to avoid Pdx corruption when multiple threads share the same reference of PdxInstance. > Two threads calling get and retrieve the same PdxInstance, resulting in > corruption > -- > > Key: GEODE-8671 > URL: https://issues.apache.org/jira/browse/GEODE-8671 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Dan Smith >Assignee: Jianxia Chen >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > Even if copy-on-read is set to true, two threads calling get on a partitioned > region can end up with the same PdxInstance object. > This is problematic because some PdxInstances methods are not thread safe. > Although the underlying bytes are immutatable, the PDXInstance has a > ByteSource with a position field that changes. That means two threads doing > serialization or calling toString on the PdxInstance could result in one or > more threads getting a corrupt read. > It looks like they are ending up with the same instance because of the > behavior in LocalRegion.optimizedGetObject. We use futures to make sure there > is only 1 get that goes through, and both threads receive the same value. > > Ending up in optimizedGetObject requires a race with the put, because if the > value was in the cache at the beginning of the get it would be returned > earlier in the get process. > I put a test that reproduces this issue here - > https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8671) Two threads calling get and retrieve the same PdxInstance, resulting in corruption
[ https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294671#comment-17294671 ] ASF GitHub Bot commented on GEODE-8671: --- jchen21 merged pull request #5925: URL: https://github.com/apache/geode/pull/5925 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Two threads calling get and retrieve the same PdxInstance, resulting in > corruption > -- > > Key: GEODE-8671 > URL: https://issues.apache.org/jira/browse/GEODE-8671 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Dan Smith >Assignee: Jianxia Chen >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > Even if copy-on-read is set to true, two threads calling get on a partitioned > region can end up with the same PdxInstance object. > This is problematic because some PdxInstances methods are not thread safe. > Although the underlying bytes are immutatable, the PDXInstance has a > ByteSource with a position field that changes. That means two threads doing > serialization or calling toString on the PdxInstance could result in one or > more threads getting a corrupt read. > It looks like they are ending up with the same instance because of the > behavior in LocalRegion.optimizedGetObject. We use futures to make sure there > is only 1 get that goes through, and both threads receive the same value. > > Ending up in optimizedGetObject requires a race with the put, because if the > value was in the cache at the beginning of the get it would be returned > earlier in the get process. > I put a test that reproduces this issue here - > https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8992) When a GatewaySenderEventImpl is serialized, its operationDetail field is not included
[
https://issues.apache.org/jira/browse/GEODE-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby reassigned GEODE-8992:
--
Assignee: Barrett Oglesby
> When a GatewaySenderEventImpl is serialized, its operationDetail field is not
> included
> --
>
> Key: GEODE-8992
> URL: https://issues.apache.org/jira/browse/GEODE-8992
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: blocks-1.15.0
>
> This causes the operation to become less specific when the
> {{GatewaySenderEventImpl}} is deserialized.
> Here is an example.
> If the original {{GatewaySenderEventImpl}} is a *PUTALL_CREATE* like:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=PUTALL_CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Then, when the {{GatewaySenderEventImpl}} is serialized and deserialized, its
> operation becomes a *CREATE*:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Thats because {{GatewaySenderEventImpl.getOperation}} uses both *action* and
> *operationDetail* to determine its operation:
> {noformat}
> public Operation getOperation() {
> Operation op = null;
> switch (this.action) {
> case CREATE_ACTION:
> switch (this.operationDetail) {
> case ...
> case OP_DETAIL_PUTALL:
> op = Operation.PUTALL_CREATE;
> break;
> default:
> op = Operation.CREATE;
> break;
> }
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8979) CI Failure: SSLSocketHostNameVerificationIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294644#comment-17294644
]
ASF GitHub Bot commented on GEODE-8979:
---
bschuchardt commented on a change in pull request #6079:
URL: https://github.com/apache/geode/pull/6079#discussion_r586573032
##
File path:
geode-core/src/integrationTest/java/org/apache/geode/internal/net/SSLSocketHostNameVerificationIntegrationTest.java
##
@@ -211,18 +211,17 @@ private Thread startServerNIO(final ServerSocket
serverSocket, int timeoutMillis
} catch (Throwable throwable) {
serverException = throwable;
} finally {
-if (engine != null && socket != null) {
+if (engine != null) {
Review comment:
Intellij informed me that if (engine != null) it isn't possible that
(socket == null). I agreed & removed that check.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI Failure: SSLSocketHostNameVerificationIntegrationTest
>
>
> Key: GEODE-8979
> URL: https://issues.apache.org/jira/browse/GEODE-8979
> Project: Geode
> Issue Type: Test
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> This test failed in a CI IntegrationTest run with this exception:
> {noformat}
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest >
> nioHandshakeValidatesHostName[hasSAN=true and doEndPointIdentification=true]
> FAILED
> org.apache.geode.GemFireIOException: exception closing SSL session
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:409)
> at
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest.lambda$startServerNIO$3(SSLSocketHostNameVerificationIntegrationTest.java:216)
> Caused by:
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470)
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:403)
> ... 1 more
> {noformat}
> It looks like the test needs to have a try/catch for IOException when closing
> the NioSslEngine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294625#comment-17294625
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586545474
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/data/RedisHash.java
##
@@ -203,47 +280,118 @@ public int hstrlen(ByteArrayWrapper field) {
return new ArrayList<>(hash.keySet());
}
- public Pair> hscan(Pattern matchPattern, int count,
BigInteger cursor) {
-List returnList = new ArrayList();
-int size = hash.size();
-BigInteger beforeCursor = new BigInteger("0");
-int numElements = 0;
-int i = -1;
-for (Map.Entry entry :
hash.entrySet()) {
- ByteArrayWrapper key = entry.getKey();
- ByteArrayWrapper value = entry.getValue();
- i++;
- if (beforeCursor.compareTo(cursor) < 0) {
-beforeCursor = beforeCursor.add(new BigInteger("1"));
+ public ImmutablePair> hscan(UUID clientID, Pattern
matchPattern,
+ int count,
+ int cursorParameter) {
+
+int startCursor = cursorParameter;
Review comment:
yeah, Now that's it's an int everywhere this isn't being used. removed.
Thx
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294623#comment-17294623
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586539617
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/CommandFunction.java
##
@@ -257,11 +258,13 @@ protected Object compute(ByteArrayWrapper key, Object[]
args) {
case HSCAN: {
Pattern pattern = (Pattern) args[1];
int count = (int) args[2];
-BigInteger cursor = (BigInteger) args[3];
-return hashCommands.hscan(key, pattern, count, cursor);
+int cursor = Integer.valueOf(args[3].toString());
Review comment:
changed to int cursor = Integer.parseInt((args[3].toString())); not
sure if that's what you mean?
(I can't just cast it because it's a string).
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8872) Add client option, to request locators internal host addresses
[ https://issues.apache.org/jira/browse/GEODE-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294621#comment-17294621 ] ASF GitHub Bot commented on GEODE-8872: --- mivanac commented on pull request #5948: URL: https://github.com/apache/geode/pull/5948#issuecomment-789818612 Updated code. Working on additional test. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add client option, to request locators internal host addresses > --- > > Key: GEODE-8872 > URL: https://issues.apache.org/jira/browse/GEODE-8872 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > Additional option for clients, when pool is created, to request locators > internal host addresses. > When sending LocatorListRequest in some cases we need to get internal host > addresses. > To describe use case: > When deploying geode, for locator we define hostname-for-clients. This is > external address used for WAN, and external clients. > If we also deploy some clients in internal network (for example in the same > kubernetes cluster as geode), then for those clients to connect with locator, > communication will go from internal network to external, then from external > to internal. This increases latency, and we should communicate over the > shortest path. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294613#comment-17294613
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586533187
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/hash/HScanExecutor.java
##
@@ -44,26 +45,29 @@
@Override
public RedisResponse executeCommand(Command command,
ExecutionHandlerContext context) {
+
+final UUID CLIENT_ID = context.getClientUUID();
+
List commandElems = command.getProcessedCommand();
String cursorString = Coder.bytesToString(commandElems.get(2));
-BigInteger cursor;
+int cursor;
Pattern matchPattern;
String globPattern = null;
int count = DEFAULT_COUNT;
try {
- cursor = new BigInteger(cursorString).abs();
+ cursor = Integer.valueOf(cursorString);
} catch (NumberFormatException e) {
return RedisResponse.error(ERROR_CURSOR);
}
-if (cursor.compareTo(UNSIGNED_LONG_CAPACITY) > 0) {
+if (cursor > Integer.MAX_VALUE) {
return RedisResponse.error(ERROR_CURSOR);
}
Review comment:
makes sense. thx
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294612#comment-17294612
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586532417
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/hash/HScanExecutor.java
##
@@ -44,26 +45,29 @@
@Override
public RedisResponse executeCommand(Command command,
ExecutionHandlerContext context) {
+
+final UUID CLIENT_ID = context.getClientUUID();
+
List commandElems = command.getProcessedCommand();
String cursorString = Coder.bytesToString(commandElems.get(2));
-BigInteger cursor;
+int cursor;
Pattern matchPattern;
String globPattern = null;
int count = DEFAULT_COUNT;
try {
- cursor = new BigInteger(cursorString).abs();
+ cursor = Integer.valueOf(cursorString);
Review comment:
changed
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294604#comment-17294604
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586526667
##
File path:
geode-redis/src/test/java/org/apache/geode/redis/internal/data/RedisHashTest.java
##
@@ -161,4 +163,109 @@ public void
setExpirationTimestamp_stores_delta_that_is_stable() throws IOExcept
o2.fromDelta(in);
assertThat(o2).isEqualTo(o1);
}
+
+ @Test
+ public void hscanSnaphots_shouldBeEmpty_givenHscanHasNotBeenCalled() {
+RedisHash subject = createRedisHash(100);
+assertThat(subject.getHscanSnapShots()).isEmpty();
+ }
+
+ @Test
+ public void hscanSnaphots_shouldContainSnapshot_givenHscanHasBeenCalled() {
+
+final List FIELDS_AND_VALUES_FOR_HASH =
createListOfDataElements(100);
+RedisHash subject = new RedisHash(FIELDS_AND_VALUES_FOR_HASH);
+UUID clientID = UUID.randomUUID();
+
+subject.hscan(clientID, null, 10, BigInteger.valueOf(0));
+
+ConcurrentHashMap> hscanSnapShotMap =
subject.getHscanSnapShots();
+
+assertThat(hscanSnapShotMap.containsKey(clientID)).isTrue();
+
+List keyList = hscanSnapShotMap.get(clientID);
+assertThat(keyList).isNotEmpty();
+
+FIELDS_AND_VALUES_FOR_HASH.forEach((entry) -> {
+ if (entry.toString().contains("field")) {
+assertThat(keyList.contains(entry)).isTrue();
+ } else if (entry.toString().contains("value")) {
+assertThat(keyList.contains(entry)).isFalse();
Review comment:
changed
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294599#comment-17294599
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586520831
##
File path:
geode-redis/src/distributedTest/java/org/apache/geode/redis/internal/executor/hash/HScanDunitTest.java
##
@@ -0,0 +1,241 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.redis.internal.executor.hash;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.MAX_WAIT_TIME_RECONNECT;
+import static org.apache.geode.test.dunit.IgnoredException.addIgnoredException;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.concurrent.ExecutionException;
+import java.util.concurrent.Future;
+import java.util.concurrent.atomic.AtomicBoolean;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import io.lettuce.core.ClientOptions;
+import io.lettuce.core.MapScanCursor;
+import io.lettuce.core.RedisClient;
+import io.lettuce.core.RedisCommandExecutionException;
+import io.lettuce.core.RedisException;
+import io.lettuce.core.ScanCursor;
+import io.lettuce.core.api.StatefulRedisConnection;
+import io.lettuce.core.api.sync.RedisCommands;
+import io.lettuce.core.resource.ClientResources;
+import org.junit.AfterClass;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.control.RebalanceFactory;
+import org.apache.geode.cache.control.ResourceManager;
+import org.apache.geode.cache.execute.FunctionException;
+import org.apache.geode.internal.AvailablePortHelper;
+import
org.apache.geode.redis.session.springRedisTestApplication.config.DUnitSocketAddressResolver;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.dunit.rules.RedisClusterStartupRule;
+import org.apache.geode.test.junit.rules.ExecutorServiceRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+
+public class HScanDunitTest {
+
+ @ClassRule
+ public static RedisClusterStartupRule redisClusterStartupRule = new
RedisClusterStartupRule(4);
+
+ @Rule
+ public ExecutorServiceRule executor = new ExecutorServiceRule();
+
+ @ClassRule
+ public static GfshCommandRule gfsh = new GfshCommandRule();
+
+ private static RedisCommands commands;
+ private RedisClient redisClient;
+ private StatefulRedisConnection connection;
+ private static Properties locatorProperties;
+
+ private static MemberVM locator;
+ private static MemberVM server1;
+ private static MemberVM server2;
+ private static MemberVM server3;
+
+ static final String HASH_KEY = "key";
+ static final String BASE_FIELD = "baseField_";
+ static final Map INITIAL_DATA_SET = makeEntrySet(1000);
+
+ static int[] redisPorts;
+
+ @BeforeClass
+ public static void classSetup() throws Exception {
+int locatorPort;
+locatorProperties = new Properties();
+locatorProperties.setProperty(MAX_WAIT_TIME_RECONNECT, "15000");
+
+locator = redisClusterStartupRule.startLocatorVM(0, locatorProperties);
+locatorPort = locator.getPort();
+redisPorts = AvailablePortHelper.getRandomAvailableTCPPorts(3);
+
+// note: due to rules around member weighting in split-brain scenarios,
+// vm1 (server1) should not be crashed or it will cause additional
(unrelated) failures
+String redisPort1 = redisPorts[0] + "";
+server1 = redisClusterStartupRule.startRedisVM(1, redisPort1, locatorPort);
+
+String redisPort2 = redisPorts[1] + "";
+server2 = redisClusterStartupRule.startServerVM(2, redisPort2,
locatorPort);
+
+String redisPort3 = redisPorts[2] + "";
+server3 = redisClusterStartupRule.startServerVM(3, redisPort3,
locatorPort);
+
+gfsh.connectAndVerify(locator);
+ }
+
+ @Before
+ public void
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294595#comment-17294595
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586512060
##
File path:
geode-redis/src/distributedTest/java/org/apache/geode/redis/internal/executor/hash/HScanDunitTest.java
##
@@ -0,0 +1,241 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.redis.internal.executor.hash;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.MAX_WAIT_TIME_RECONNECT;
+import static org.apache.geode.test.dunit.IgnoredException.addIgnoredException;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.concurrent.ExecutionException;
+import java.util.concurrent.Future;
+import java.util.concurrent.atomic.AtomicBoolean;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import io.lettuce.core.ClientOptions;
+import io.lettuce.core.MapScanCursor;
+import io.lettuce.core.RedisClient;
+import io.lettuce.core.RedisCommandExecutionException;
+import io.lettuce.core.RedisException;
+import io.lettuce.core.ScanCursor;
+import io.lettuce.core.api.StatefulRedisConnection;
+import io.lettuce.core.api.sync.RedisCommands;
+import io.lettuce.core.resource.ClientResources;
+import org.junit.AfterClass;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.control.RebalanceFactory;
+import org.apache.geode.cache.control.ResourceManager;
+import org.apache.geode.cache.execute.FunctionException;
+import org.apache.geode.internal.AvailablePortHelper;
+import
org.apache.geode.redis.session.springRedisTestApplication.config.DUnitSocketAddressResolver;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.dunit.rules.RedisClusterStartupRule;
+import org.apache.geode.test.junit.rules.ExecutorServiceRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+
+public class HScanDunitTest {
+
+ @ClassRule
+ public static RedisClusterStartupRule redisClusterStartupRule = new
RedisClusterStartupRule(4);
+
+ @Rule
+ public ExecutorServiceRule executor = new ExecutorServiceRule();
+
+ @ClassRule
+ public static GfshCommandRule gfsh = new GfshCommandRule();
Review comment:
yeah, my bad- I didn't notice the rule was still around. will remove.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8872) Add client option, to request locators internal host addresses
[
https://issues.apache.org/jira/browse/GEODE-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294507#comment-17294507
]
ASF GitHub Bot commented on GEODE-8872:
---
mivanac commented on a change in pull request #5948:
URL: https://github.com/apache/geode/pull/5948#discussion_r586386215
##
File path: geode-core/src/main/java/org/apache/geode/cache/client/Pool.java
##
@@ -207,6 +207,13 @@ default boolean getThreadLocalConnections() {
*/
boolean getMultiuserAuthentication();
+ /**
+ * Returns true ir request locator internal address is enabled on this pool.
+ *
+ * @see PoolFactory#setRequestLocatorInternalAddress(boolean)
+ * @since Geode 1.14
+ */
+ boolean getRequestLocatorInternalAddress();
Review comment:
Thanks for comment. I will update.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add client option, to request locators internal host addresses
> ---
>
> Key: GEODE-8872
> URL: https://issues.apache.org/jira/browse/GEODE-8872
> Project: Geode
> Issue Type: New Feature
> Components: client/server
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: pull-request-available
>
> Additional option for clients, when pool is created, to request locators
> internal host addresses.
> When sending LocatorListRequest in some cases we need to get internal host
> addresses.
> To describe use case:
> When deploying geode, for locator we define hostname-for-clients. This is
> external address used for WAN, and external clients.
> If we also deploy some clients in internal network (for example in the same
> kubernetes cluster as geode), then for those clients to connect with locator,
> communication will go from internal network to external, then from external
> to internal. This increases latency, and we should communicate over the
> shortest path.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender
[ https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294394#comment-17294394 ] ASF GitHub Bot commented on GEODE-8971: --- albertogpz commented on pull request #6052: URL: https://github.com/apache/geode/pull/6052#issuecomment-789556681 > Unless we have a real need to expose `TransactionId getTransactionId()` and `boolean isLastEventInTransaction()` to the User (it's in a non-internal package), then I would **_not_** add them to the `GatewayQueueEvent`. > > I would create a new `InternalGatewayQueueEvent` interface that extends `GatewayQueueEvent` and add the two tx related methods to that internal interface instead. Then you could define the predicate as `Predicate`. > > Adding `InternalGatewayQueueEvent` would probably require some follow-up PRs that update the WAN code to use it internally. This would them be part of longer term refactoring to improve the codebase with interfaces and is similar to the many other internal interfaces that we've been adding including `InternalRegion` and `InternalCache`. Note that we tend to not parameterize these internal interfaces. Thanks for the comments. I have done as suggested. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Batches with incomplete transactions when stopping the gateway sender > - > > Key: GEODE-8971 > URL: https://issues.apache.org/jira/browse/GEODE-8971 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When the gateway sender is stopped there is a high probability that batches > with incomplete transactions are sent even if group-transaction-events is > enabled. > The reason is that once the stop command reaches the gateway sender, it > immediately stops queueing events, and this could happen in the middle of > receiving events for the same transaction. If this is the case, some events > for the transaction may have reached the queue right before the stop command > was received and the rest of events for that transaction would not make it to > the queue (they would be dropped) because they arrived right after the stop > command was received at the gateway sender. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7455) CI Failure: AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean Failed
[
https://issues.apache.org/jira/browse/GEODE-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294357#comment-17294357
]
Jakov Varenina edited comment on GEODE-7455 at 3/3/21, 8:48 AM:
Reproduced in [https://concourse.apachegeode-ci.info/builds/9113]
{code:java}
org.apache.geode.management.AEQManagementDUnitTest >
testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.management.AEQManagementDUnitTest$$Lambda$218/0x000100321040.run
in VM 0 running on Host a758e6d7ed63 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
at
org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean(AEQManagementDUnitTest.java:198)
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
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.management.AEQManagementDUnitTest.lambda$testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean$d4d42c35$1(AEQManagementDUnitTest.java:203)
{code}
It is not the same test as initially reported, but in both tests the same code
is used, and it fails on the same check.
was (Author: jvarenina):
Reproduced in [https://concourse.apachegeode-ci.info/builds/9113]
{code:java}
org.apache.geode.management.AEQManagementDUnitTest >
testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.management.AEQManagementDUnitTest$$Lambda$218/0x000100321040.run
in VM 0 running on Host a758e6d7ed63 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
at
org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean(AEQManagementDUnitTest.java:198)
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
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.management.AEQManagementDUnitTest.lambda$testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean$d4d42c35$1(AEQManagementDUnitTest.java:203)
{code}
> CI Failure:
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> Failed
> --
>
> Key: GEODE-7455
> URL: https://issues.apache.org/jira/browse/GEODE-7455
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: flaky
>
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> failed in DistributedTestOpenJDK11 below are the relevant details.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1280]
>
> {noformat}
> 13:30:08
> org.apache.geode.management.AEQManagementDUnitTest >
> testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean FAILED
> 13:30:08
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.AEQManagementDUnitTest$$Lambda$200/0x0008407dec40.run
> in VM 0 running on Host 0e592392f6db with 4 VMs
> 13:30:08
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> 13:30:08
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> 13:30:08
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean(AEQManagementDUnitTest.java:245)
> 13:30:0813:30:08
> Caused by:
> 13:30:08
> org.junit.ComparisonFailure: e
[jira] [Commented] (GEODE-7455) CI Failure: AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean Failed
[
https://issues.apache.org/jira/browse/GEODE-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294357#comment-17294357
]
Jakov Varenina commented on GEODE-7455:
---
Reproduced in [https://concourse.apachegeode-ci.info/builds/9113]
{code:java}
org.apache.geode.management.AEQManagementDUnitTest >
testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.management.AEQManagementDUnitTest$$Lambda$218/0x000100321040.run
in VM 0 running on Host a758e6d7ed63 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
at
org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean(AEQManagementDUnitTest.java:198)
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
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.management.AEQManagementDUnitTest.lambda$testCreateAEQWithDispatcherInPausedStateAndVerifyUsingMBean$d4d42c35$1(AEQManagementDUnitTest.java:203)
{code}
> CI Failure:
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> Failed
> --
>
> Key: GEODE-7455
> URL: https://issues.apache.org/jira/browse/GEODE-7455
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: flaky
>
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
> failed in DistributedTestOpenJDK11 below are the relevant details.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1280]
>
> {noformat}
> 13:30:08
> org.apache.geode.management.AEQManagementDUnitTest >
> testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean FAILED
> 13:30:08
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.AEQManagementDUnitTest$$Lambda$200/0x0008407dec40.run
> in VM 0 running on Host 0e592392f6db with 4 VMs
> 13:30:08
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> 13:30:08
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> 13:30:08
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean(AEQManagementDUnitTest.java:245)
> 13:30:0813:30:08
> Caused by:
> 13:30:08
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 13:30:08
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 13:30:08
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 13:30:08
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 13:30:08
> at
> org.apache.geode.management.AEQManagementDUnitTest.lambda$testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean$d4d42c35$1(AEQManagementDUnitTest.java:250)
> 14:10:3714:10:37
> 793 tests completed, 1 failed, 61 skipped {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-results/distributedTest/1573687903/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-artifacts/1573687903/distributedtestfiles-OpenJDK11-1.12.0-SNAPSHOT.0013.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
