[jira] [Resolved] (GEODE-9281) No results for the query with multiple indexes used
[
https://issues.apache.org/jira/browse/GEODE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-9281.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> No results for the query with multiple indexes used
> ---
>
> Key: GEODE-9281
> URL: https://issues.apache.org/jira/browse/GEODE-9281
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> While running a basic query which is using 2 indexes, there are no results
> displayed.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.status = 'SUSPENDED' or value.status = 'REGISTERED')"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 29.131016 ms;
> indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
> While using just one index it works correctly.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
> Result : true
> Limit : 100
> Rows : 100
> Query Trace : Query Executed in 15.422983 ms;
> indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
>
> Steps to reproduce the issue:
> # start locator --name=locator1
> # configure pdx --read-serialized=true --disk-store
> # start server --name=server1 --server-port=0
> # start server --name=server2 --server-port=0
> # create region --name=example-region --type=PARTITION_PERSISTENT
> --redundant-copies=1
> # put entries
> # create index --name=ExpiredTimeIndex --expression=value.ExpiredTime
> --region="/example-region.entrySet" --type=range
> # create index --name=StatusIndex --expression=value.Status
> --region="/example-region.entrySet" --type=range
> # query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.Status = 'SUSPENDED' or value.Status = 'REGISTERED')"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9098) Package splitting geode-membership
[ https://issues.apache.org/jira/browse/GEODE-9098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350744#comment-17350744 ] ASF subversion and git services commented on GEODE-9098: Commit 5b0ebb4230af60bf4cfbfebfd2796dd927ba8d9e in geode's branch refs/heads/develop from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5b0ebb4 ] GEODE-9098: Resolve package splitting geode-membership (#6452) * Resolve package splitting geode-membership Co-authored-by: Udo Kohlmeyer Co-authored-by: Patrick Johnson > Package splitting geode-membership > -- > > Key: GEODE-9098 > URL: https://issues.apache.org/jira/browse/GEODE-9098 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9091) Remove Package Splitting
[ https://issues.apache.org/jira/browse/GEODE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9091. -- Fix Version/s: 1.15.0 Resolution: Fixed > Remove Package Splitting > > > Key: GEODE-9091 > URL: https://issues.apache.org/jira/browse/GEODE-9091 > Project: Geode > Issue Type: Improvement >Reporter: Udo Kohlmeyer >Priority: Major > Fix For: 1.15.0 > > > Geode project modules have packages split across them. Splitting packages > across modules is not allowed in Java 9+ and will cause problems when > GEODE-8705 is committed. > This ticket is here to track the removal of package splitting -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9098) Package splitting geode-membership
[ https://issues.apache.org/jira/browse/GEODE-9098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9098. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-membership > -- > > Key: GEODE-9098 > URL: https://issues.apache.org/jira/browse/GEODE-9098 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9098) Package splitting geode-membership
[ https://issues.apache.org/jira/browse/GEODE-9098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9098: -- Labels: pull-request-available (was: ) > Package splitting geode-membership > -- > > Key: GEODE-9098 > URL: https://issues.apache.org/jira/browse/GEODE-9098 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9307) When a server is force disconnected, its regions can still be referenced
[
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350704#comment-17350704
]
ASF subversion and git services commented on GEODE-9307:
Commit 93166a00232eacc9757456f655be2c9c877d77ca in geode's branch
refs/heads/feature/GEODE-9307 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=93166a0 ]
GEODE-9307: Removed MembershipListener after force disconnect
> When a server is force disconnected, its regions can still be referenced
>
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> When a server is force disconnected, any of its DistributedRegions will not
> be GCed after they are closed. This is really only a problem if the
> GemFireCacheImpl is referenced in something other than the
> ClusterDistributionManager.cache field (in my test, I used a static field of
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the
> final field called distAdvisor. The DistributionAdvisor creates a
> MembershipListener and adds it to the ClusterDistributionManager's
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
> getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
> // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not
> removed, so the ClusterDistributionManager references both the
> GemFireCacheImpl and the MembershipListener. The MembershipListener
> references the DistributionAdvisor which references the DistributedRegion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9307) When a server is force disconnected, its regions can still be referenced
[
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9307:
--
Labels: pull-request-available (was: )
> When a server is force disconnected, its regions can still be referenced
>
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> When a server is force disconnected, any of its DistributedRegions will not
> be GCed after they are closed. This is really only a problem if the
> GemFireCacheImpl is referenced in something other than the
> ClusterDistributionManager.cache field (in my test, I used a static field of
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the
> final field called distAdvisor. The DistributionAdvisor creates a
> MembershipListener and adds it to the ClusterDistributionManager's
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
> getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
> // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not
> removed, so the ClusterDistributionManager references both the
> GemFireCacheImpl and the MembershipListener. The MembershipListener
> references the DistributionAdvisor which references the DistributedRegion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9307) When a server is force disconnected, its regions can still be referenced
[
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby reassigned GEODE-9307:
--
Assignee: Barrett Oglesby
> When a server is force disconnected, its regions can still be referenced
>
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>
> When a server is force disconnected, any of its DistributedRegions will not
> be GCed after they are closed. This is really only a problem if the
> GemFireCacheImpl is referenced in something other than the
> ClusterDistributionManager.cache field (in my test, I used a static field of
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the
> final field called distAdvisor. The DistributionAdvisor creates a
> MembershipListener and adds it to the ClusterDistributionManager's
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
> getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
> // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not
> removed, so the ClusterDistributionManager references both the
> GemFireCacheImpl and the MembershipListener. The MembershipListener
> references the DistributionAdvisor which references the DistributedRegion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9307) When a server is force disconnected, its regions can still be referenced
Barrett Oglesby created GEODE-9307:
--
Summary: When a server is force disconnected, its regions can
still be referenced
Key: GEODE-9307
URL: https://issues.apache.org/jira/browse/GEODE-9307
Project: Geode
Issue Type: Bug
Components: regions
Reporter: Barrett Oglesby
When a server is force disconnected, any of its DistributedRegions will not be
GCed after they are closed. This is really only a problem if the
GemFireCacheImpl is referenced in something other than the
ClusterDistributionManager.cache field (in my test, I used a static field of a
Function)
The GemFireCacheImpl references a ClusterDistributionManager in the final field
called dm.
The DistributedRegion creates and references a DistributionAdvisor in the final
field called distAdvisor. The DistributionAdvisor creates a MembershipListener
and adds it to the ClusterDistributionManager's membershipListeners.
When the GemFireCacheImpl is closed due to force disconnect, its regions are
also closed.
When a DistributedRegion is closed, its DistributionAdvisor is also closed.
DistributionAdvisor.close attempts to remove the MembershipListener
{noformat}
try {
getDistributionManager().removeMembershipListener(membershipListener);
} catch (CancelException e) {
// if distribution has stopped, above is a no-op.
} ...
{noformat}
That call fails with a CancelException, and the MembershipListener is not
removed, so the ClusterDistributionManager references both the GemFireCacheImpl
and the MembershipListener. The MembershipListener references the
DistributionAdvisor which references the DistributedRegion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9306) Implement **ZINCRBY**
Hale Bales created GEODE-9306: - Summary: Implement **ZINCRBY** Key: GEODE-9306 URL: https://issues.apache.org/jira/browse/GEODE-9306 Project: Geode Issue Type: Improvement Components: redis Affects Versions: 1.15.0 Reporter: Hale Bales Implement the ZINCRBY Redis command. https://redis.io/commands/zincrby AC Unit and integration tests for ZINCRBY command -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9301) Make RedisHash's measurement of bytes in use more accurate
[ https://issues.apache.org/jira/browse/GEODE-9301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-9301: --- Summary: Make RedisHash's measurement of bytes in use more accurate (was: make RedisHash's measurement of bytes in use more accurate) > Make RedisHash's measurement of bytes in use more accurate > -- > > Key: GEODE-9301 > URL: https://issues.apache.org/jira/browse/GEODE-9301 > Project: Geode > Issue Type: Task > Components: redis >Reporter: Donal Evans >Priority: Major > > RedisHash currently uses constants to help keep track of the size of bytes in > use by that RedisHash. The way that the size increases when members are added > is not constant, and is affected by resizing. It is possible to get the > measurement to be exactly accurate, by dynamically calculating the overhead > based on the current capacity and how many entries there are. > This relates to: > [https://github.com/apache/geode/commit/6a0eba25d5ed5cc7146ce6374d39dd12b22745f3] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9301) Make RedisHash's measurement of bytes in use more accurate
[ https://issues.apache.org/jira/browse/GEODE-9301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-9301: -- Assignee: Donal Evans > Make RedisHash's measurement of bytes in use more accurate > -- > > Key: GEODE-9301 > URL: https://issues.apache.org/jira/browse/GEODE-9301 > Project: Geode > Issue Type: Task > Components: redis >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > RedisHash currently uses constants to help keep track of the size of bytes in > use by that RedisHash. The way that the size increases when members are added > is not constant, and is affected by resizing. It is possible to get the > measurement to be exactly accurate, by dynamically calculating the overhead > based on the current capacity and how many entries there are. > This relates to: > [https://github.com/apache/geode/commit/6a0eba25d5ed5cc7146ce6374d39dd12b22745f3] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9148) expiration may be rescheduled when it is not needed
[ https://issues.apache.org/jira/browse/GEODE-9148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9148: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > expiration may be rescheduled when it is not needed > --- > > Key: GEODE-9148 > URL: https://issues.apache.org/jira/browse/GEODE-9148 > Project: Geode > Issue Type: Improvement > Components: expiration >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Geode expiration is configured with timeouts whose units are seconds. But the > internal implementation uses milliseconds. I noticed recently that for > whatever reason, the Timer was firing scheduled events a few milliseconds > early. This caused the expiration code to reschedule it for just a few > milliseconds and then do all the expiration checking again. It has also been > noticed that last-access-time expiration may find a timestamp on another > member that is just a few milliseconds away from expiration. Once again this > causes a reschedule. > It seems like if the millisecond time is within 500 millis of expiring then > we could go ahead and expire without rescheduling. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9148) expiration may be rescheduled when it is not needed
[ https://issues.apache.org/jira/browse/GEODE-9148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-9148: --- Assignee: Darrel Schneider > expiration may be rescheduled when it is not needed > --- > > Key: GEODE-9148 > URL: https://issues.apache.org/jira/browse/GEODE-9148 > Project: Geode > Issue Type: Improvement > Components: expiration >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > Geode expiration is configured with timeouts whose units are seconds. But the > internal implementation uses milliseconds. I noticed recently that for > whatever reason, the Timer was firing scheduled events a few milliseconds > early. This caused the expiration code to reschedule it for just a few > milliseconds and then do all the expiration checking again. It has also been > noticed that last-access-time expiration may find a timestamp on another > member that is just a few milliseconds away from expiration. Once again this > causes a reschedule. > It seems like if the millisecond time is within 500 millis of expiring then > we could go ahead and expire without rescheduling. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9305) Implement the RESTORE Command
[ https://issues.apache.org/jira/browse/GEODE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9305: - Labels: redis (was: ) > Implement the RESTORE Command > - > > Key: GEODE-9305 > URL: https://issues.apache.org/jira/browse/GEODE-9305 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > Labels: redis > > Implement the [RESTORE|https://redis.io/commands/restore] command. > +Acceptance Criteria+ > The RESTORE command has been implemented per specification and appropriate > unit and integration tests have been written. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9305) Implement the RESTORE Command
[ https://issues.apache.org/jira/browse/GEODE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9305: - Priority: Minor (was: Major) > Implement the RESTORE Command > - > > Key: GEODE-9305 > URL: https://issues.apache.org/jira/browse/GEODE-9305 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Minor > Labels: redis > > Implement the [RESTORE|https://redis.io/commands/restore] command. > +Acceptance Criteria+ > The RESTORE command has been implemented per specification and appropriate > unit and integration tests have been written. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9305) Implement the RESTORE Command
Wayne created GEODE-9305: Summary: Implement the RESTORE Command Key: GEODE-9305 URL: https://issues.apache.org/jira/browse/GEODE-9305 Project: Geode Issue Type: New Feature Components: redis Affects Versions: 1.15.0 Reporter: Wayne Implement the [RESTORE|https://redis.io/commands/restore] command. +Acceptance Criteria+ The RESTORE command has been implemented per specification and appropriate unit and integration tests have been written. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9304) Make RedisSortedSet's measurement of byes in use more accurate
Ray Ingles created GEODE-9304: - Summary: Make RedisSortedSet's measurement of byes in use more accurate Key: GEODE-9304 URL: https://issues.apache.org/jira/browse/GEODE-9304 Project: Geode Issue Type: Bug Components: redis Affects Versions: 1.15.0 Reporter: Ray Ingles The current calculation of bytes in use by RedisSortedSet is inaccurate, and needs to be improved. Once a strategy for size calculation for classes using Object2ObjectCustomHash and OrderStatisticsTree has been decided, it should be implemented for this data type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9281) No results for the query with multiple indexes used
[
https://issues.apache.org/jira/browse/GEODE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350612#comment-17350612
]
ASF subversion and git services commented on GEODE-9281:
Commit 9dfff0c902d6c6017e9b4ad24d512b1927550169 in geode's branch
refs/heads/develop from Mario Kevo
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9dfff0c ]
GEODE-9281: fix printing results for the query when multiple indexes … (#6485)
* GEODE-9281: fix printing results for the query when multiple indexes are used
* add test
* test clean-up
* empty commit to re-launch CI
> No results for the query with multiple indexes used
> ---
>
> Key: GEODE-9281
> URL: https://issues.apache.org/jira/browse/GEODE-9281
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> While running a basic query which is using 2 indexes, there are no results
> displayed.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.status = 'SUSPENDED' or value.status = 'REGISTERED')"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 29.131016 ms;
> indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
> While using just one index it works correctly.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
> Result : true
> Limit : 100
> Rows : 100
> Query Trace : Query Executed in 15.422983 ms;
> indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
>
> Steps to reproduce the issue:
> # start locator --name=locator1
> # configure pdx --read-serialized=true --disk-store
> # start server --name=server1 --server-port=0
> # start server --name=server2 --server-port=0
> # create region --name=example-region --type=PARTITION_PERSISTENT
> --redundant-copies=1
> # put entries
> # create index --name=ExpiredTimeIndex --expression=value.ExpiredTime
> --region="/example-region.entrySet" --type=range
> # create index --name=StatusIndex --expression=value.Status
> --region="/example-region.entrySet" --type=range
> # query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.Status = 'SUSPENDED' or value.Status = 'REGISTERED')"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9281) No results for the query with multiple indexes used
[
https://issues.apache.org/jira/browse/GEODE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350613#comment-17350613
]
ASF subversion and git services commented on GEODE-9281:
Commit 9dfff0c902d6c6017e9b4ad24d512b1927550169 in geode's branch
refs/heads/develop from Mario Kevo
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9dfff0c ]
GEODE-9281: fix printing results for the query when multiple indexes … (#6485)
* GEODE-9281: fix printing results for the query when multiple indexes are used
* add test
* test clean-up
* empty commit to re-launch CI
> No results for the query with multiple indexes used
> ---
>
> Key: GEODE-9281
> URL: https://issues.apache.org/jira/browse/GEODE-9281
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> While running a basic query which is using 2 indexes, there are no results
> displayed.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.status = 'SUSPENDED' or value.status = 'REGISTERED')"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 29.131016 ms;
> indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
> While using just one index it works correctly.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
> Result : true
> Limit : 100
> Rows : 100
> Query Trace : Query Executed in 15.422983 ms;
> indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
>
> Steps to reproduce the issue:
> # start locator --name=locator1
> # configure pdx --read-serialized=true --disk-store
> # start server --name=server1 --server-port=0
> # start server --name=server2 --server-port=0
> # create region --name=example-region --type=PARTITION_PERSISTENT
> --redundant-copies=1
> # put entries
> # create index --name=ExpiredTimeIndex --expression=value.ExpiredTime
> --region="/example-region.entrySet" --type=range
> # create index --name=StatusIndex --expression=value.Status
> --region="/example-region.entrySet" --type=range
> # query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.Status = 'SUSPENDED' or value.Status = 'REGISTERED')"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9303) Implement the DUMP Command
[ https://issues.apache.org/jira/browse/GEODE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9303: - Labels: redis (was: ) > Implement the DUMP Command > -- > > Key: GEODE-9303 > URL: https://issues.apache.org/jira/browse/GEODE-9303 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > Labels: redis > > Implement the [DUMP|https://redis.io/commands/dump] command as compatible > with Redis. > > +Acceptance Criteria+ > The DUMP command has been implemented as specified, with adequate unit and > integration tests. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9303) Implement the DUMP Command
Wayne created GEODE-9303: Summary: Implement the DUMP Command Key: GEODE-9303 URL: https://issues.apache.org/jira/browse/GEODE-9303 Project: Geode Issue Type: New Feature Components: redis Affects Versions: 1.15.0 Reporter: Wayne Implement the [DUMP|https://redis.io/commands/dump] command as compatible with Redis. +Acceptance Criteria+ The DUMP command has been implemented as specified, with adequate unit and integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350600#comment-17350600
]
Geode Integration commented on GEODE-9302:
--
Seen in [Benchmark_base
#234|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/234].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Updated] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9302:
---
Affects Version/s: 1.15.0
Description:
A benchmark failure due to the recently-introduced
PartitionedPutStringBenchmark was observed:
{noformat}
This is ITERATION 1 of benchmarking against baseline.
P2pPartitionedGetBenchmark avg ops/sec
Baseline:853001.60 Test:867151.67 Difference: +1.7%
avg latency
Baseline:842007.55 Test:828545.06 Difference: -1.6%
P2pPartitionedPutBenchmark avg ops/sec
Baseline:128283.47 Test:126510.92 Difference: -1.4%
avg latency
Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
P2pPartitionedPutBytesBenchmark avg ops/sec
Baseline:175658.08 Test:174865.97 Difference: -0.5%
avg latency
Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
PartitionedFunctionExecutionBenchmark avg ops/sec
Baseline:254788.26 Test:268132.99 Difference: +5.2%
avg latency
Baseline:846158.41 Test:804199.42 Difference: -5.0%
PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
Baseline:278669.87 Test:281504.58 Difference: +1.0%
avg latency
Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
Baseline:372204.82 Test:348815.81 Difference: -6.3%
avg latency
Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
PartitionedGetBenchmark avg ops/sec
Baseline:823740.09 Test:819044.99 Difference: -0.6%
avg latency
Baseline:872172.75 Test:877580.02 Difference: +0.6%
PartitionedGetLongBenchmark avg ops/sec
Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
avg latency
Baseline:685757.55 Test:687005.43 Difference: +0.2%
PartitionedGetStringBenchmark avg ops/sec
Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
avg latency
Baseline:680031.44 Test:687045.15 Difference: +1.0%
PartitionedIndexedQueryBenchmark avg ops/sec
Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
avg latency
Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
PartitionedNonIndexedQueryBenchmark avg ops/sec
Baseline:95.78 Test: 100.35 Difference: +4.8%
avg latency
Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
PartitionedPutAllBenchmark avg ops/sec
Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
avg latency
Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
PartitionedPutAllLongBenchmark avg ops/sec
Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
avg latency
Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
PartitionedPutBenchmark avg ops/sec
Baseline:491790.40 Test:479926.75 Difference: -2.4%
avg latency
Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
PartitionedPutBytesBenchmark avg ops/sec
Baseline:472520.77 Test:475046.43 Difference: +0.5%
avg latency
Baseline: 1523521.43 Test: 1515515.20 Difference: -0.5%
PartitionedPutLongBenchmark avg ops/sec
Baseline:412720.03 Test:389975.92 Difference: -5.5%
avg latency
Baseline: 1740407.45 Test: 1842985.87 Difference: +5.9%
PartitionedPutStringBenchmark avg ops/sec
Baseline:430083.15 Test:402523.17 Difference: -6.4%
[jira] [Created] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
Donal Evans created GEODE-9302:
--
Summary: Benchmark instability in PartitionedPutStringBenchmark
Key: GEODE-9302
URL: https://issues.apache.org/jira/browse/GEODE-9302
Project: Geode
Issue Type: Bug
Components: benchmarks
Reporter: Donal Evans
A benchmark failure due to the recently-introduced
PartitionedPutStringBenchmark was observed:
{noformat}
This is ITERATION 1 of benchmarking against baseline.
P2pPartitionedGetBenchmark avg ops/sec
Baseline:853001.60 Test:867151.67 Difference: +1.7%
avg latency
Baseline:842007.55 Test:828545.06 Difference: -1.6%
P2pPartitionedPutBenchmark avg ops/sec
Baseline:128283.47 Test:126510.92 Difference: -1.4%
avg latency
Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
P2pPartitionedPutBytesBenchmark avg ops/sec
Baseline:175658.08 Test:174865.97 Difference: -0.5%
avg latency
Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
PartitionedFunctionExecutionBenchmark avg ops/sec
Baseline:254788.26 Test:268132.99 Difference: +5.2%
avg latency
Baseline:846158.41 Test:804199.42 Difference: -5.0%
PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
Baseline:278669.87 Test:281504.58 Difference: +1.0%
avg latency
Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
Baseline:372204.82 Test:348815.81 Difference: -6.3%
avg latency
Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
PartitionedGetBenchmark avg ops/sec
Baseline:823740.09 Test:819044.99 Difference: -0.6%
avg latency
Baseline:872172.75 Test:877580.02 Difference: +0.6%
PartitionedGetLongBenchmark avg ops/sec
Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
avg latency
Baseline:685757.55 Test:687005.43 Difference: +0.2%
PartitionedGetStringBenchmark avg ops/sec
Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
avg latency
Baseline:680031.44 Test:687045.15 Difference: +1.0%
PartitionedIndexedQueryBenchmark avg ops/sec
Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
avg latency
Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
PartitionedNonIndexedQueryBenchmark avg ops/sec
Baseline:95.78 Test: 100.35 Difference: +4.8%
avg latency
Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
PartitionedPutAllBenchmark avg ops/sec
Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
avg latency
Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
PartitionedPutAllLongBenchmark avg ops/sec
Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
avg latency
Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
PartitionedPutBenchmark avg ops/sec
Baseline:491790.40 Test:479926.75 Difference: -2.4%
avg latency
Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
PartitionedPutBytesBenchmark avg ops/sec
Baseline:472520.77 Test:475046.43 Difference: +0.5%
avg latency
Baseline: 1523521.43 Test: 1515515.20 Difference: -0.5%
PartitionedPutLongBenchmark avg ops/sec
Baseline:412720.03 Test:389975.92 Difference: -5.5%
avg latency
Baseline: 1740407.45 Test: 1842985.87 Difference: +5.9%
[jira] [Created] (GEODE-9301) make RedisHash's measurement of bytes in use more accurate
Donal Evans created GEODE-9301: -- Summary: make RedisHash's measurement of bytes in use more accurate Key: GEODE-9301 URL: https://issues.apache.org/jira/browse/GEODE-9301 Project: Geode Issue Type: Task Components: redis Reporter: Donal Evans RedisHash currently uses constants to help keep track of the size of bytes in use by that RedisHash. The way that the size increases when members are added is not constant, and is affected by resizing. It is possible to get the measurement to be exactly accurate, by dynamically calculating the overhead based on the current capacity and how many entries there are. This relates to: [https://github.com/apache/geode/commit/6a0eba25d5ed5cc7146ce6374d39dd12b22745f3] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9242) CI failure in PutAllClientServerDistributedTest > testEventIdOutOfOrderInPartitionRegionSingleHop
[
https://issues.apache.org/jira/browse/GEODE-9242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-9242:
Assignee: Kirk Lund
> CI failure in PutAllClientServerDistributedTest >
> testEventIdOutOfOrderInPartitionRegionSingleHop
> -
>
> Key: GEODE-9242
> URL: https://issues.apache.org/jira/browse/GEODE-9242
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Assignee: Kirk Lund
>Priority: Major
> Labels: release-blocker
>
> CI failure artifacts here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/214]
>
> Stack trace as follows:
>
> {code:java}
> > Task :geode-cq:distributedTest
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest >
> testEventIdOutOfOrderInPartitionRegionSingleHop FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$365/1949439489.run
> in VM 2 running on Host 1cd9d0b3a09e with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testEventIdOutOfOrderInPartitionRegionSingleHop(PutAllClientServerDistributedTest.java:2547)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined
> as a lambda expression in
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest that uses
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$Counter
> expected:<[100]> but was:<[91]> within 5 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$testEventIdOutOfOrderInPartitionRegionSingleHop$46f2d07$1(PutAllClientServerDistributedTest.java:2548)
> Caused by:
> org.junit.ComparisonFailure: expected:<[100]> but was:<[91]>
> at sun.reflect.GeneratedConstructorAccessor43.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$null$86(PutAllClientServerDistributedTest.java:2548)
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9103) CI Failure: PutAllClientServerDistributedTest.testPutAllReturnsExceptions FAILED
[
https://issues.apache.org/jira/browse/GEODE-9103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-9103:
Assignee: Kirk Lund
> CI Failure: PutAllClientServerDistributedTest.testPutAllReturnsExceptions
> FAILED
>
>
> Key: GEODE-9103
> URL: https://issues.apache.org/jira/browse/GEODE-9103
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest >
> testPutAllReturnsExceptions FAILED
> 17:13:44org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$613/835527630.run
> in VM 2 running on Host de2767658753 with 4 VMs
> 17:13:44at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 17:13:44at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 17:13:44at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPutAllReturnsExceptions(PutAllClientServerDistributedTest.java:1956)
> 17:13:44
> 17:13:44Caused by:
> 17:13:44java.lang.AssertionError:
> 17:13:44Expecting actual throwable to be an instance of:
> 17:13:44 org.apache.geode.cache.client.ServerOperationException
> 17:13:44but was:
> 17:13:44 org.apache.geode.cache.client.ServerConnectivityException:
> Pool unexpected closed socket on server connection=Pooled Connection to
> de2767658753:36547,172.17.0.10(245):41001: Connection[DESTROYED]).
> Server unreachable: could not connect after 1 attempts
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:665)
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:507)
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:157)
> 17:13:44 ...(35 remaining lines not displayed - this can be
> changed with Assertions.setMaxStackTraceElementsDisplayed)
> 17:13:44at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$testPutAllReturnsExceptions$bb17a952$6(PutAllClientServerDistributedTest.java:1961)
> 17:16 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9253) Add unit tests for NullRedis* Classes
[ https://issues.apache.org/jira/browse/GEODE-9253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9253. Resolution: Won't Fix To keep in line with the integration test-focused testing strategy in the geode-apis-compatible-with-redis module, unit tests won't be added for these classes, as the behaviour in them is already tested at the integration level. > Add unit tests for NullRedis* Classes > - > > Key: GEODE-9253 > URL: https://issues.apache.org/jira/browse/GEODE-9253 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.14.0, 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: redis > > NullRedisString, NullRedisSet and NullRedisHash have no unit test coverage > for their methods. Unit tests should be written to validate the behaviour of > the methods in the classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9300) write-buffer-size parameter not used when creating disk store
Alberto Gomez created GEODE-9300: Summary: write-buffer-size parameter not used when creating disk store Key: GEODE-9300 URL: https://issues.apache.org/jira/browse/GEODE-9300 Project: Geode Issue Type: Bug Components: core Reporter: Alberto Gomez According to the Geode documentation, it is possible to set the write buffer size by using --write-buffer-size when creating a disk store ([https://geode.apache.org/docs/guide/113/tools_modules/gfsh/command-pages/create.html]). Nevertheless, setting a value for that parameter either by using gfsh, cache.xml or the DiskStoreFactory.setWriteBuffer() method has no effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9299) CI Failure: WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
[
https://issues.apache.org/jira/browse/GEODE-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350556#comment-17350556
]
Hale Bales commented on GEODE-9299:
---
[~burcham] it is not due to membership, I just had it identified incorrectly.
removed the label
> CI Failure:
> WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover >
> testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> --
>
> Key: GEODE-9299
> URL: https://issues.apache.org/jira/browse/GEODE-9299
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from_v1.12.2]
> FAILED
> java.lang.AssertionError: expected:<100> but was:<101>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.stopSenderAndVerifyEvents(WANRollingUpgradeDUnitTest.java:227)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover(WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.java:98)
> {code}
> CI Failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/229#B
> Artifacts Available here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0253/test-results/upgradeTest/1621635640/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9299) CI Failure: WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
[
https://issues.apache.org/jira/browse/GEODE-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350553#comment-17350553
]
Bill Burcham commented on GEODE-9299:
-
The test in question isn't actually doing any rolling upgrade. It establishes
WAN replication and then shuts down a member with a sender and verifies that
another member takes over the sender responsibilities.
I'm removing the membership component label from this ticket. We can add that
back in if someone develops a theory of a membership bug.
> CI Failure:
> WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover >
> testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> --
>
> Key: GEODE-9299
> URL: https://issues.apache.org/jira/browse/GEODE-9299
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from_v1.12.2]
> FAILED
> java.lang.AssertionError: expected:<100> but was:<101>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.stopSenderAndVerifyEvents(WANRollingUpgradeDUnitTest.java:227)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover(WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.java:98)
> {code}
> CI Failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/229#B
> Artifacts Available here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0253/test-results/upgradeTest/1621635640/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9299) CI Failure: WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
[
https://issues.apache.org/jira/browse/GEODE-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-9299:
--
Component/s: (was: membership)
> CI Failure:
> WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover >
> testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> --
>
> Key: GEODE-9299
> URL: https://issues.apache.org/jira/browse/GEODE-9299
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from_v1.12.2]
> FAILED
> java.lang.AssertionError: expected:<100> but was:<101>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.stopSenderAndVerifyEvents(WANRollingUpgradeDUnitTest.java:227)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover(WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.java:98)
> {code}
> CI Failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/229#B
> Artifacts Available here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0253/test-results/upgradeTest/1621635640/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9296) CI Failure: PutAllClientServerDistributedTest > testPartialKeyInPRSingleHopWithRedundancy
[ https://issues.apache.org/jira/browse/GEODE-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-9296: - Labels: GeodeOperationAPI (was: ) > CI Failure: PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHopWithRedundancy > - > > Key: GEODE-9296 > URL: https://issues.apache.org/jira/browse/GEODE-9296 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.15.0 >Reporter: Hale Bales >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI > > org.apache.geode.internal.cache.PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHopWithRedundancy FAILED > org.junit.ComparisonFailure: expected:<[20]0> but was:<[17]0> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPartialKeyInPRSingleHopWithRedundancy(PutAllClientServerDistributedTest.java:2430) > failed in CI run: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253#B > artifacts available here: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0251/test-results/distributedTest/1621568801/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9296) CI Failure: PutAllClientServerDistributedTest > testPartialKeyInPRSingleHopWithRedundancy
[ https://issues.apache.org/jira/browse/GEODE-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-9296: Assignee: Kirk Lund (was: Anilkumar Gingade) > CI Failure: PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHopWithRedundancy > - > > Key: GEODE-9296 > URL: https://issues.apache.org/jira/browse/GEODE-9296 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.15.0 >Reporter: Hale Bales >Assignee: Kirk Lund >Priority: Major > > org.apache.geode.internal.cache.PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHopWithRedundancy FAILED > org.junit.ComparisonFailure: expected:<[20]0> but was:<[17]0> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPartialKeyInPRSingleHopWithRedundancy(PutAllClientServerDistributedTest.java:2430) > failed in CI run: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253#B > artifacts available here: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0251/test-results/distributedTest/1621568801/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9299) CI Failure: WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
[
https://issues.apache.org/jira/browse/GEODE-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350524#comment-17350524
]
Bill Burcham commented on GEODE-9299:
-
Does someone have a theory about why this failure is due to a membership bug
[~balesh2]?
> CI Failure:
> WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover >
> testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> --
>
> Key: GEODE-9299
> URL: https://issues.apache.org/jira/browse/GEODE-9299
> Project: Geode
> Issue Type: Bug
> Components: membership, wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from_v1.12.2]
> FAILED
> java.lang.AssertionError: expected:<100> but was:<101>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.stopSenderAndVerifyEvents(WANRollingUpgradeDUnitTest.java:227)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover(WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.java:98)
> {code}
> CI Failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/229#B
> Artifacts Available here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0253/test-results/upgradeTest/1621635640/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9294) Final review of Radish docs
[ https://issues.apache.org/jira/browse/GEODE-9294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales updated GEODE-9294: -- Labels: blocks-1.14.0 pull-request-available redis (was: pull-request-available) > Final review of Radish docs > --- > > Key: GEODE-9294 > URL: https://issues.apache.org/jira/browse/GEODE-9294 > Project: Geode > Issue Type: Improvement > Components: docs, redis >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available, redis > > *AC* > - Docs for compatibility-with-Redis have been checked for errors and > inconsistencies > - (note: be aware of places in README where usage of "apis vs api" is the > docs-blessed form-- should be plural) > - (note: check for functionality of links in README) > - do we want to remove lines from the README?: > #- "The Geode APIs compatible with Redis currently implement a subset of > the full Redis command set." > #- Commands not listed above are not implemented. (this is at the end of > the Supported Commands section) > #- Note: These commands are supported for Redis 5. (at the beginning of > the Supported Commands section) -- 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&focusedCommentId=17350519#comment-17350519 ] Dave Barnes commented on GEODE-9042: There's been another update – bookbinder 1.10.17 contains some additional dependency updates and should be available in rubygems. > 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 >Assignee: Alberto Bustamante Reyes >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] [Updated] (GEODE-9252) CI failure: NativeRedisClusterTestRule incorrect primary node count (expected 3 but was 2)
[
https://issues.apache.org/jira/browse/GEODE-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9252:
---
Summary: CI failure: NativeRedisClusterTestRule incorrect primary node
count (expected 3 but was 2) (was: CI failure: HashesNativeRedisAcceptanceTest
> classMethod FAILED)
> CI failure: NativeRedisClusterTestRule incorrect primary node count (expected
> 3 but was 2)
> --
>
> Key: GEODE-9252
> URL: https://issues.apache.org/jira/browse/GEODE-9252
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Owen Nichols
>Priority: Major
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HashesNativeRedisAcceptanceTest
> > classMethod FAILED
> org.junit.ComparisonFailure: [Incorrect primary node count]
> expected:<[3]> but was:<[2]>
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:93)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9252) CI failure: NativeRedisClusterTestRule incorrect primary node count (expected 3 but was 2)
[
https://issues.apache.org/jira/browse/GEODE-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350516#comment-17350516
]
Geode Integration commented on GEODE-9252:
--
Seen in [AcceptanceTestOpenJDK11
#231|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/231]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0257/test-results/acceptanceTest/1621862107/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0257/test-artifacts/1621862107/acceptancetestfiles-OpenJDK11-1.15.0-build.0257.tgz].
> CI failure: NativeRedisClusterTestRule incorrect primary node count (expected
> 3 but was 2)
> --
>
> Key: GEODE-9252
> URL: https://issues.apache.org/jira/browse/GEODE-9252
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Owen Nichols
>Priority: Major
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HashesNativeRedisAcceptanceTest
> > classMethod FAILED
> org.junit.ComparisonFailure: [Incorrect primary node count]
> expected:<[3]> but was:<[2]>
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:93)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-9191) PR clear could miss clearing bucket which lost primary
[ https://issues.apache.org/jira/browse/GEODE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339313#comment-17339313 ] Xiaojian Zhou edited comment on GEODE-9191 at 5/24/21, 4:29 PM: More investigation found that the primary buckets could switch at any time especially when they are not balanced (usually happened in GII). We need to lock the primary from moving. The revised design will be: (1) coordinator(a server) assignAllBuckets. (2) coordinator lock local primary buckets and sends lock message to all peer members. (3) upon received the lock message, each datastore server will: - lockBucketCreationForRegionClear (Maybe we don't need it) - waits for all the primaries to show up - iterate through local primary bucket list to lock primary from moving, then lock RVV - reply with number of buckets locked (4) coordinator collected locked bucket numbers from each member, if matched the expected total bucket number (i.e. default is 113), move on to next step. Otherwise, retry. - It's possible while iterating through the local primary bucket list, some of the primary bucket is no longer primary, in this case, the sum of locked primary bucket numbers that collected by the coordinator could be different with the expected total bucket number. Then coordinator will unlock all the members and retry. - Retry until succeed or failed with PartialClearException. Retry will usually succeed, unless there're too many servers shutdown. In that case, waitForPrimary will fail with PartialClearException and break the endless retry. (5) If a member is down, the membership listener will detected and let coordinator to retry. If too many members are down, wait for primary should fail with PartitionedRegionPartialClearException. Then coordinator will unlock and throw this exception to caller. If the coordinator is down, the pr clear will fail. Note: membership listener will trigger coordinator to retry from beginning, not to let each member to retry locally, because the primary list might have changed. (6) After locked all the members' primary buckets (both locked primary and locked RVV), the coordinator sends clear message to all the members. (7) each member clear primary buckets one by one and return number of buckets cleared. (8) Coordinator collect all the numbers cleared, if less than expected bucket number, retry. This could happen when a member is offline in the middle of clear. The retry should succeed finally unless too many servers are down. Then the waitForPrimary will throw PartialClearException. (9) In unlock, the coordinator should send UNLOCK message to all the members to unlock not only primary buckets, because the primary list at each member could have been changed. - should iterate through all the local buckets and unlock RVV, then unlock primary moving. - getLockRequester()==null means coordinator is down. In that case, we should still do unlock. - Since the PR clear will retry forever until succeeded or fail with ParticlalClearException due to too many members are down, there's no need to lockBucketCreationForRegionClear. was (Author: zhouxj): More investigation found that the primary buckets could switch at any time especially when they are not balanced (usually happened in GII). We need to lock the primary from moving. The revised design will be: (1) coordinator(a server) assignAllBuckets. (2) coordinator lock local primary buckets and sends lock message to all peer members. (3) upon received the lock message, each datastore server will: - lockBucketCreationForRegionClear (Maybe we don't need it) - waits for all the primaries to show up - iterate through local primary bucket list to lock primary from moving, then lock RVV - reply with number of buckets locked (4) coordinator collected locked bucket numbers from each member, if matched the expected total bucket number (i.e. default is 113), move on to next step. Otherwise, retry. - It's possible while iterating through the local primary bucket list, some of the primary bucket is no longer primary, in this case, the sum of locked primary bucket numbers that collected by the coordinator could be different with the expected total bucket number. Then coordinator will unlock all the members and retry. - Retry until succeed or failed with PartialClearException. Retry will usually succeed, unless there're too many servers shutdown. In that case, waitForPrimary will fail with PartialClearException and break the endless retry. (5) If a member is down, the membership listener will detected and let coordinator to retry. If too many members are down, wait for primary should fail with PartitionedRegionPartialClearException. Then coordinator will unlock and throw this exception to caller. If the coordinator is down, the pr clear will fail. (6) After locked all the member
[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&focusedCommentId=17350464#comment-17350464 ] Alberto Bustamante Reyes commented on GEODE-9042: - Thanks Dave, I will continue with this ticket then > 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 >Assignee: Alberto Bustamante Reyes >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] [Comment Edited] (GEODE-9288) DeployedJarTest fails because JavaCompiler.compile() fails to delete temporaryClassesDirectory
[
https://issues.apache.org/jira/browse/GEODE-9288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350343#comment-17350343
]
Alberto Bustamante Reyes edited comment on GEODE-9288 at 5/24/21, 10:51 AM:
Lets see if after changing to "Files.createTempDirectory()" this issue is not
reproduced again
was (Author: alberto.bustamante.reyes):
Lets see if after changing to "Files.createTempDirectory()" this issue is
reproduced again
> DeployedJarTest fails because JavaCompiler.compile() fails to delete
> temporaryClassesDirectory
> --
>
> Key: GEODE-9288
> URL: https://issues.apache.org/jira/browse/GEODE-9288
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> DeployedJarTest.throwsIfFileIsNotValidJarFile() test failed in Windows CI
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/225
> The problem did not reproduce on macOS in 1000 runs.
> I notice that the JavaCompiler constructor calls the deprecated
> Files.createTempDir(). I wonder if there might be a race condition where two
> test processes (at once) think they own that temp dir and so they can both
> delete it.
> We might consider replacing that deprecated call with the recommended
> Files.createTempDirectory() which may be more robust. Looking at the
> deprecated method and the recommended substitute the latter might have less
> of a chance of collision due to its use of random suffixes (versus the
> former's monotonically-increasing ints).
> {code:java}
> org.apache.geode.deployment.internal.DeployedJarTest >
> throwsIfFileIsNotValidJarFile FAILED
> java.io.IOException: Unable to delete directory
> C:\Users\geode\AppData\Local\Temp\1621373797371-0\classes.
> at
> org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1212)
> at
> org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:90)
> at
> org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:79)
> at
> org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82)
> at
> org.apache.geode.deployment.internal.DeployedJarTest.throwsIfFileIsNotValidJarFile(DeployedJarTest.java:47)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9288) DeployedJarTest fails because JavaCompiler.compile() fails to delete temporaryClassesDirectory
[
https://issues.apache.org/jira/browse/GEODE-9288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes resolved GEODE-9288.
-
Fix Version/s: 1.15.0
Resolution: Fixed
Lets see if after changing to "Files.createTempDirectory()" this issue is
reproduced again
> DeployedJarTest fails because JavaCompiler.compile() fails to delete
> temporaryClassesDirectory
> --
>
> Key: GEODE-9288
> URL: https://issues.apache.org/jira/browse/GEODE-9288
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> DeployedJarTest.throwsIfFileIsNotValidJarFile() test failed in Windows CI
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/225
> The problem did not reproduce on macOS in 1000 runs.
> I notice that the JavaCompiler constructor calls the deprecated
> Files.createTempDir(). I wonder if there might be a race condition where two
> test processes (at once) think they own that temp dir and so they can both
> delete it.
> We might consider replacing that deprecated call with the recommended
> Files.createTempDirectory() which may be more robust. Looking at the
> deprecated method and the recommended substitute the latter might have less
> of a chance of collision due to its use of random suffixes (versus the
> former's monotonically-increasing ints).
> {code:java}
> org.apache.geode.deployment.internal.DeployedJarTest >
> throwsIfFileIsNotValidJarFile FAILED
> java.io.IOException: Unable to delete directory
> C:\Users\geode\AppData\Local\Temp\1621373797371-0\classes.
> at
> org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1212)
> at
> org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:90)
> at
> org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:79)
> at
> org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82)
> at
> org.apache.geode.deployment.internal.DeployedJarTest.throwsIfFileIsNotValidJarFile(DeployedJarTest.java:47)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9288) DeployedJarTest fails because JavaCompiler.compile() fails to delete temporaryClassesDirectory
[
https://issues.apache.org/jira/browse/GEODE-9288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350342#comment-17350342
]
ASF subversion and git services commented on GEODE-9288:
Commit 6702402a98de98c61b71d9d017c863dc659acf0c in geode's branch
refs/heads/develop from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6702402 ]
GEODE-9288: DeployedJarTest fails because JavaCompiler fails to delete temp dir
(#6501)
> DeployedJarTest fails because JavaCompiler.compile() fails to delete
> temporaryClassesDirectory
> --
>
> Key: GEODE-9288
> URL: https://issues.apache.org/jira/browse/GEODE-9288
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> DeployedJarTest.throwsIfFileIsNotValidJarFile() test failed in Windows CI
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/225
> The problem did not reproduce on macOS in 1000 runs.
> I notice that the JavaCompiler constructor calls the deprecated
> Files.createTempDir(). I wonder if there might be a race condition where two
> test processes (at once) think they own that temp dir and so they can both
> delete it.
> We might consider replacing that deprecated call with the recommended
> Files.createTempDirectory() which may be more robust. Looking at the
> deprecated method and the recommended substitute the latter might have less
> of a chance of collision due to its use of random suffixes (versus the
> former's monotonically-increasing ints).
> {code:java}
> org.apache.geode.deployment.internal.DeployedJarTest >
> throwsIfFileIsNotValidJarFile FAILED
> java.io.IOException: Unable to delete directory
> C:\Users\geode\AppData\Local\Temp\1621373797371-0\classes.
> at
> org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1212)
> at
> org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:90)
> at
> org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:79)
> at
> org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82)
> at
> org.apache.geode.deployment.internal.DeployedJarTest.throwsIfFileIsNotValidJarFile(DeployedJarTest.java:47)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivanac updated GEODE-8191:
Fix Version/s: 1.15.0
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.15.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivanac resolved GEODE-8191.
-
Resolution: Fixed
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350319#comment-17350319
]
ASF subversion and git services commented on GEODE-8191:
Commit 6c1e3d700e1a075bff08b2f81f88387c8a05e489 in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6c1e3d7 ]
GEODE-8191: update flaky test (#6427)
* GEODE-8191: solution for failing test
* GEODE-8191: update after comments
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350318#comment-17350318
]
ASF subversion and git services commented on GEODE-8191:
Commit 6c1e3d700e1a075bff08b2f81f88387c8a05e489 in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6c1e3d7 ]
GEODE-8191: update flaky test (#6427)
* GEODE-8191: solution for failing test
* GEODE-8191: update after comments
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350317#comment-17350317
]
ASF subversion and git services commented on GEODE-8191:
Commit 6c1e3d700e1a075bff08b2f81f88387c8a05e489 in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6c1e3d7 ]
GEODE-8191: update flaky test (#6427)
* GEODE-8191: solution for failing test
* GEODE-8191: update after comments
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
