[jira] [Commented] (GEODE-8925) Migrate old integration test testThinClientPRSingleHop to new test framework
[ https://issues.apache.org/jira/browse/GEODE-8925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309164#comment-17309164 ] ASF GitHub Bot commented on GEODE-8925: --- mmartell commented on pull request #760: URL: https://github.com/apache/geode-native/pull/760#issuecomment-807933678 The two ported tests (testThinClientPRSingleHop and testThinClientPutAllPRSingleHop) have been 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 > Migrate old integration test testThinClientPRSingleHop to new test framework > > > Key: GEODE-8925 > URL: https://issues.apache.org/jira/browse/GEODE-8925 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The following singleHop tests are marked Flaky. This ticket is to port these > to the new framework. > * testThinClientPRSingleHop > * testThinClientPutAllPRSingleHop -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-8950. Fix Version/s: 1.15.0 1.14.0 Resolution: Workaround > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.14.0, blocks-1.15.0 > Fix For: 1.14.0, 1.15.0 > > Attachments: GEODE-8950-before-after-histogram-chart.png, > GEODE-8950-performance degradation vs 1.13.png > > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309143#comment-17309143 ] Donal Evans commented on GEODE-8950: The P2pPartitionedPutLongBenchmark was disabled on develop and support/1.14. As a consequence this ticket is being closed, although if possible it would be good to increase the stability of the benchmark and reintroduce it. > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.14.0, blocks-1.15.0 > Attachments: GEODE-8950-before-after-histogram-chart.png, > GEODE-8950-performance degradation vs 1.13.png > > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309142#comment-17309142 ] ASF subversion and git services commented on GEODE-8950: Commit 7f70ac9899c8e04683543428fd89ea60463108e3 in geode-benchmarks's branch refs/heads/support/1.14 from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=7f70ac9 ] Disable P2pPartitionedPutLongBenchmark (#146) - This benchmark is unstable and does not produce reliable results. See GEODE-8950 for further details. Authored-by: Donal Evans > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.14.0, blocks-1.15.0 > Attachments: GEODE-8950-before-after-histogram-chart.png, > GEODE-8950-performance degradation vs 1.13.png > > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9042) Geode User Guide: update dockerfile to use newer ruby & gems
[ https://issues.apache.org/jira/browse/GEODE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309051#comment-17309051 ] Alberto Bustamante Reyes commented on GEODE-9042: - The problem with mimemagic library is affecting more than 500.000 repositories: https://www.theregister.com/2021/03/25/ruby_rails_code/ It seems Bookbinder should use version 0.3.6 to avoid license issues. > Geode User Guide: update dockerfile to use newer ruby & gems > > > Key: GEODE-9042 > URL: https://issues.apache.org/jira/browse/GEODE-9042 > Project: Geode > Issue Type: Improvement > Components: docs, tools >Affects Versions: 1.13.1 >Reporter: Dave Barnes >Priority: Major > > The scripts that build the user guide are pinned at Ruby 2.3.0 and Bookbinder > 1.10.14. > These need to be updated to Ruby 2.5.3 (or later) and Bookbinder 1.10.15 in > order to support current deployment infrastructure. > Path to the Bookbinder gem: > http://docs-wiki.cfapps.io/wiki/bookbinder/installing-bookbinder.html#v10 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9042) Geode User Guide: update dockerfile to use newer ruby & gems
[
https://issues.apache.org/jira/browse/GEODE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309035#comment-17309035
]
Alberto Bustamante Reyes commented on GEODE-9042:
-
Hi [~dbarnes]. Updating Bookbinder to 1.10.5 is not enough, as that version is
affected by a recent issue with mimemagic ruby gem. The authors removed old
versions, and Bookbinder uses mimemagic 0.3.2, which is not available anymore.
The change affected a lot of software projects, and it seems it is solved by
using an updated version, with that has to be fixed by Bookbinder team.
The manual process to generate the documentation [described
here|https://github.com/apache/geode/tree/develop/geode-book#building-the-documentation]
is impacted. And also the automatic process based on Docker images.
I tried first using what is in develop branch, which is Bookbinder 1.10.14, and
after I changed the geode-book/Gemfile to use 1.10.15, but in both cases the
result is the same: after moving to "final_app" folder and running "bundle
install", this error is shown:
{code:java}
$ bundle install
Fetching gem metadata from http://rubygems.org/
Resolving dependencies...
Your bundle is locked to mimemagic (0.3.2), but that version could not be found
in any of the sources listed in your Gemfile. If you haven't changed sources,
that means the author of mimemagic (0.3.2) has
removed it. You'll need to update your bundle to a version other than mimemagic
(0.3.2) that hasn't been removed in order to install.
{code}
Bookbinder team should create a newer version updating the dependencies, to
avoid the usage of mimemagic 0.3.2
> Geode User Guide: update dockerfile to use newer ruby & gems
>
>
> Key: GEODE-9042
> URL: https://issues.apache.org/jira/browse/GEODE-9042
> Project: Geode
> Issue Type: Improvement
> Components: docs, tools
>Affects Versions: 1.13.1
>Reporter: Dave Barnes
>Priority: Major
>
> The scripts that build the user guide are pinned at Ruby 2.3.0 and Bookbinder
> 1.10.14.
> These need to be updated to Ruby 2.5.3 (or later) and Bookbinder 1.10.15 in
> order to support current deployment infrastructure.
> Path to the Bookbinder gem:
> http://docs-wiki.cfapps.io/wiki/bookbinder/installing-bookbinder.html#v10
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9077) GFSH commands invoke functions using execute(Function) rather than execute(ID)
Udo Kohlmeyer created GEODE-9077: Summary: GFSH commands invoke functions using execute(Function) rather than execute(ID) Key: GEODE-9077 URL: https://issues.apache.org/jira/browse/GEODE-9077 Project: Geode Issue Type: Improvement Components: gfsh Reporter: Udo Kohlmeyer GFSH currently executes functions using the method, `execute(Function)` rather than a more acceptable `execute(ID)`. In both cases the function is required to be on the server-side, BUT the main difference is that for the first case the function does not need to be registered. Which makes no sense, as the function as to be present on the server side. This approach makes it difficult to move functions (package) or replace them with better versions at runtime, as the function versions have to match up for it to be able to deserialize correctly. In the approach of `execute(ID)` the problem exists that the functions need to be registered which means that possibly they might become "public" when listing them with `list functions`. But the benefits are larger, as they are registered by name and thus invocation from the client side is against the ID and not the Function itself. In addition, this approach allows for the updating of the function, without having to update the client, as the implementation does not have to live in GFSH. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9076) GeodeClusterManagementServiceBuilder is based on internal API from another module.
Udo Kohlmeyer created GEODE-9076: Summary: GeodeClusterManagementServiceBuilder is based on internal API from another module. Key: GEODE-9076 URL: https://issues.apache.org/jira/browse/GEODE-9076 Project: Geode Issue Type: Bug Components: configuration Reporter: Udo Kohlmeyer GeodeClusterManagementServiceBuilder is extending BaseManagementServiceBuilder, which is in the internal namespace. Which means that we now expose internal API's into the public API space. This is not only technically incorrect, but also ethically and morally. Can we please address this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8972) remove shunnedMembers collection from GMSMembership
[ https://issues.apache.org/jira/browse/GEODE-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami updated GEODE-8972: -- Fix Version/s: 1.14.0 > remove shunnedMembers collection from GMSMembership > --- > > Key: GEODE-8972 > URL: https://issues.apache.org/jira/browse/GEODE-8972 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0, 1.15.0 > > > GMSMembership has a _shunnedMembers_ collection that is used to track the IDs > of nodes that are no longer part of the cluster. This collection is no > longer needed since we can tell if a node is old by comparing the view ID in > its identifier to that of the current view (called _latestView_ in that > class. Checks like this are already in place in some parts of the code. > All uses of _shunnedMembers_ should be replaced with this check. > MembershipView view = latestView; > boolean shunned = memberId.getVmViewId() <= view.getViewId() && > !view.contains(memberId); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7245) Remove most uses of latestViewReadLock in GMSMembershipManager
[ https://issues.apache.org/jira/browse/GEODE-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami updated GEODE-7245: -- Fix Version/s: 1.14.0 > Remove most uses of latestViewReadLock in GMSMembershipManager > -- > > Key: GEODE-7245 > URL: https://issues.apache.org/jira/browse/GEODE-7245 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Changes for GEODE-7196 made the latestView immutable so there is no reason, > in most cases, to use the latestViewReadlock when accessing the view. A > simple volatile read of the field & storing the value in a method variable > can replace most uses of the latestViewReadLock, especially those uses that > are in the path of sending or receiving messages. > Performance could be measured with our benchmarks to see if this change helps. > > latestViewReadLock is currently used in getCoordinator(), memberExists(), > getMembersNotShuttingDown(), getAllMembers(), isShunnedOrNew(), > isSurpriseMember(), doWithViewLocked(). > doWithViewLocked() is used to add membership listeners, and we don't want the > view to change until this operation completes. Therefore, we should keep the > lock in this method. > getCoordinator(), memberExists(), getMembersNotShuttingDown(), > getAllMembers() use latestViewReadLock to access latestView. In these methods > we can replace the lock with a volatile read of the latestView and storing > the value in a method variable. > isShunnedOrNew() accesses latestView, and 2 ConcurrentHashMaps - > shunnedMembers and surpriseMembers. Since the hashmaps are concurrent and > latestView is unmodifiable, a volatile read could replace the lock. Same for > isSurpriseMember(), which uses surpriseMembers hashmap. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8972) remove shunnedMembers collection from GMSMembership
[ https://issues.apache.org/jira/browse/GEODE-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308989#comment-17308989 ] ASF subversion and git services commented on GEODE-8972: Commit f274c73c105c51fe798ac0f50ef058ec1a939867 in geode's branch refs/heads/support/1.14 from Kamilla Aslami [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f274c73 ] GEODE-8972: remove shunnedMembers collection from GMSMembership (#6089) * GEODE-8972: remove shunnedMembers collection from GMSMembership * Changes after the code review (cherry picked from commit c2fc107bad1de221157072470e2a6ad426533f20) > remove shunnedMembers collection from GMSMembership > --- > > Key: GEODE-8972 > URL: https://issues.apache.org/jira/browse/GEODE-8972 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > GMSMembership has a _shunnedMembers_ collection that is used to track the IDs > of nodes that are no longer part of the cluster. This collection is no > longer needed since we can tell if a node is old by comparing the view ID in > its identifier to that of the current view (called _latestView_ in that > class. Checks like this are already in place in some parts of the code. > All uses of _shunnedMembers_ should be replaced with this check. > MembershipView view = latestView; > boolean shunned = memberId.getVmViewId() <= view.getViewId() && > !view.contains(memberId); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8972) remove shunnedMembers collection from GMSMembership
[ https://issues.apache.org/jira/browse/GEODE-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308988#comment-17308988 ] ASF subversion and git services commented on GEODE-8972: Commit f274c73c105c51fe798ac0f50ef058ec1a939867 in geode's branch refs/heads/support/1.14 from Kamilla Aslami [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f274c73 ] GEODE-8972: remove shunnedMembers collection from GMSMembership (#6089) * GEODE-8972: remove shunnedMembers collection from GMSMembership * Changes after the code review (cherry picked from commit c2fc107bad1de221157072470e2a6ad426533f20) > remove shunnedMembers collection from GMSMembership > --- > > Key: GEODE-8972 > URL: https://issues.apache.org/jira/browse/GEODE-8972 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > GMSMembership has a _shunnedMembers_ collection that is used to track the IDs > of nodes that are no longer part of the cluster. This collection is no > longer needed since we can tell if a node is old by comparing the view ID in > its identifier to that of the current view (called _latestView_ in that > class. Checks like this are already in place in some parts of the code. > All uses of _shunnedMembers_ should be replaced with this check. > MembershipView view = latestView; > boolean shunned = memberId.getVmViewId() <= view.getViewId() && > !view.contains(memberId); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7245) Remove most uses of latestViewReadLock in GMSMembershipManager
[ https://issues.apache.org/jira/browse/GEODE-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308987#comment-17308987 ] ASF subversion and git services commented on GEODE-7245: Commit ff947f1328f87ec8a8f4a914aea80f3d59eaef59 in geode's branch refs/heads/support/1.14 from Kamilla Aslami [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ff947f1 ] GEODE-7245: Remove most uses of latestViewReadLock in GMSMembership (#6037) * Remove most uses of latestViewReadLock in GMSMembership * make MembershipView immutable * Constructor consolidation and better naming of add/remove * Tighten constructor chaining Co-authored-by: Bill Burcham (cherry picked from commit 477ffba8e155dca0bdeeefd312b6b32b4b481100) > Remove most uses of latestViewReadLock in GMSMembershipManager > -- > > Key: GEODE-7245 > URL: https://issues.apache.org/jira/browse/GEODE-7245 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Changes for GEODE-7196 made the latestView immutable so there is no reason, > in most cases, to use the latestViewReadlock when accessing the view. A > simple volatile read of the field & storing the value in a method variable > can replace most uses of the latestViewReadLock, especially those uses that > are in the path of sending or receiving messages. > Performance could be measured with our benchmarks to see if this change helps. > > latestViewReadLock is currently used in getCoordinator(), memberExists(), > getMembersNotShuttingDown(), getAllMembers(), isShunnedOrNew(), > isSurpriseMember(), doWithViewLocked(). > doWithViewLocked() is used to add membership listeners, and we don't want the > view to change until this operation completes. Therefore, we should keep the > lock in this method. > getCoordinator(), memberExists(), getMembersNotShuttingDown(), > getAllMembers() use latestViewReadLock to access latestView. In these methods > we can replace the lock with a volatile read of the latestView and storing > the value in a method variable. > isShunnedOrNew() accesses latestView, and 2 ConcurrentHashMaps - > shunnedMembers and surpriseMembers. Since the hashmaps are concurrent and > latestView is unmodifiable, a volatile read could replace the lock. Same for > isSurpriseMember(), which uses surpriseMembers hashmap. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9067) register-interest done during rolling upgrade can take longer than needed
[ https://issues.apache.org/jira/browse/GEODE-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9067: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > register-interest done during rolling upgrade can take longer than needed > - > > Key: GEODE-9067 > URL: https://issues.apache.org/jira/browse/GEODE-9067 > Project: Geode > Issue Type: Improvement > Components: client/server >Affects Versions: 1.1.0, 1.10.0, 1.11.0, 1.12.0, 1.12.1, 1.13.0, 1.13.1 >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > If a client does a register-interest to a server that is a newer geode > version than its peer servers (which happens during a rolling upgrade), and > the InterestResultPolicy is KEYS_VALUES (the default), on a partitioned > region, then the way the server fetches values that are on the older peer > servers is slower than it needs to be. Instead of sending that server a > single FetchBulkEntries message, it does an individual get for each key. This > individual get can also go to a primary of secondary and for correctness > register-interest needs to do all its reads from the primary. > The code has been doing this ever since the first release of geode. Once all > the members have been restarted then register-interest does its reads > optimally. Since a register-interest that is in progress prevents its > subscription queue from draining, this slow register-interest could cause > memory issues or performance issues on the cluster. But it really depends on > how big the region is, how big the cluster is, and the rate at which > operations that go into the subscription queue are being done. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket timed out on client"
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308982#comment-17308982
]
Geode Integration commented on GEODE-8616:
--
Seen in [DistributedTestOpenJDK8
#101.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/101.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-results/distributedTest/1616705973/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-artifacts/1616705973/distributedtestfiles-OpenJDK8-1.15.0-build.0082.tgz].
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected
> socket timed out on client"
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1
>Reporter: Donal Evans
>Priority: Major
> Labels: flaky-test
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9058) Remove ACE_OS references
[
https://issues.apache.org/jira/browse/GEODE-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308977#comment-17308977
]
ASF GitHub Bot commented on GEODE-9058:
---
gaussianrecurrence commented on a change in pull request #774:
URL: https://github.com/apache/geode-native/pull/774#discussion_r601845671
##
File path: cppcache/src/DistributedSystemImpl.cpp
##
@@ -81,9 +81,9 @@ void DistributedSystemImpl::logSystemInformation() const {
ACE_utsname u;
ACE_OS::uname();
- LOGCONFIG(
- "Running on: SystemName=%s Machine=%s Host=%s Release=%s Version=%s",
- u.sysname, u.machine, u.nodename, u.release, u.version);
+ LOGCONFIG("Running on: SystemName=" BOOST_PLATFORM
Review comment:
There it is. I've written an implementation for at least all the
supported platforms. I've left out some old Windows versions, like Windows
95/98/Me, but I really doubt someone manages to run geode on those OS.
--
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
> Remove ACE_OS references
>
>
> Key: GEODE-9058
> URL: https://issues.apache.org/jira/browse/GEODE-9058
> Project: Geode
> Issue Type: Task
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: obliterate-ace, pull-request-available
>
> *AS A* geode-native contributor
> *I WOULD LIKE* to remove any references to ACE_OS in the source
> *SO THAT* we can get rid of ACE for good, eventually.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9064) Configure serialization filtering for JMX/RMI by default on Java 11
[ https://issues.apache.org/jira/browse/GEODE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9064: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > Configure serialization filtering for JMX/RMI by default on Java 11 > --- > > Key: GEODE-9064 > URL: https://issues.apache.org/jira/browse/GEODE-9064 > Project: Geode > Issue Type: Improvement > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The Geode JMX layer should configure the > “jmx.remote.rmi.server.serial.filter.pattern” system property on Java 11 to > accept only JDK classes identified as open-types for JMX. If the user or > another library has already set this system property, then Geode will log a > statement and leave it alone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9075) Thread stuck indefinitely when using Istio/Sidecar
[ https://issues.apache.org/jira/browse/GEODE-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-9075: Description: Geode cluster is deployed in kubernetes environment, and Istio/SideCars are injected between cluster members. While running traffic, if any Istio/SideCar is restarted, thread can get stuck, while waiting for reply on sent message. [warn 2021/03/25 21:04:47.282 CET server2 tid=0x12] Thread <64> (0x40) that was executed at <25 Mar 2021 21:03:53 CET> has been stuck for <53.897 seconds> and number of thread monitor iteration <1> Thread Name state Waiting on Executor Group Monitored metric Thread stack: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:736) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:811) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:784) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:874) org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:811) org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:699) org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277) org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318) org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520) ... was: Geode cluster is deployed in kubernetes environment, and Istio is injected between cluster members. While running traffic, if any istion/sidecar is restarted, thread can get stuck, while waiting for reply on sent message. [warn 2021/03/25 21:04:47.282 CET server2 tid=0x12] Thread <64> (0x40) that was executed at <25 Mar 2021 21:03:53 CET> has been stuck for <53.897 seconds> and number of thread monitor iteration <1> Thread Name state Waiting on Executor Group Monitored metric Thread stack: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:736) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:811) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:784) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:874) org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:811) org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:699) org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277) org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318) org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520) ... > Thread stuck indefinitely when using Istio/Sidecar > -- > > Key: GEODE-9075 > URL: https://issues.apache.org/jira/browse/GEODE-9075 > Project: Geode > Issue Type: Bug >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > Geode cluster is deployed in kubernetes environment, and Istio/SideCars are > injected between cluster members. While running traffic, if any Istio/SideCar > is restarted, thread can get stuck, while waiting for reply on sent message. > > [warn 2021/03/25 21:04:47.282 CET server2 tid=0x12] Thread > <64> (0x40) that was executed at <25 Mar 2021 21:03:53 CET> has been stuck > for <53.897 seconds>
[jira] [Commented] (GEODE-9045) Rename Redis properties
[ https://issues.apache.org/jira/browse/GEODE-9045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308966#comment-17308966 ] ASF subversion and git services commented on GEODE-9045: Commit d9ec6fb2b8716a5c4f8bc6afadd8edff796de4a6 in geode's branch refs/heads/develop from Hale Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d9ec6fb ] GEODE-9045: customer facing references to Redis (#6150) Change the customer facing references to Redis to comply with Redis's copyright. Instead of calling ourselves Geode Redis, we are called Geode APIs compatible with Redis. - property redis-port -> compatible-with-redis-port - property redis-bind-address -> compatible-with-redis-bind-address - property redis-password -> compatible-with-redis-password - property redis-enabled -> compatible-with-redis-enabled - use the word Redis when referring to actual Redis - rename html documentation file and change all references to it - fix filename that mixed dashes and underscores > Rename Redis properties > --- > > Key: GEODE-9045 > URL: https://issues.apache.org/jira/browse/GEODE-9045 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > In order to comply with Redis's copyright we should change the following > parameters from -> to > redis-port -> compatible-with-redis-port > redis-bind-address -> compatible-with-redis-bind-address > redis-password -> compatible-with-redis-password -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9075) Thread stuck indefinitely when using Istio/Sidecar
[ https://issues.apache.org/jira/browse/GEODE-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-9075: Description: Geode cluster is deployed in kubernetes environment, and Istio/SideCars are injected between cluster members. While running traffic, if any Istio/SideCar is restarted, thread can get stuck indefinitely, while waiting for reply on sent message. [warn 2021/03/25 21:04:47.282 CET server2 tid=0x12] Thread <64> (0x40) that was executed at <25 Mar 2021 21:03:53 CET> has been stuck for <53.897 seconds> and number of thread monitor iteration <1> Thread Name state Waiting on Executor Group Monitored metric Thread stack: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:736) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:811) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:784) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:874) org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:811) org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:699) org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277) org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318) org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520) ... was: Geode cluster is deployed in kubernetes environment, and Istio/SideCars are injected between cluster members. While running traffic, if any Istio/SideCar is restarted, thread can get stuck, while waiting for reply on sent message. [warn 2021/03/25 21:04:47.282 CET server2 tid=0x12] Thread <64> (0x40) that was executed at <25 Mar 2021 21:03:53 CET> has been stuck for <53.897 seconds> and number of thread monitor iteration <1> Thread Name state Waiting on Executor Group Monitored metric Thread stack: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:736) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:811) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:784) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:874) org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:811) org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:699) org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277) org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318) org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520) ... > Thread stuck indefinitely when using Istio/Sidecar > -- > > Key: GEODE-9075 > URL: https://issues.apache.org/jira/browse/GEODE-9075 > Project: Geode > Issue Type: Bug >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > Geode cluster is deployed in kubernetes environment, and Istio/SideCars are > injected between cluster members. While running traffic, if any Istio/SideCar > is restarted, thread can get stuck indefinitely, while waiting for reply on > sent message. > > [warn 2021/03/25 21:04:47.282 CET server2 tid=0x12] Thread > <64> (0x40) that was
[jira] [Created] (GEODE-9075) Thread stuck indefinitely when using Istio/Sidecar
Mario Ivanac created GEODE-9075: --- Summary: Thread stuck indefinitely when using Istio/Sidecar Key: GEODE-9075 URL: https://issues.apache.org/jira/browse/GEODE-9075 Project: Geode Issue Type: Bug Reporter: Mario Ivanac Geode cluster is deployed in kubernetes environment, and Istio is injected between cluster members. While running traffic, if any istion/sidecar is restarted, thread can get stuck, while waiting for reply on sent message. [warn 2021/03/25 21:04:47.282 CET server2 tid=0x12] Thread <64> (0x40) that was executed at <25 Mar 2021 21:03:53 CET> has been stuck for <53.897 seconds> and number of thread monitor iteration <1> Thread Name state Waiting on Executor Group Monitored metric Thread stack: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:736) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:811) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:784) org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:874) org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:811) org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:699) org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277) org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318) org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520) ... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9075) Thread stuck indefinitely when using Istio/Sidecar
[ https://issues.apache.org/jira/browse/GEODE-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-9075: --- Assignee: Mario Ivanac > Thread stuck indefinitely when using Istio/Sidecar > -- > > Key: GEODE-9075 > URL: https://issues.apache.org/jira/browse/GEODE-9075 > Project: Geode > Issue Type: Bug >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > Geode cluster is deployed in kubernetes environment, and Istio is injected > between cluster members. While running traffic, if any istion/sidecar is > restarted, thread can get stuck, while waiting for reply on sent message. > > [warn 2021/03/25 21:04:47.282 CET server2 tid=0x12] Thread > <64> (0x40) that was executed at <25 Mar 2021 21:03:53 CET> has been stuck > for <53.897 seconds> and number of thread monitor iteration <1> > Thread Name state > Waiting on > Executor Group > Monitored metric > Thread stack: > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) > org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:736) > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:811) > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:784) > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:874) > org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:811) > org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:699) > org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277) > org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318) > org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:520) > ... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9074) CacheClientProxyStatistics messageQueueSize does not increase as events are added
Darrel Schneider created GEODE-9074: --- Summary: CacheClientProxyStatistics messageQueueSize does not increase as events are added Key: GEODE-9074 URL: https://issues.apache.org/jira/browse/GEODE-9074 Project: Geode Issue Type: Bug Components: client queues Reporter: Darrel Schneider Something I observed is that while a subscription queue was "full" the default throttling caused geode to only add 10 events/sec to the queue. This makes sense. But what didn't make sense was that the messageQueueSize did not change by 10 events/sec even though, during this time, nothing was draining from the queue. Then when the draining finally started (because the CacheClientUpdater started running after a long register interest that had been blocking it) we saw a huge spike in messageQueueSize when we should have seen gradual growth. In addition to improving messageQueueSize it would also be nice to have a gage stat that shows how many threads are currently trying to add to the queue. The throttle logic can cause a large number of thread to be blocked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9074) CacheClientProxyStatistics messageQueueSize does not increase as events are added
[ https://issues.apache.org/jira/browse/GEODE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9074: Labels: GeodeOperationAPI (was: ) > CacheClientProxyStatistics messageQueueSize does not increase as events are > added > - > > Key: GEODE-9074 > URL: https://issues.apache.org/jira/browse/GEODE-9074 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > Something I observed is that while a subscription queue was "full" the > default throttling caused geode to only add 10 events/sec to the queue. This > makes sense. But what didn't make sense was that the messageQueueSize did not > change by 10 events/sec even though, during this time, nothing was draining > from the queue. Then when the draining finally started (because the > CacheClientUpdater started running after a long register interest that had > been blocking it) we saw a huge spike in messageQueueSize when we should have > seen gradual growth. > In addition to improving messageQueueSize it would also be nice to have a > gage stat that shows how many threads are currently trying to add to the > queue. The throttle logic can cause a large number of thread to be blocked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9073) CacheClientUpdaterStatistics can be improved
[ https://issues.apache.org/jira/browse/GEODE-9073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9073: Labels: GeodeOperationAPI (was: ) > CacheClientUpdaterStatistics can be improved > > > Key: GEODE-9073 > URL: https://issues.apache.org/jira/browse/GEODE-9073 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > The CacheClientUpdaterStatistics should have a counter named "events" that is > incremented each time the updater thread receives an event from the queue. > It should also have a "eventProcessingTime" counter that measure total time > spent processing events. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9073) CacheClientUpdaterStatistics can be improved
Darrel Schneider created GEODE-9073: --- Summary: CacheClientUpdaterStatistics can be improved Key: GEODE-9073 URL: https://issues.apache.org/jira/browse/GEODE-9073 Project: Geode Issue Type: Improvement Components: client/server Reporter: Darrel Schneider The CacheClientUpdaterStatistics should have a counter named "events" that is incremented each time the updater thread receives an event from the queue. It should also have a "eventProcessingTime" counter that measure total time spent processing events. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9067) register-interest done during rolling upgrade can take longer than needed
[ https://issues.apache.org/jira/browse/GEODE-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9067: Labels: GeodeOperationAPI (was: ) > register-interest done during rolling upgrade can take longer than needed > - > > Key: GEODE-9067 > URL: https://issues.apache.org/jira/browse/GEODE-9067 > Project: Geode > Issue Type: Improvement > Components: client/server >Affects Versions: 1.1.0, 1.10.0, 1.11.0, 1.12.0, 1.12.1, 1.13.0, 1.13.1 >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > If a client does a register-interest to a server that is a newer geode > version than its peer servers (which happens during a rolling upgrade), and > the InterestResultPolicy is KEYS_VALUES (the default), on a partitioned > region, then the way the server fetches values that are on the older peer > servers is slower than it needs to be. Instead of sending that server a > single FetchBulkEntries message, it does an individual get for each key. This > individual get can also go to a primary of secondary and for correctness > register-interest needs to do all its reads from the primary. > The code has been doing this ever since the first release of geode. Once all > the members have been restarted then register-interest does its reads > optimally. Since a register-interest that is in progress prevents its > subscription queue from draining, this slow register-interest could cause > memory issues or performance issues on the cluster. But it really depends on > how big the region is, how big the cluster is, and the rate at which > operations that go into the subscription queue are being done. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9033) client read operations should not be blocked by a write operation
[
https://issues.apache.org/jira/browse/GEODE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9033:
Labels: GeodeOperationAPI (was: )
> client read operations should not be blocked by a write operation
> -
>
> Key: GEODE-9033
> URL: https://issues.apache.org/jira/browse/GEODE-9033
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI
>
> Client read operations currently will be blocked by a write operation that is
> in progress.
> This is caused by the write operation holding a synchronization on the
> RegionEntry and LocalRegion.getDeserializedValue synchronizing the
> RegionEntry with clientEvent is not null in order to atomically obtain both
> the entry's value and version.
> The read code in LocalRegion that causes this is:
> {code:java}
> synchronized (regionEntry) {
> // value & version must be obtained atomically
>
> clientEvent.setVersionTag(regionEntry.getVersionStamp().asVersionTag());
> value = getDeserialized(regionEntry, updateStats,
> disableCopyOnRead,
> preferCachedDeserializable, retainResult);
> }
> {code}
> To fix this it may be possible to change the write operations to synchronize
> on something else while changing both the value and version (but not while
> doing anything else). Then the read code can sync on that new Object and not
> the RegionEntry instance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9072) detect stuck CacheClientUpdater threads
[ https://issues.apache.org/jira/browse/GEODE-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9072: Labels: GeodeOperationAPI (was: ) > detect stuck CacheClientUpdater threads > --- > > Key: GEODE-9072 > URL: https://issues.apache.org/jira/browse/GEODE-9072 > Project: Geode > Issue Type: Improvement > Components: client queues >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > The CacheClientUpdater is a single thread on the client that drains the > subscription queue. If the updater thread gets stuck doing something then the > server side queue will not drain which can lead to either memory issues on > the server or throttling and thus performance issues. > It would be helpful if the geode thread monitor detected a CacheClientUpdater > thread that was stuck processing something it had removed from the queue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9072) detect stuck CacheClientUpdater threads
Darrel Schneider created GEODE-9072: --- Summary: detect stuck CacheClientUpdater threads Key: GEODE-9072 URL: https://issues.apache.org/jira/browse/GEODE-9072 Project: Geode Issue Type: Improvement Components: client queues Reporter: Darrel Schneider The CacheClientUpdater is a single thread on the client that drains the subscription queue. If the updater thread gets stuck doing something then the server side queue will not drain which can lead to either memory issues on the server or throttling and thus performance issues. It would be helpful if the geode thread monitor detected a CacheClientUpdater thread that was stuck processing something it had removed from the queue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9033) client read operations should not be blocked by a write operation
[
https://issues.apache.org/jira/browse/GEODE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308909#comment-17308909
]
Darrel Schneider commented on GEODE-9033:
-
I don't think atomics are a good solution here because the version stamp info
is actually stored in 6 non-volatile fields on the RegionEntry instance. I
think to use atomics we would need to change how the info is stored in the
RegionEntry and that may lead to a higher memory overhead.
As I have thought more about this solution it seems pretty basic. We just need
to make sure that code that sets both the version stamp and value does the
version stamp set first. We could limit how many spins we do before dropping
out of the spin loop and getting the sync. This would prevent clients from
spinning forever on entries that are being update frequently.
> client read operations should not be blocked by a write operation
> -
>
> Key: GEODE-9033
> URL: https://issues.apache.org/jira/browse/GEODE-9033
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Priority: Major
>
> Client read operations currently will be blocked by a write operation that is
> in progress.
> This is caused by the write operation holding a synchronization on the
> RegionEntry and LocalRegion.getDeserializedValue synchronizing the
> RegionEntry with clientEvent is not null in order to atomically obtain both
> the entry's value and version.
> The read code in LocalRegion that causes this is:
> {code:java}
> synchronized (regionEntry) {
> // value & version must be obtained atomically
>
> clientEvent.setVersionTag(regionEntry.getVersionStamp().asVersionTag());
> value = getDeserialized(regionEntry, updateStats,
> disableCopyOnRead,
> preferCachedDeserializable, retainResult);
> }
> {code}
> To fix this it may be possible to change the write operations to synchronize
> on something else while changing both the value and version (but not while
> doing anything else). Then the read code can sync on that new Object and not
> the RegionEntry instance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9071) CI Failure: PartitionedRegionCqQueryDUnitTest > testRemoveAllWithCQLocalDestroy
Jens Deppe created GEODE-9071:
-
Summary: CI Failure: PartitionedRegionCqQueryDUnitTest >
testRemoveAllWithCQLocalDestroy
Key: GEODE-9071
URL: https://issues.apache.org/jira/browse/GEODE-9071
Project: Geode
Issue Type: Bug
Components: cq
Reporter: Jens Deppe
{noformat}
org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest >
testRemoveAllWithCQLocalDestroy FAILED
10:10:22org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest$$Lambda$87/434016892.run
in VM 2 running on Host bb8c1d338b8b with 4 VMs
10:10:22at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
10:10:22at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
10:10:22at
org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.testRemoveAllWithCQLocalDestroy(PartitionedRegionCqQueryDUnitTest.java:243)
10:10:22
10:10:22Caused by:
10:10:22org.junit.ComparisonFailure: expected:<[999]> but was:<[645]>
10:10:22at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
10:10:22at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
10:10:22at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
10:10:22at
org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.lambda$testRemoveAllWithCQLocalDestroy$c93719d5$3(PartitionedRegionCqQueryDUnitTest.java:251)
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-results/distributedTest/1616696789/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-artifacts/1616696789/distributedtestfiles-OpenJDK8-1.15.0-build.0082.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9071) CI Failure: PartitionedRegionCqQueryDUnitTest > testRemoveAllWithCQLocalDestroy
[
https://issues.apache.org/jira/browse/GEODE-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308904#comment-17308904
]
Geode Integration commented on GEODE-9071:
--
Seen in [DistributedTestOpenJDK8
#101|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/101]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-results/distributedTest/1616696789/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-artifacts/1616696789/distributedtestfiles-OpenJDK8-1.15.0-build.0082.tgz].
> CI Failure: PartitionedRegionCqQueryDUnitTest >
> testRemoveAllWithCQLocalDestroy
> ---
>
> Key: GEODE-9071
> URL: https://issues.apache.org/jira/browse/GEODE-9071
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Jens Deppe
>Priority: Major
>
> {noformat}
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest >
> testRemoveAllWithCQLocalDestroy FAILED
> 10:10:22org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest$$Lambda$87/434016892.run
> in VM 2 running on Host bb8c1d338b8b with 4 VMs
> 10:10:22at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 10:10:22at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 10:10:22at
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.testRemoveAllWithCQLocalDestroy(PartitionedRegionCqQueryDUnitTest.java:243)
> 10:10:22
> 10:10:22Caused by:
> 10:10:22org.junit.ComparisonFailure: expected:<[999]> but was:<[645]>
> 10:10:22at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 10:10:22at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 10:10:22at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 10:10:22at
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.lambda$testRemoveAllWithCQLocalDestroy$c93719d5$3(PartitionedRegionCqQueryDUnitTest.java:251)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-results/distributedTest/1616696789/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-artifacts/1616696789/distributedtestfiles-OpenJDK8-1.15.0-build.0082.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9033) client read operations should not be blocked by a write operation
[
https://issues.apache.org/jira/browse/GEODE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308877#comment-17308877
]
Kirk Lund commented on GEODE-9033:
--
Non-volatile fields may flush at any unspecified time, so yes it may read the
value later.
I remember Java Concurrency in Practice making the claim that reading/writing a
volatile field or acquiring synchronization on any monitor will cause all
non-volatile fields to flush as well. I suspect it's chapter 16 that explains
this.
So, if the code writes to a non-volatile field and then writes to a volatile
field, all other thread(s) that read the volatile field should also immediately
have visibility to all other non-volatile fields that changed.
Atomics might be another option. Since they handle non-blocking spinning, one
of the API methods might provide what's needed without having to write
something custom. Chapter 14 talks about how to write custom synchronization
which is what it sounds like you're leaning towards. Chapter 15 has some good
info about Atomics as well.
> client read operations should not be blocked by a write operation
> -
>
> Key: GEODE-9033
> URL: https://issues.apache.org/jira/browse/GEODE-9033
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Priority: Major
>
> Client read operations currently will be blocked by a write operation that is
> in progress.
> This is caused by the write operation holding a synchronization on the
> RegionEntry and LocalRegion.getDeserializedValue synchronizing the
> RegionEntry with clientEvent is not null in order to atomically obtain both
> the entry's value and version.
> The read code in LocalRegion that causes this is:
> {code:java}
> synchronized (regionEntry) {
> // value & version must be obtained atomically
>
> clientEvent.setVersionTag(regionEntry.getVersionStamp().asVersionTag());
> value = getDeserialized(regionEntry, updateStats,
> disableCopyOnRead,
> preferCachedDeserializable, retainResult);
> }
> {code}
> To fix this it may be possible to change the write operations to synchronize
> on something else while changing both the value and version (but not while
> doing anything else). Then the read code can sync on that new Object and not
> the RegionEntry instance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308873#comment-17308873 ] ASF subversion and git services commented on GEODE-8950: Commit e0b1babd57924fa6fab2af1b4cd109170002c608 in geode-benchmarks's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=e0b1bab ] Disable P2pPartitionedPutLongBenchmark (#140) - This benchmark is unstable and does not produce reliable results. See GEODE-8950 for further details. Authored-by: Donal Evans > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.14.0, blocks-1.15.0 > Attachments: GEODE-8950-before-after-histogram-chart.png, > GEODE-8950-performance degradation vs 1.13.png > > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9048) Remove the timeout on DockerizedExecHandle startup
[
https://issues.apache.org/jira/browse/GEODE-9048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-9048.
---
Fix Version/s: 1.15.0
Resolution: Fixed
Fixed by extending the timeouts instead of removing them.
> Remove the timeout on DockerizedExecHandle startup
> --
>
> Key: GEODE-9048
> URL: https://issues.apache.org/jira/browse/GEODE-9048
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> In the Dockerized test plugin, {{DockerizedExecHandle.start()}} throws a
> timeout exception if the process does not start within 30 seconds. The error
> handling code tries to abort the process, gets confused because the process
> has not started, and throws an {{IllegalStateException}}, preventing Gradle
> from reporting the original timeout exception.
> {{DockerizedExecHandle.start()}} is a modified copy of the code from Gradle's
> {{DefaultExecHandle}}. Gradle's code does not have a timeout on starting the
> process. But a successfully started process immediately connects to Gradle,
> and Gradle throws an exception if the connection doesn't happen within 2
> minutes.
> The {{DockerizedExecHandle}} timeout hides the real problem, which is that
> the process takes too long to start, or too long to report that it has
> started. Removing that timeout will allow Gradle to give better diagnostic
> information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-9048) Remove the timeout on DockerizedExecHandle startup
[
https://issues.apache.org/jira/browse/GEODE-9048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery closed GEODE-9048.
-
> Remove the timeout on DockerizedExecHandle startup
> --
>
> Key: GEODE-9048
> URL: https://issues.apache.org/jira/browse/GEODE-9048
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> In the Dockerized test plugin, {{DockerizedExecHandle.start()}} throws a
> timeout exception if the process does not start within 30 seconds. The error
> handling code tries to abort the process, gets confused because the process
> has not started, and throws an {{IllegalStateException}}, preventing Gradle
> from reporting the original timeout exception.
> {{DockerizedExecHandle.start()}} is a modified copy of the code from Gradle's
> {{DefaultExecHandle}}. Gradle's code does not have a timeout on starting the
> process. But a successfully started process immediately connects to Gradle,
> and Gradle throws an exception if the connection doesn't happen within 2
> minutes.
> The {{DockerizedExecHandle}} timeout hides the real problem, which is that
> the process takes too long to start, or too long to report that it has
> started. Removing that timeout will allow Gradle to give better diagnostic
> information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9017) Reload key store and trust store upon change
[ https://issues.apache.org/jira/browse/GEODE-9017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-9017. -- Fix Version/s: 1.15.0 Resolution: Fixed > Reload key store and trust store upon change > > > Key: GEODE-9017 > URL: https://issues.apache.org/jira/browse/GEODE-9017 > Project: Geode > Issue Type: New Feature >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > [Link to > RFC|https://cwiki.apache.org/confluence/display/GEODE/Make+key+and+trust+stores+reload+automatically+upon+change] > (The below text is copied from the RFC document.) > h3. Problem > Currently, in order to rotate certificates each member of the cluster needs > to be restarted to load new certs and trust. It would be preferable if > certificates can be rotated without having to restart members. > h3. Solution > When starting up a cluster member we currently read the TLS configuration > which, when TLS is enabled has key and trust store files defined. In case > those files are defined they are read, and the information inside them is > loaded into the key and trust manager objects that are loaded into the > SSLContext. > This solution will introduce wrapper objects for the key and trust managers > and file/directory watcher(s) that can detect changes to the key and trust > store files. When key and trust store files are changed this will trigger a > reload into key and trust managers and through the wrapper objects these new > key and trust managers will be injected into the SSLContext so that the > context can start using the new key and trust managers in process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9022) Redis: add unit/integration/dunit tests for INFO command
[ https://issues.apache.org/jira/browse/GEODE-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9022: Fix Version/s: 1.14.0 > Redis: add unit/integration/dunit tests for INFO command > > > Key: GEODE-9022 > URL: https://issues.apache.org/jira/browse/GEODE-9022 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers for the INFO command. > A.C. > Users can connect and see data for the Datadog compatible Redis dashboard. > Unit/integration tests for both Geode and native Redis passing > DUNIT tests passing > README/redis_api_for_geode.html.md.erb updated to make command "supported", > plus documentation of the fields we support > and > Stories in the backlog to fix the identified issues (with JIRA tickets) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9019) Convert all redis data structures to DataSerializableFixedID
[ https://issues.apache.org/jira/browse/GEODE-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9019: Fix Version/s: 1.15.0 > Convert all redis data structures to DataSerializableFixedID > > > Key: GEODE-9019 > URL: https://issues.apache.org/jira/browse/GEODE-9019 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Issue: > * Currently, a couple of redis data structures are using DataSerializable > * This will cause issues during rolling upgrade > Solution: > * Convert these data structures to DataSerializableFixedIDs. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9040) The SingleThreadColocationLogger executorService is not shutdown when the server is stopped
[
https://issues.apache.org/jira/browse/GEODE-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9040:
Fix Version/s: 1.15.0
> The SingleThreadColocationLogger executorService is not shutdown when the
> server is stopped
> ---
>
> Key: GEODE-9040
> URL: https://issues.apache.org/jira/browse/GEODE-9040
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> When a server is shutdown, its JVM remains alive because the ExecutorService
> created by the SingleThreadColocationLogger is not terminated nor is its
> thread a daemon:
> {noformat}
> "ColocationLogger for customer" #57 prio=5 os_prio=31 tid=0x7fb39d4e4000
> nid=0xb203 waiting on condition [0x7dc58000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000785268818> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The SingleThreadColocationLogger only gets created when there are missing
> co-located regions.
> We can either terminate the ExecutorService or make its thread a daemon or
> both.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9043) A register interest attempt from a newer client to an older server throws a NoSubscriptionServersAvailableException instead of a ServerRefusedConnectionException
[
https://issues.apache.org/jira/browse/GEODE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9043:
Fix Version/s: 1.15.0
> A register interest attempt from a newer client to an older server throws a
> NoSubscriptionServersAvailableException instead of a
> ServerRefusedConnectionException
> -
>
> Key: GEODE-9043
> URL: https://issues.apache.org/jira/browse/GEODE-9043
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Barrett Oglesby
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> The exception in the register interest case is a bit confusing.
> If a 1.13.2 client attempts to connect to a 1.13.0 server and do a put, it
> throws this ServerRefusedConnectionException with the exact cause:
> {noformat}
> Exception in thread "main"
> org.apache.geode.cache.client.NoAvailableServersException:
> org.apache.geode.cache.client.ServerRefusedConnectionException:
> nn.nnn.nnn.nn(3047):41001(version:GEODE 1.13.0) refused connection: Peer
> or client version with ordinal 121 not supported. Highest known version is
> 1.13.0 Client: /nn.nnn.nnn.nn:64123.
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:200)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:273)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:796)
> at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:91)
> {noformat}
> If the client attempts to registerInterest, it throws this
> NoSubscriptionServersAvailableException:
> {noformat}
> Exception in thread "main"
> org.apache.geode.cache.NoSubscriptionServersAvailableException:
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
> initialize a primary queue on startup. No queue servers available.
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:432)
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:870)
> at
> org.apache.geode.cache.Region.registerInterestForAllKeys(Region.java:1657)
> {noformat}
> The log does contain a message like below so it can be determined the exact
> cause, but not in the exception:
> {noformat}
> [warn 2021/03/15 11:59:04.100 PDT client tid=0x1] Could not create a
> new connection to server: nn.nnn.nnn.nn(9838):41001(version:GEODE 1.13.0)
> refused connection: Peer or client version with ordinal 121 not supported.
> Highest known version is 1.13.0 Client: /nn.nnn.nnn.nn:65323.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9044) Introduce RedisKey as key object for RedisData entries
[
https://issues.apache.org/jira/browse/GEODE-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9044:
Fix Version/s: 1.15.0
> Introduce RedisKey as key object for RedisData entries
> --
>
> Key: GEODE-9044
> URL: https://issues.apache.org/jira/browse/GEODE-9044
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> Currently we are using a {{ByteArrayWrapper}} as the key for all redis
> entries. Now that we also have a {{PartitionResolver}} the {{routingId}} is
> optionally computed when needed. Adding an explicit object to represent the
> key makes for a cleaner abstraction and allows the routing id to be
> calculated when the key is instantiated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9070) CI Failure: ClientServerSessionCacheDUnitTest > addServerToExistingClusterCreatesSessionRegion
[
https://issues.apache.org/jira/browse/GEODE-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308788#comment-17308788
]
Geode Integration commented on GEODE-9070:
--
Seen in [DistributedTestOpenJDK8
#100|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/100]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161716/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161716/distributedtestfiles-OpenJDK8-1.15.0-build.0081.tgz].
> CI Failure: ClientServerSessionCacheDUnitTest >
> addServerToExistingClusterCreatesSessionRegion
> --
>
> Key: GEODE-9070
> URL: https://issues.apache.org/jira/browse/GEODE-9070
> Project: Geode
> Issue Type: Bug
> Components: ci, http session
>Reporter: Jens Deppe
>Priority: Major
>
> {noformat}
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest >
> addServerToExistingClusterCreatesSessionRegion FAILED
> 00:47:45org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest$$Lambda$84/1299235653.run
> in VM 1 running on Host 51208612ea94 with 4 VMs
> 00:47:45at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 00:47:45at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.addServerToExistingClusterCreatesSessionRegion(ClientServerSessionCacheDUnitTest.java:100)
> 00:47:45
> 00:47:45Caused by:
> 00:47:45org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest
> 00:47:45Expected size: 1 but was: 0 in:
> 00:47:45[] within 5 minutes.
> 00:47:45at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 00:47:45at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 00:47:45at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 00:47:45at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 00:47:45at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.lambda$addServerToExistingClusterCreatesSessionRegion$bb17a952$1(ClientServerSessionCacheDUnitTest.java:100)
> 00:47:45
> 00:47:45Caused by:
> 00:47:45java.lang.AssertionError:
> 00:47:45Expected size: 1 but was: 0 in:
> 00:47:45[]
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateBootstrapped(ClientServerSessionCacheDUnitTest.java:258)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateServer(ClientServerSessionCacheDUnitTest.java:245)
> 00:47:53{noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161716/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161716/distributedtestfiles-OpenJDK8-1.15.0-build.0081.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9070) CI Failure: ClientServerSessionCacheDUnitTest > addServerToExistingClusterCreatesSessionRegion
Jens Deppe created GEODE-9070:
-
Summary: CI Failure: ClientServerSessionCacheDUnitTest >
addServerToExistingClusterCreatesSessionRegion
Key: GEODE-9070
URL: https://issues.apache.org/jira/browse/GEODE-9070
Project: Geode
Issue Type: Bug
Components: ci, http session
Reporter: Jens Deppe
{noformat}
org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest >
addServerToExistingClusterCreatesSessionRegion FAILED
00:47:45org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest$$Lambda$84/1299235653.run
in VM 1 running on Host 51208612ea94 with 4 VMs
00:47:45at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
00:47:45at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
00:47:45at
org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.addServerToExistingClusterCreatesSessionRegion(ClientServerSessionCacheDUnitTest.java:100)
00:47:45
00:47:45Caused by:
00:47:45org.awaitility.core.ConditionTimeoutException: Assertion
condition defined as a lambda expression in
org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest
00:47:45Expected size: 1 but was: 0 in:
00:47:45[] within 5 minutes.
00:47:45at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
00:47:45at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
00:47:45at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
00:47:45at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
00:47:45at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
00:47:45at
org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.lambda$addServerToExistingClusterCreatesSessionRegion$bb17a952$1(ClientServerSessionCacheDUnitTest.java:100)
00:47:45
00:47:45Caused by:
00:47:45java.lang.AssertionError:
00:47:45Expected size: 1 but was: 0 in:
00:47:45[]
00:47:45at
org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateBootstrapped(ClientServerSessionCacheDUnitTest.java:258)
00:47:45at
org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateServer(ClientServerSessionCacheDUnitTest.java:245)
00:47:53{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161716/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161716/distributedtestfiles-OpenJDK8-1.15.0-build.0081.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9037) Do not expose unsupported commands in Geode compatibility with Redis
[ https://issues.apache.org/jira/browse/GEODE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308770#comment-17308770 ] ASF subversion and git services commented on GEODE-9037: Commit 6372ba430b2dc0c0ccfcf68ca64767495123b3b1 in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6372ba4 ] GEODE-9037: Remove unimplemented commands -update handling of unsupported commands > Do not expose unsupported commands in Geode compatibility with Redis > > > Key: GEODE-9037 > URL: https://issues.apache.org/jira/browse/GEODE-9037 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The distinction between 'supported' and 'unsupported' commands is no longer > useful and will be removed. Any commands still listed as unsupported will now > respond if they were unimplemented/unknown. > A system property will allow them to be enabled solely for tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9037) Do not expose unsupported commands in Geode compatibility with Redis
[ https://issues.apache.org/jira/browse/GEODE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308772#comment-17308772 ] ASF subversion and git services commented on GEODE-9037: Commit 8134891c0f032cbfa12a9aec3d9d7023ce8a in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8134891 ] Merge pull request #6155 from ringles/GEODE-9037-do-not-expose-unsupported-commands GEODE-9037: Do not expose unsupported commands in Geode compatibility with Redis > Do not expose unsupported commands in Geode compatibility with Redis > > > Key: GEODE-9037 > URL: https://issues.apache.org/jira/browse/GEODE-9037 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The distinction between 'supported' and 'unsupported' commands is no longer > useful and will be removed. Any commands still listed as unsupported will now > respond if they were unimplemented/unknown. > A system property will allow them to be enabled solely for tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9037) Do not expose unsupported commands in Geode compatibility with Redis
[ https://issues.apache.org/jira/browse/GEODE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308771#comment-17308771 ] ASF subversion and git services commented on GEODE-9037: Commit 8134891c0f032cbfa12a9aec3d9d7023ce8a in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8134891 ] Merge pull request #6155 from ringles/GEODE-9037-do-not-expose-unsupported-commands GEODE-9037: Do not expose unsupported commands in Geode compatibility with Redis > Do not expose unsupported commands in Geode compatibility with Redis > > > Key: GEODE-9037 > URL: https://issues.apache.org/jira/browse/GEODE-9037 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The distinction between 'supported' and 'unsupported' commands is no longer > useful and will be removed. Any commands still listed as unsupported will now > respond if they were unimplemented/unknown. > A system property will allow them to be enabled solely for tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9037) Do not expose unsupported commands in Geode compatibility with Redis
[ https://issues.apache.org/jira/browse/GEODE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hutchison resolved GEODE-9037. --- Resolution: Fixed > Do not expose unsupported commands in Geode compatibility with Redis > > > Key: GEODE-9037 > URL: https://issues.apache.org/jira/browse/GEODE-9037 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The distinction between 'supported' and 'unsupported' commands is no longer > useful and will be removed. Any commands still listed as unsupported will now > respond if they were unimplemented/unknown. > A system property will allow them to be enabled solely for tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9069) CI Failure: org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest > testConcurrentHExists_whileAddingValues FAILED
[
https://issues.apache.org/jira/browse/GEODE-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308757#comment-17308757
]
Geode Integration commented on GEODE-9069:
--
Seen in [DistributedTestOpenJDK11
#104|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/104]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161436/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161436/distributedtestfiles-OpenJDK11-1.15.0-build.0081.tgz].
> CI Failure: org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest >
> testConcurrentHExists_whileAddingValues FAILED
> ---
>
> Key: GEODE-9069
> URL: https://issues.apache.org/jira/browse/GEODE-9069
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest >
> testConcurrentHExists_whileAddingValues FAILED
> 00:56:20java.lang.RuntimeException:
> java.util.concurrent.ExecutionException:
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:77)
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.runInLockstep(ConcurrentLoopingThreads.java:96)
> 00:56:20at
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest.testConcurrentHExists_whileAddingValues(HExistsDUnitTest.java:121)
> 00:56:20
> 00:56:20Caused by:
> 00:56:20java.util.concurrent.ExecutionException:
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
> 00:56:20at
> java.util.concurrent.FutureTask.get(FutureTask.java:205)
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:73)
> 00:56:20... 2 more
> 00:56:20
> 00:56:20Caused by:
> 00:56:20org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 00:56:20at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 00:56:20at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 00:56:20at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 00:56:20at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 00:56:20at
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest.lambda$testConcurrentHExists_whileAddingValues$5(HExistsDUnitTest.java:120)
> 00:56:20
> 00:56:20Caused by:
> 00:56:20java.util.concurrent.TimeoutException
> 00:56:20at
> java.util.concurrent.FutureTask.get(FutureTask.java:204)
> 00:56:20at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
> 00:56:20at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
> 00:56:20at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:101)
> 00:56:20... 5 more {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161436/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161436/distributedtestfiles-OpenJDK11-1.15.0-build.0081.tgz
--
This message was sent by Atlassian
[jira] [Assigned] (GEODE-9069) CI Failure: org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest > testConcurrentHExists_whileAddingValues FAILED
[
https://issues.apache.org/jira/browse/GEODE-9069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9069:
-
Assignee: Hale Bales
> CI Failure: org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest >
> testConcurrentHExists_whileAddingValues FAILED
> ---
>
> Key: GEODE-9069
> URL: https://issues.apache.org/jira/browse/GEODE-9069
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest >
> testConcurrentHExists_whileAddingValues FAILED
> 00:56:20java.lang.RuntimeException:
> java.util.concurrent.ExecutionException:
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:77)
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.runInLockstep(ConcurrentLoopingThreads.java:96)
> 00:56:20at
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest.testConcurrentHExists_whileAddingValues(HExistsDUnitTest.java:121)
> 00:56:20
> 00:56:20Caused by:
> 00:56:20java.util.concurrent.ExecutionException:
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
> 00:56:20at
> java.util.concurrent.FutureTask.get(FutureTask.java:205)
> 00:56:20at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:73)
> 00:56:20... 2 more
> 00:56:20
> 00:56:20Caused by:
> 00:56:20org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
> java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
> 00:56:20at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 00:56:20at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 00:56:20at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 00:56:20at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 00:56:20at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 00:56:20at
> org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest.lambda$testConcurrentHExists_whileAddingValues$5(HExistsDUnitTest.java:120)
> 00:56:20
> 00:56:20Caused by:
> 00:56:20java.util.concurrent.TimeoutException
> 00:56:20at
> java.util.concurrent.FutureTask.get(FutureTask.java:204)
> 00:56:20at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
> 00:56:20at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
> 00:56:20at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:101)
> 00:56:20... 5 more {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161436/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161436/distributedtestfiles-OpenJDK11-1.15.0-build.0081.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9069) CI Failure: org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest > testConcurrentHExists_whileAddingValues FAILED
Jens Deppe created GEODE-9069:
-
Summary: CI Failure:
org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest >
testConcurrentHExists_whileAddingValues FAILED
Key: GEODE-9069
URL: https://issues.apache.org/jira/browse/GEODE-9069
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Jens Deppe
{noformat}
org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest >
testConcurrentHExists_whileAddingValues FAILED
00:56:20java.lang.RuntimeException:
java.util.concurrent.ExecutionException:
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a
lambda expression in
org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
00:56:20at
org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:77)
00:56:20at
org.apache.geode.redis.ConcurrentLoopingThreads.runInLockstep(ConcurrentLoopingThreads.java:96)
00:56:20at
org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest.testConcurrentHExists_whileAddingValues(HExistsDUnitTest.java:121)
00:56:20
00:56:20Caused by:
00:56:20java.util.concurrent.ExecutionException:
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a
lambda expression in
org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
00:56:20at
java.util.concurrent.FutureTask.report(FutureTask.java:122)
00:56:20at java.util.concurrent.FutureTask.get(FutureTask.java:205)
00:56:20at
org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:73)
00:56:20... 2 more
00:56:20
00:56:20Caused by:
00:56:20org.awaitility.core.ConditionTimeoutException: Assertion
condition defined as a lambda expression in
org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest that uses
java.lang.String, java.lang.Stringjava.lang.Integer null within 1 seconds.
00:56:20at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
00:56:20at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
00:56:20at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
00:56:20at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
00:56:20at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
00:56:20at
org.apache.geode.redis.internal.executor.hash.HExistsDUnitTest.lambda$testConcurrentHExists_whileAddingValues$5(HExistsDUnitTest.java:120)
00:56:20
00:56:20Caused by:
00:56:20java.util.concurrent.TimeoutException
00:56:20at
java.util.concurrent.FutureTask.get(FutureTask.java:204)
00:56:20at
org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
00:56:20at
org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
00:56:20at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:101)
00:56:20... 5 more {noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161436/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161436/distributedtestfiles-OpenJDK11-1.15.0-build.0081.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9068) Update Documents to show removal of unsupported commands category
[ https://issues.apache.org/jira/browse/GEODE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hutchison updated GEODE-9068: -- Summary: Update Documents to show removal of unsupported commands category (was: Update Documents to show removal of unsupported commands feature) > Update Documents to show removal of unsupported commands category > - > > Key: GEODE-9068 > URL: https://issues.apache.org/jira/browse/GEODE-9068 > Project: Geode > Issue Type: Task > Components: redis >Reporter: John Hutchison >Priority: Major > > update docs to represent changes in > https://issues.apache.org/jira/browse/GEODE-9037 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9037) Do not expose unsupported commands in Geode compatibility with Redis
[ https://issues.apache.org/jira/browse/GEODE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308752#comment-17308752 ] John Hutchison commented on GEODE-9037: --- docs changes for this story under https://issues.apache.org/jira/browse/GEODE-9068 > Do not expose unsupported commands in Geode compatibility with Redis > > > Key: GEODE-9037 > URL: https://issues.apache.org/jira/browse/GEODE-9037 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The distinction between 'supported' and 'unsupported' commands is no longer > useful and will be removed. Any commands still listed as unsupported will now > respond if they were unimplemented/unknown. > A system property will allow them to be enabled solely for tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9068) Update Documents to show removal of unsupported commands feature
[ https://issues.apache.org/jira/browse/GEODE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hutchison updated GEODE-9068: -- Description: update docs to represent changes in https://issues.apache.org/jira/browse/GEODE-9037 > Update Documents to show removal of unsupported commands feature > > > Key: GEODE-9068 > URL: https://issues.apache.org/jira/browse/GEODE-9068 > Project: Geode > Issue Type: Task > Components: redis >Reporter: John Hutchison >Priority: Major > > update docs to represent changes in > https://issues.apache.org/jira/browse/GEODE-9037 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9068) Update Documents to show removal of unsupported commands feature
John Hutchison created GEODE-9068: - Summary: Update Documents to show removal of unsupported commands feature Key: GEODE-9068 URL: https://issues.apache.org/jira/browse/GEODE-9068 Project: Geode Issue Type: Task Components: redis Reporter: John Hutchison -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9018) ExtendedNumericComparator does not compare correctly NULL and UNDEFINED
[ https://issues.apache.org/jira/browse/GEODE-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-9018. -- Fix Version/s: 1.15.0 Resolution: Fixed > ExtendedNumericComparator does not compare correctly NULL and UNDEFINED > --- > > Key: GEODE-9018 > URL: https://issues.apache.org/jira/browse/GEODE-9018 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The compareTo method of ExtendedNumericComparator does not compare correctly > UNDEFINED and NULL. > UNDEFINED should always be smaller than anything but it is not always so when > compared with NULL. > compareTo(NULL, UNDEFINED) returns 1, which is correct > but > compareTo(UNDEFINED, NULL) returns 1, and it should return -1. > This could provoke that queries with indexes do not return the right results > when these values are involved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8318) Shutdown hang and abort
[ https://issues.apache.org/jira/browse/GEODE-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-8318. -- Fix Version/s: 1.15.0 Resolution: Fixed > Shutdown hang and abort > --- > > Key: GEODE-8318 > URL: https://issues.apache.org/jira/browse/GEODE-8318 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Matthew Reddington >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Switching from Ace to Boost.Asio has revealed threading issues related to > shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9063) Make mandatory options to appear first when autocompleting in gfsh
[ https://issues.apache.org/jira/browse/GEODE-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9063: -- Labels: pull-request-available (was: ) > Make mandatory options to appear first when autocompleting in gfsh > -- > > Key: GEODE-9063 > URL: https://issues.apache.org/jira/browse/GEODE-9063 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > When writting a command in gfsh followed by "--" and then pressing "tab" to > obtain command completion suggestions, the mandatory options should be shown > in first place. > This was recently fixed in GEODE-9034 for "create gateway-sender" but there > are some more commands to be fixed: > * change log-level > * create disk-store > * create jndi-binding > * destroy gateway-sender > * export data > * import data > * remove -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9034) Make mandatory options to appear first when autocompleting in create gateway sender command
[ https://issues.apache.org/jira/browse/GEODE-9034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-9034. -- Fix Version/s: 1.15.0 Resolution: Fixed > Make mandatory options to appear first when autocompleting in create gateway > sender command > --- > > Key: GEODE-9034 > URL: https://issues.apache.org/jira/browse/GEODE-9034 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When typing "create gateway-sender --" from gfsh and pressing tab to suggest > options, the "group" option is autocompleted instead of any of the mandatory > ones. > It would be expected that the mandatory options appear first (id and > remote-distributed-id). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9062) DataSerializableJUnitTest fails in StressTest task
[
https://issues.apache.org/jira/browse/GEODE-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes resolved GEODE-9062.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> DataSerializableJUnitTest fails in StressTest task
> --
>
> Key: GEODE-9062
> URL: https://issues.apache.org/jira/browse/GEODE-9062
> Project: Geode
> Issue Type: Bug
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> DataSerializableJUnitTest is failing if executed using the "repeatUnitTest"
> gradle task. I dont know what is causing this failure, but I got the error
> when verifying a PR ( [https://concourse.apachegeode-ci.info/builds/17155] )
> and I realized it is failing in develop branch too.
> {code}
> ~/git/apache/geode (develop) $ ./gradlew geode-core:repeatUnitTest
> --tests=DataSerializableJUnitTest
> ...
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS2 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS2(DataSerializableJUnitTest.java:2284)
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS4 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS4(DataSerializableJUnitTest.java:2307)
> org.apache.geode.internal.DataSerializableJUnitTest > testSupportedClasses
> FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testSupportedClasses(DataSerializableJUnitTest.java:2260)
> 11100 tests completed, 297 failed, 200 skipped
> > Task :geode-core:repeatUnitTest FAILED
> > Task :combineReports
> All test reports at /home/alb3rtobr/git/apache/geode/build/reports/combined
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-core:repeatUnitTest'.
> > There were failing tests. See the report at:
> > file:///home/alb3rtobr/git/apache/geode/geode-core/build/reports/repeatUnitTest/index.html
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> BUILD FAILED in 1m 8s
> 36 actionable tasks: 2 executed, 34 up-to-date
> ~/git/apache/geode (develop) $ git log -n 1
> commit a45dbf94de2f35b869a3dd0e1cf945f5282e2fd0 (HEAD -> develop,
> origin/develop, origin/HEAD)
> Author: Mario Kevo <48509719+mk...@users.noreply.github.com>
> Date: Wed Mar 24 10:25:29 2021 +0100
> GEODE-8962: add an option to escape dollar($) character in the query (#6044)
>
> * GEODE-8962: add an option to escape dollar($) character in the query
> {code}
> Three tests are failing: testSupportedClasses, testUDDS2 and testUDDS4.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9062) DataSerializableJUnitTest fails in StressTest task
[
https://issues.apache.org/jira/browse/GEODE-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308442#comment-17308442
]
ASF subversion and git services commented on GEODE-9062:
Commit c800898eb5ae31fa583c0e16b5701f4f1eaca466 in geode's branch
refs/heads/develop from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c800898 ]
GEODE-9062: Fix for DataSerializableJUnit in StressTest (#6182)
* GEODE-9062: Fix for DataSerializableJUnit in StressTest
* Empty commit to retrigger CI
> DataSerializableJUnitTest fails in StressTest task
> --
>
> Key: GEODE-9062
> URL: https://issues.apache.org/jira/browse/GEODE-9062
> Project: Geode
> Issue Type: Bug
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> DataSerializableJUnitTest is failing if executed using the "repeatUnitTest"
> gradle task. I dont know what is causing this failure, but I got the error
> when verifying a PR ( [https://concourse.apachegeode-ci.info/builds/17155] )
> and I realized it is failing in develop branch too.
> {code}
> ~/git/apache/geode (develop) $ ./gradlew geode-core:repeatUnitTest
> --tests=DataSerializableJUnitTest
> ...
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS2 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS2(DataSerializableJUnitTest.java:2284)
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS4 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS4(DataSerializableJUnitTest.java:2307)
> org.apache.geode.internal.DataSerializableJUnitTest > testSupportedClasses
> FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testSupportedClasses(DataSerializableJUnitTest.java:2260)
> 11100 tests completed, 297 failed, 200 skipped
> > Task :geode-core:repeatUnitTest FAILED
> > Task :combineReports
> All test reports at /home/alb3rtobr/git/apache/geode/build/reports/combined
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-core:repeatUnitTest'.
> > There were failing tests. See the report at:
> > file:///home/alb3rtobr/git/apache/geode/geode-core/build/reports/repeatUnitTest/index.html
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> BUILD FAILED in 1m 8s
> 36 actionable tasks: 2 executed, 34 up-to-date
> ~/git/apache/geode (develop) $ git log -n 1
> commit a45dbf94de2f35b869a3dd0e1cf945f5282e2fd0 (HEAD -> develop,
> origin/develop, origin/HEAD)
> Author: Mario Kevo <48509719+mk...@users.noreply.github.com>
> Date: Wed Mar 24 10:25:29 2021 +0100
> GEODE-8962: add an option to escape dollar($) character in the query (#6044)
>
> * GEODE-8962: add an option to escape dollar($) character in the query
> {code}
> Three tests are failing: testSupportedClasses, testUDDS2 and testUDDS4.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9062) DataSerializableJUnitTest fails in StressTest task
[
https://issues.apache.org/jira/browse/GEODE-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308441#comment-17308441
]
ASF subversion and git services commented on GEODE-9062:
Commit c800898eb5ae31fa583c0e16b5701f4f1eaca466 in geode's branch
refs/heads/develop from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c800898 ]
GEODE-9062: Fix for DataSerializableJUnit in StressTest (#6182)
* GEODE-9062: Fix for DataSerializableJUnit in StressTest
* Empty commit to retrigger CI
> DataSerializableJUnitTest fails in StressTest task
> --
>
> Key: GEODE-9062
> URL: https://issues.apache.org/jira/browse/GEODE-9062
> Project: Geode
> Issue Type: Bug
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> DataSerializableJUnitTest is failing if executed using the "repeatUnitTest"
> gradle task. I dont know what is causing this failure, but I got the error
> when verifying a PR ( [https://concourse.apachegeode-ci.info/builds/17155] )
> and I realized it is failing in develop branch too.
> {code}
> ~/git/apache/geode (develop) $ ./gradlew geode-core:repeatUnitTest
> --tests=DataSerializableJUnitTest
> ...
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS2 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS2(DataSerializableJUnitTest.java:2284)
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS4 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS4(DataSerializableJUnitTest.java:2307)
> org.apache.geode.internal.DataSerializableJUnitTest > testSupportedClasses
> FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testSupportedClasses(DataSerializableJUnitTest.java:2260)
> 11100 tests completed, 297 failed, 200 skipped
> > Task :geode-core:repeatUnitTest FAILED
> > Task :combineReports
> All test reports at /home/alb3rtobr/git/apache/geode/build/reports/combined
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-core:repeatUnitTest'.
> > There were failing tests. See the report at:
> > file:///home/alb3rtobr/git/apache/geode/geode-core/build/reports/repeatUnitTest/index.html
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> BUILD FAILED in 1m 8s
> 36 actionable tasks: 2 executed, 34 up-to-date
> ~/git/apache/geode (develop) $ git log -n 1
> commit a45dbf94de2f35b869a3dd0e1cf945f5282e2fd0 (HEAD -> develop,
> origin/develop, origin/HEAD)
> Author: Mario Kevo <48509719+mk...@users.noreply.github.com>
> Date: Wed Mar 24 10:25:29 2021 +0100
> GEODE-8962: add an option to escape dollar($) character in the query (#6044)
>
> * GEODE-8962: add an option to escape dollar($) character in the query
> {code}
> Three tests are failing: testSupportedClasses, testUDDS2 and testUDDS4.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
