[jira] [Commented] (GEODE-7772) Simplify hasNext in PageableLuceneQueryResultsImpl
[
https://issues.apache.org/jira/browse/GEODE-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032278#comment-17032278
]
ASF subversion and git services commented on GEODE-7772:
Commit 93aa3c4668f888e62d7951c1712c179955b6d01b in geode's branch
refs/heads/develop from mkevo
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=93aa3c4 ]
GEODE-7772: Simplify hasNext in PageableLuceneQueryResultsImpl (#4678)
> Simplify hasNext in PageableLuceneQueryResultsImpl
> --
>
> Key: GEODE-7772
> URL: https://issues.apache.org/jira/browse/GEODE-7772
> Project: Geode
> Issue Type: Task
> Components: lucene
>Reporter: Jason Huynh
>Assignee: Mario Kevo
>Priority: Major
> Labels: beginner, newb, starter
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The if statement in the hasNext() method can be simplified by condensing into
> a single line return statement.
> See here:
> [https://github.com/apache/geode/blob/182de42d8e56a900f0d22793a440af72f62f09f4/geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/PageableLuceneQueryResultsImpl.java#L149]
>
> Example, and possibly correct fix:
> {code:java}
> return !currentPage.isEmpty();{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7772) Simplify hasNext in PageableLuceneQueryResultsImpl
[
https://issues.apache.org/jira/browse/GEODE-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-7772.
---
Fix Version/s: 1.13.0
Resolution: Fixed
> Simplify hasNext in PageableLuceneQueryResultsImpl
> --
>
> Key: GEODE-7772
> URL: https://issues.apache.org/jira/browse/GEODE-7772
> Project: Geode
> Issue Type: Task
> Components: lucene
>Reporter: Jason Huynh
>Assignee: Mario Kevo
>Priority: Major
> Labels: beginner, newb, starter
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The if statement in the hasNext() method can be simplified by condensing into
> a single line return statement.
> See here:
> [https://github.com/apache/geode/blob/182de42d8e56a900f0d22793a440af72f62f09f4/geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/PageableLuceneQueryResultsImpl.java#L149]
>
> Example, and possibly correct fix:
> {code:java}
> return !currentPage.isEmpty();{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7717) ClusterManagementListResult should contain a list ConfigurationInfo (config per id)
[ https://issues.apache.org/jira/browse/GEODE-7717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032515#comment-17032515 ] ASF subversion and git services commented on GEODE-7717: Commit bda6bdf50c0a6a3e7cc39fb3ff654a0c26c86d94 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bda6bdf ] GEODE-7717: ClusterManagementListResult should show a list of EntityInfo (#4673) * only show links in the EntityInfo level * rework list member responses > ClusterManagementListResult should contain a list ConfigurationInfo (config > per id) > --- > > Key: GEODE-7717 > URL: https://issues.apache.org/jira/browse/GEODE-7717 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Priority: Major > Labels: tech-debt, technical_debt > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently ClusterManagementListResult contains a list > ConfigurationResult(config per group), those configs are not grouped by id, > so a region that belongs to multiple groups might be dispersed in the list. > Since ClsuterManagementGetResult contains a single ConfigurationInfo, it > seems to make sense to have the ListResult contains a list of > ConfigurationInfo. > Also, after the ClusterManagementListResult contains the list grouped by id, > it would be good for us to display "links" in the ConfigurationInfo level > instead of ConfigurationResult level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7760) NPE in reconnecting Locator
[
https://issues.apache.org/jira/browse/GEODE-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032523#comment-17032523
]
ASF subversion and git services commented on GEODE-7760:
Commit af8307243e3c8dfb4f0c03b4539eace0b3ea11b3 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=af83072 ]
GEODE-7760: NPE in Locator during auto-reconnect (#4668)
* GEODE-7760: NPE in Locator during auto-reconnect
* empty commit
* fixes for stress-testing
* working on another stresstest failure
This test passes all the time outside of stress testing
* ignoring test that seems to have trouble with workingDir/configDir and
temporary folders in stress testing
* remove use of static locator variable in InternalLocator. added crash test.
unset shutdownHandled after locator restarts
* fixing stresstest issues
> NPE in reconnecting Locator
> ---
>
> Key: GEODE-7760
> URL: https://issues.apache.org/jira/browse/GEODE-7760
> Project: Geode
> Issue Type: Bug
> Components: management, membership
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A v1.9 locator was forced out of the cluster and then threw an NPE when it
> was reconnecting. Apparently the new DistributedSystem was also kicked out
> of the cluster during this time.
> {noformat}
> [fatal 2019/12/18 02:14:55.647 UTC
> tid=0xb1a5] Uncaught exception in thread Thread[Location services restart
> thread,5,main]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:690)
> at
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalLocator.java:1124)
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1062)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$1(InternalLocator.java:983)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This wasn't from a CI run and there are no other artifacts available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7760) NPE in reconnecting Locator
[
https://issues.apache.org/jira/browse/GEODE-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032522#comment-17032522
]
ASF subversion and git services commented on GEODE-7760:
Commit af8307243e3c8dfb4f0c03b4539eace0b3ea11b3 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=af83072 ]
GEODE-7760: NPE in Locator during auto-reconnect (#4668)
* GEODE-7760: NPE in Locator during auto-reconnect
* empty commit
* fixes for stress-testing
* working on another stresstest failure
This test passes all the time outside of stress testing
* ignoring test that seems to have trouble with workingDir/configDir and
temporary folders in stress testing
* remove use of static locator variable in InternalLocator. added crash test.
unset shutdownHandled after locator restarts
* fixing stresstest issues
> NPE in reconnecting Locator
> ---
>
> Key: GEODE-7760
> URL: https://issues.apache.org/jira/browse/GEODE-7760
> Project: Geode
> Issue Type: Bug
> Components: management, membership
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A v1.9 locator was forced out of the cluster and then threw an NPE when it
> was reconnecting. Apparently the new DistributedSystem was also kicked out
> of the cluster during this time.
> {noformat}
> [fatal 2019/12/18 02:14:55.647 UTC
> tid=0xb1a5] Uncaught exception in thread Thread[Location services restart
> thread,5,main]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:690)
> at
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalLocator.java:1124)
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1062)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$1(InternalLocator.java:983)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This wasn't from a CI run and there are no other artifacts available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7760) NPE in reconnecting Locator
[
https://issues.apache.org/jira/browse/GEODE-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-7760.
---
Fix Version/s: 1.12.0
Resolution: Fixed
> NPE in reconnecting Locator
> ---
>
> Key: GEODE-7760
> URL: https://issues.apache.org/jira/browse/GEODE-7760
> Project: Geode
> Issue Type: Bug
> Components: management, membership
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A v1.9 locator was forced out of the cluster and then threw an NPE when it
> was reconnecting. Apparently the new DistributedSystem was also kicked out
> of the cluster during this time.
> {noformat}
> [fatal 2019/12/18 02:14:55.647 UTC
> tid=0xb1a5] Uncaught exception in thread Thread[Location services restart
> thread,5,main]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:690)
> at
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalLocator.java:1124)
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1062)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$1(InternalLocator.java:983)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This wasn't from a CI run and there are no other artifacts available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7760) NPE in reconnecting Locator
[
https://issues.apache.org/jira/browse/GEODE-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032553#comment-17032553
]
ASF subversion and git services commented on GEODE-7760:
Commit 26194ea332e5140812c6660ec6487eff5f9606a3 in geode's branch
refs/heads/release/1.12.0 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=26194ea ]
GEODE-7760: NPE in Locator during auto-reconnect (#4668)
* GEODE-7760: NPE in Locator during auto-reconnect
* empty commit
* fixes for stress-testing
* working on another stresstest failure
This test passes all the time outside of stress testing
* ignoring test that seems to have trouble with workingDir/configDir and
temporary folders in stress testing
* remove use of static locator variable in InternalLocator. added crash test.
unset shutdownHandled after locator restarts
* fixing stresstest issues
(cherry picked from commit af8307243e3c8dfb4f0c03b4539eace0b3ea11b3)
> NPE in reconnecting Locator
> ---
>
> Key: GEODE-7760
> URL: https://issues.apache.org/jira/browse/GEODE-7760
> Project: Geode
> Issue Type: Bug
> Components: management, membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A v1.9 locator was forced out of the cluster and then threw an NPE when it
> was reconnecting. Apparently the new DistributedSystem was also kicked out
> of the cluster during this time.
> {noformat}
> [fatal 2019/12/18 02:14:55.647 UTC
> tid=0xb1a5] Uncaught exception in thread Thread[Location services restart
> thread,5,main]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:690)
> at
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalLocator.java:1124)
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1062)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$1(InternalLocator.java:983)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This wasn't from a CI run and there are no other artifacts available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7760) NPE in reconnecting Locator
[
https://issues.apache.org/jira/browse/GEODE-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032554#comment-17032554
]
ASF subversion and git services commented on GEODE-7760:
Commit 26194ea332e5140812c6660ec6487eff5f9606a3 in geode's branch
refs/heads/release/1.12.0 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=26194ea ]
GEODE-7760: NPE in Locator during auto-reconnect (#4668)
* GEODE-7760: NPE in Locator during auto-reconnect
* empty commit
* fixes for stress-testing
* working on another stresstest failure
This test passes all the time outside of stress testing
* ignoring test that seems to have trouble with workingDir/configDir and
temporary folders in stress testing
* remove use of static locator variable in InternalLocator. added crash test.
unset shutdownHandled after locator restarts
* fixing stresstest issues
(cherry picked from commit af8307243e3c8dfb4f0c03b4539eace0b3ea11b3)
> NPE in reconnecting Locator
> ---
>
> Key: GEODE-7760
> URL: https://issues.apache.org/jira/browse/GEODE-7760
> Project: Geode
> Issue Type: Bug
> Components: management, membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A v1.9 locator was forced out of the cluster and then threw an NPE when it
> was reconnecting. Apparently the new DistributedSystem was also kicked out
> of the cluster during this time.
> {noformat}
> [fatal 2019/12/18 02:14:55.647 UTC
> tid=0xb1a5] Uncaught exception in thread Thread[Location services restart
> thread,5,main]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:690)
> at
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalLocator.java:1124)
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1062)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$1(InternalLocator.java:983)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This wasn't from a CI run and there are no other artifacts available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7740) Refactor and combine create_instances.sh for all Geode projects
[ https://issues.apache.org/jira/browse/GEODE-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-7740. - Fix Version/s: 1.12.0 Resolution: Fixed > Refactor and combine create_instances.sh for all Geode projects > --- > > Key: GEODE-7740 > URL: https://issues.apache.org/jira/browse/GEODE-7740 > Project: Geode > Issue Type: Improvement > Components: build, ci >Reporter: Robert Houghton >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Geode and geode-native-client both maintain their own GCE instance creation > scripts for Concourse CI. Combining them will lead to fewer issues as the GCE > APIs move forward, and lighten the load on maintainers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7750) If a member is force disconnected from the distributed system repeatedly, it reconnects each time, but after the second force disconnect, it shuts down after reconnectin
[
https://issues.apache.org/jira/browse/GEODE-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-7750.
-
Fix Version/s: 1.12.0
Resolution: Fixed
fixed as part of GEODE-7760
> If a member is force disconnected from the distributed system repeatedly, it
> reconnects each time, but after the second force disconnect, it shuts down
> after reconnecting
> --
>
> Key: GEODE-7750
> URL: https://issues.apache.org/jira/browse/GEODE-7750
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.11.0
>Reporter: Barry Oglesby
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.12.0
>
>
> If I start a server using gfsh and repeatedly invoke the
> MembershipManagerHelper crashDistributedSystem method to force it to
> disconnect from the distributed system, it reconnects each time, but after
> the second force disconnect, the server shuts down after reconnecting.
> Here is truncated logging for the first disconnect:
> {noformat}
> [info 2020/01/29 11:41:07.613 PST tid=0x44]
> crashing distributed system: Connected "server1" (id=76d0ecd7) to distributed
> system using locators "localhost[23456]" logging to cacheserver.log started
> at Wed Jan 29 11:32:37 PST 2020
> [info 2020/01/29 11:41:07.613 PST tid=0x44]
> GroupMembershipService.beSick invoked for
> 192.168.99.1(server1:51825):41001 - simulating sickness
> [info 2020/01/29 11:41:07.613 PST tid=0x44]
> GroupMembershipService.playDead invoked for
> 192.168.99.1(server1:51825):41001
> [fatal 2020/01/29 11:41:07.613 PST tid=0x44]
> Membership service failure: for testing
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> for testing
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2004)
> at
> org.apache.geode.distributed.internal.membership.api.MembershipManagerHelper.crashDistributedSystem(MembershipManagerHelper.java:66)
> at
> MembershipCycleHealthFunction.execute(MembershipCycleHealthFunction.java:20)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:328)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.lambda$executeFunctionOnLocalNode$1(AbstractExecution.java:299)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:449)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.lang.Thread.run(Thread.java:745)
> [info 2020/01/29 11:41:07.616 PST tid=0x44]
> CacheServer configuration saved
> [info 2020/01/29 11:41:07.626 PST
> tid=0x1f] GMSHealthMonitor server thread exiting
> [info 2020/01/29 11:41:07.626 PST tid=0x47] Stopping
> membership services
> [info 2020/01/29 11:41:07.630 PST tid=0x47] Disconnecting
> old DistributedSystem to prepare for a reconnect attempt
> [info 2020/01/29 11:41:07.632 PST tid=0x47] GemFireCache[id
> = 101500074; isClosing = true; isShutDownAll = false; created = Wed Jan 29
> 11:32:38 PST 2020; server = true; copyOnRead = false; lockLease = 120;
> lockTimeout = 60]: Now closing.
> [info 2020/01/29 11:41:07.633 PST tid=0x47] Cache server on
> port 40401 is shutting down.
> [info 2020/01/29 11:41:07.657 PST tid=0x47] Shutting down
> DistributionManager 192.168.99.1(server1:51825):41001. At least one
> Exception occurred.
> [info 2020/01/29 11:41:07.759 PST tid=0x47] Now closing
> distribution for 192.168.99.1(server1:51825):41001
> [info 2020/01/29 11:41:07.760 PST tid=0x47]
> DistributionManager stopped in 103ms.
> [info 2020/01/29 11:41:07.760 PST tid=0x47] Marking
> DistributionManager 192.168.99.1(server1:51825):41001 as closed.
> {noformat}
> Here is truncated logging for the first reconnect:
> {noformat}
> [info 2020/01/29 11:42:07.755 PST tid=0x47] Attempting to
> reconnect to the distributed system. This is attempt #1.
> [info 2020/01/29 11:42:07.775 PST tid=0x47] Starting
> membership services
> [info 2020/01/29 11:42:07.778 PST tid=0x47] Established
> local address 192.168.99.1(server1:51825):41001
> [info 2020/01/29 11:42:07.779 PST tid=0x47] GemFire P2P
> Listener sta
[jira] [Commented] (GEODE-7717) ClusterManagementListResult should contain a list ConfigurationInfo (config per id)
[ https://issues.apache.org/jira/browse/GEODE-7717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032573#comment-17032573 ] ASF subversion and git services commented on GEODE-7717: Commit ebf23bb86bb0ce0396fa0d5ccbaac06b9c06d858 in geode's branch refs/heads/release/1.12.0 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ebf23bb ] GEODE-7717: ClusterManagementListResult should show a list of EntityInfo (#4673) * only show links in the EntityInfo level * rework list member responses (cherry picked from commit bda6bdf50c0a6a3e7cc39fb3ff654a0c26c86d94) > ClusterManagementListResult should contain a list ConfigurationInfo (config > per id) > --- > > Key: GEODE-7717 > URL: https://issues.apache.org/jira/browse/GEODE-7717 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Priority: Major > Labels: tech-debt, technical_debt > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently ClusterManagementListResult contains a list > ConfigurationResult(config per group), those configs are not grouped by id, > so a region that belongs to multiple groups might be dispersed in the list. > Since ClsuterManagementGetResult contains a single ConfigurationInfo, it > seems to make sense to have the ListResult contains a list of > ConfigurationInfo. > Also, after the ClusterManagementListResult contains the list grouped by id, > it would be good for us to display "links" in the ConfigurationInfo level > instead of ConfigurationResult level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7717) ClusterManagementListResult should contain a list ConfigurationInfo (config per id)
[ https://issues.apache.org/jira/browse/GEODE-7717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-7717. Fix Version/s: 1.12.0 Resolution: Fixed > ClusterManagementListResult should contain a list ConfigurationInfo (config > per id) > --- > > Key: GEODE-7717 > URL: https://issues.apache.org/jira/browse/GEODE-7717 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Priority: Major > Labels: tech-debt, technical_debt > Fix For: 1.12.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently ClusterManagementListResult contains a list > ConfigurationResult(config per group), those configs are not grouped by id, > so a region that belongs to multiple groups might be dispersed in the list. > Since ClsuterManagementGetResult contains a single ConfigurationInfo, it > seems to make sense to have the ListResult contains a list of > ConfigurationInfo. > Also, after the ClusterManagementListResult contains the list grouped by id, > it would be good for us to display "links" in the ConfigurationInfo level > instead of ConfigurationResult level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7777) add 1.13 management rest wiki page
Owen Nichols created GEODE-: --- Summary: add 1.13 management rest wiki page Key: GEODE- URL: https://issues.apache.org/jira/browse/GEODE- Project: Geode Issue Type: Bug Components: management Reporter: Owen Nichols each release gets a new wiki page... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7777) add 1.13 management rest wiki page
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-: --- Assignee: Owen Nichols > add 1.13 management rest wiki page > -- > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Bug > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > each release gets a new wiki page... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7778) Add PUBLISH, SUBSCRIBE and UNSUBSCRIBE Redis commands
[ https://issues.apache.org/jira/browse/GEODE-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-7778: - Assignee: Jens Deppe > Add PUBLISH, SUBSCRIBE and UNSUBSCRIBE Redis commands > - > > Key: GEODE-7778 > URL: https://issues.apache.org/jira/browse/GEODE-7778 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7778) Add PUBLISH, SUBSCRIBE and UNSUBSCRIBE Redis commands
Jens Deppe created GEODE-7778: - Summary: Add PUBLISH, SUBSCRIBE and UNSUBSCRIBE Redis commands Key: GEODE-7778 URL: https://issues.apache.org/jira/browse/GEODE-7778 Project: Geode Issue Type: Improvement Components: redis Reporter: Jens Deppe -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7751) Tomcat9CachingClientServerTest.containersShouldExpireInSetTimeframe failed.
[
https://issues.apache.org/jira/browse/GEODE-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032607#comment-17032607
]
Ivan Godwin commented on GEODE-7751:
Failed again:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1555
{code:java}
org.apache.geode.session.tests.Tomcat9CachingClientServerTest >
containersShouldExpireInSetTimeframe FAILED
org.awaitility.core.ConditionTimeoutException: Condition with lambda
expression in org.apache.geode.session.tests.CargoTestBase was not fulfilled
within 300 seconds.
Caused by:
java.util.concurrent.TimeoutExceptio{code}
> Tomcat9CachingClientServerTest.containersShouldExpireInSetTimeframe failed.
> ---
>
> Key: GEODE-7751
> URL: https://issues.apache.org/jira/browse/GEODE-7751
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
>
> Test run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2937
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7779) Concourse BumpXYZ does not include {prerelease}
Robert Houghton created GEODE-7779:
--
Summary: Concourse BumpXYZ does not include {prerelease}
Key: GEODE-7779
URL: https://issues.apache.org/jira/browse/GEODE-7779
Project: Geode
Issue Type: Bug
Components: ci
Reporter: Robert Houghton
After cutting the 1.13.0 release branch, hitting {noformat}BumpMinor{noformat}
caused the semver to move from {noformat}1.12.0-SNAPSHOT.246{noformat} ->
{noformat}1.13.0{noformat}, which is then sorted in semantic-order to be higher
value than {noformat}1.13.0-SNAPSHOT.1{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5595) CI: DeltaPropagationDUnit.testBug40165ClientReconnects - NoSubscriptionServersAvailableException
[
https://issues.apache.org/jira/browse/GEODE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032628#comment-17032628
]
ASF subversion and git services commented on GEODE-5595:
Commit a2ac820116c7a54dcbf95dbaa0fd37eb5e7e09d8 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a2ac820 ]
GEODE-5595: Fix DeltaPropagationDUnitTest flakiness (#4653)
Improve testability of CacheClientProxy
* Extract inner classes
* Introduce CacheClientProxyFactory with support for property injection
> CI: DeltaPropagationDUnit.testBug40165ClientReconnects -
> NoSubscriptionServersAvailableException
>
>
> Key: GEODE-5595
> URL: https://issues.apache.org/jira/browse/GEODE-5595
> Project: Geode
> Issue Type: Bug
>Reporter: Ken Howe
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> This test failed. See _Issue Links_ section below for a bunch of other tests
> that seem to fail due to the same underlying product fault. See [~klund]'s
> analysis cited in the comment section for that underlying fault. Don't mark
> this ticket resolved until that product problem is really fixed please.
> {code:java}
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest >
> testBug40165ClientReconnects FAILED
>
> 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:187)
>
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:548)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:855)
>
> at
> org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
>
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:355)
>
> at
> org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3797)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3888)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3686)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3681)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3676)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1305)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.testBug40165ClientReconnects(DeltaPropagationDUnitTest.java:647)
>
>
> Caused by:
>
> 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.initializeConnections(QueueManagerImpl.java:585)
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:296)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:352)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:176)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:162)
>
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:349)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1295)
>
> ... 1 more
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7777) add 1.13 management rest wiki page
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032655#comment-17032655 ] ASF subversion and git services commented on GEODE-: Commit 72e83460603c629f8dbf6a636f46844d03f8bb51 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=72e8346 ] GEODE-: add 1.13 management rest wiki page (#4681) > add 1.13 management rest wiki page > -- > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Bug > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > each release gets a new wiki page... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7777) add 1.13 management rest wiki page
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-. - Fix Version/s: 1.13.0 Resolution: Fixed > add 1.13 management rest wiki page > -- > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Bug > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > each release gets a new wiki page... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7757) list gateway command should also show the gateway sender's connected state
[
https://issues.apache.org/jira/browse/GEODE-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-7757.
Fix Version/s: 1.13.0
Resolution: Fixed
> list gateway command should also show the gateway sender's connected state
> --
>
> Key: GEODE-7757
> URL: https://issues.apache.org/jira/browse/GEODE-7757
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jinmei Liao
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Pulse shows the gateway sender's connected state, but gfsh list gateways
> sender command only shows the running/paused/stopping state, and user needs
> to infer the "connected" state by the information in the "Receiver Location"
> column.
> Here is the output sample of list gateways:
> {noformat}
> GatewaySender Id | Member | Remote Cluster Id
> | Type | Status | Queued Events | Receiver Location
> | - | -
> | -- | --- | - | -
> gws2 | 192.168.86.30(server:72557):41001 | 2
> | Serial | Running | 0 |
> {noformat}
>
> It would be nice for the gfsh command to spell out if the gateway sender is
> "connected" or not. Maybe the Status column should show those state:
> "running, not connected", "running and connected" .
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7780) Geode session management could update a stale state and cause some session attributes to be lost if enableLocalCache is set to true
Eric Shu created GEODE-7780:
---
Summary: Geode session management could update a stale state and
cause some session attributes to be lost if enableLocalCache is set to true
Key: GEODE-7780
URL: https://issues.apache.org/jira/browse/GEODE-7780
Project: Geode
Issue Type: Bug
Components: http session
Reporter: Eric Shu
I have analyzed the test failure
(https://issues.apache.org/jira/browse/GEODE-7753) and found out the cause.
What happened is that for every session get (get through geode client local
caching), geode session management will do a put of that session to reset the
lastAccessTime on all servers and local caches used by Tomcat servers.
Please see the code below:
{code:java}
public void commit() {
if (!isValidInternal())
throw new IllegalStateException("commit: Session " + getId() + " already
invalidated");
// (STRING_MANAGER.getString("deltaSession.commit.ise", getId()));
synchronized (this.changeLock) {
// Jens - there used to be a check to only perform this if the queue is
// empty, but we want this to always run so that the lastAccessedTime
// will be updated even when no attributes have been changed.
DeltaSessionManager mgr = (DeltaSessionManager) this.manager;
if (this.enableGatewayDeltaReplication && mgr.isPeerToPeer()) {
setCurrentGatewayDeltaEvent(
new DeltaSessionAttributeEventBatch(this.sessionRegionName,
this.id, this.eventQueue));
}
this.hasDelta = true;
this.applyRemotely = true;
putInRegion(getOperatingRegion(), true, null);
this.eventQueue.clear();
}
}
{code}
However, because this is a client local cache, the get could have stale data
(some delta updates have not been delivered yet through HARegionQueue). This
new update will update on server to be a staled data (lost some of the
attributes).
The stack shows the get and the following put of the session are:
{noformat}
at
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1312)
at
org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
at
org.apache.geode.modules.session.catalina.AbstractSessionCache.getSession(AbstractSessionCache.java:69)
at
org.apache.geode.modules.session.catalina.DeltaSessionManager.findSession(DeltaSessionManager.java:340)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2951)
at
org.apache.catalina.connector.Request.getSessionInternal(Request.java:2677)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
{noformat}
and
{noformat}
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1628)
at
org.apache.geode.modules.session.catalina.DeltaSession.putInRegion(DeltaSession.java:442)
at
org.apache.geode.modules.session.catalina.DeltaSession.commit(DeltaSession.java:469)
at
org.apache.geode.modules.session.catalina.DeltaSessionFacade.commit(DeltaSessionFacade.java:36)
at
org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:56)
at
org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:45)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValv
[jira] [Commented] (GEODE-7777) add 1.13 management rest wiki page
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032692#comment-17032692 ] ASF subversion and git services commented on GEODE-: Commit 72e83460603c629f8dbf6a636f46844d03f8bb51 in geode's branch refs/heads/mass-test-run from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=72e8346 ] GEODE-: add 1.13 management rest wiki page (#4681) > add 1.13 management rest wiki page > -- > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Bug > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > each release gets a new wiki page... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) Redundant JMX managers may not federate mbeans of other JMX managers
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032684#comment-17032684 ] ASF subversion and git services commented on GEODE-7739: Commit 5c8edc26ac81144f3e556fde3be9cb08f5a8fa18 in geode's branch refs/heads/mass-test-run from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c8edc2 ] GEODE-7739: Federate ManagerMXBean (#4655) * Reenable locator mbean federation validation in JMXMBeanReconnectDUnitTest * Fix federation of ManagerMXBean * Remove atMost clause from await calls > Redundant JMX managers may not federate mbeans of other JMX managers > > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7772) Simplify hasNext in PageableLuceneQueryResultsImpl
[
https://issues.apache.org/jira/browse/GEODE-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032686#comment-17032686
]
ASF subversion and git services commented on GEODE-7772:
Commit 93aa3c4668f888e62d7951c1712c179955b6d01b in geode's branch
refs/heads/mass-test-run from mkevo
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=93aa3c4 ]
GEODE-7772: Simplify hasNext in PageableLuceneQueryResultsImpl (#4678)
> Simplify hasNext in PageableLuceneQueryResultsImpl
> --
>
> Key: GEODE-7772
> URL: https://issues.apache.org/jira/browse/GEODE-7772
> Project: Geode
> Issue Type: Task
> Components: lucene
>Reporter: Jason Huynh
>Assignee: Mario Kevo
>Priority: Major
> Labels: beginner, newb, starter
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The if statement in the hasNext() method can be simplified by condensing into
> a single line return statement.
> See here:
> [https://github.com/apache/geode/blob/182de42d8e56a900f0d22793a440af72f62f09f4/geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/PageableLuceneQueryResultsImpl.java#L149]
>
> Example, and possibly correct fix:
> {code:java}
> return !currentPage.isEmpty();{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7717) ClusterManagementListResult should contain a list ConfigurationInfo (config per id)
[ https://issues.apache.org/jira/browse/GEODE-7717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032687#comment-17032687 ] ASF subversion and git services commented on GEODE-7717: Commit bda6bdf50c0a6a3e7cc39fb3ff654a0c26c86d94 in geode's branch refs/heads/mass-test-run from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bda6bdf ] GEODE-7717: ClusterManagementListResult should show a list of EntityInfo (#4673) * only show links in the EntityInfo level * rework list member responses > ClusterManagementListResult should contain a list ConfigurationInfo (config > per id) > --- > > Key: GEODE-7717 > URL: https://issues.apache.org/jira/browse/GEODE-7717 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Priority: Major > Labels: tech-debt, technical_debt > Fix For: 1.12.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently ClusterManagementListResult contains a list > ConfigurationResult(config per group), those configs are not grouped by id, > so a region that belongs to multiple groups might be dispersed in the list. > Since ClsuterManagementGetResult contains a single ConfigurationInfo, it > seems to make sense to have the ListResult contains a list of > ConfigurationInfo. > Also, after the ClusterManagementListResult contains the list grouped by id, > it would be good for us to display "links" in the ConfigurationInfo level > instead of ConfigurationResult level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-5595) CI: DeltaPropagationDUnit.testBug40165ClientReconnects - NoSubscriptionServersAvailableException
[
https://issues.apache.org/jira/browse/GEODE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032691#comment-17032691
]
ASF subversion and git services commented on GEODE-5595:
Commit a2ac820116c7a54dcbf95dbaa0fd37eb5e7e09d8 in geode's branch
refs/heads/mass-test-run from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a2ac820 ]
GEODE-5595: Fix DeltaPropagationDUnitTest flakiness (#4653)
Improve testability of CacheClientProxy
* Extract inner classes
* Introduce CacheClientProxyFactory with support for property injection
> CI: DeltaPropagationDUnit.testBug40165ClientReconnects -
> NoSubscriptionServersAvailableException
>
>
> Key: GEODE-5595
> URL: https://issues.apache.org/jira/browse/GEODE-5595
> Project: Geode
> Issue Type: Bug
>Reporter: Ken Howe
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> This test failed. See _Issue Links_ section below for a bunch of other tests
> that seem to fail due to the same underlying product fault. See [~klund]'s
> analysis cited in the comment section for that underlying fault. Don't mark
> this ticket resolved until that product problem is really fixed please.
> {code:java}
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest >
> testBug40165ClientReconnects FAILED
>
> 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:187)
>
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:548)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:855)
>
> at
> org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
>
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:355)
>
> at
> org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3797)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3888)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3686)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3681)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3676)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1305)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.testBug40165ClientReconnects(DeltaPropagationDUnitTest.java:647)
>
>
> Caused by:
>
> 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.initializeConnections(QueueManagerImpl.java:585)
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:296)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:352)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:176)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:162)
>
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:349)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1295)
>
> ... 1 more
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7760) NPE in reconnecting Locator
[
https://issues.apache.org/jira/browse/GEODE-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032688#comment-17032688
]
ASF subversion and git services commented on GEODE-7760:
Commit af8307243e3c8dfb4f0c03b4539eace0b3ea11b3 in geode's branch
refs/heads/mass-test-run from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=af83072 ]
GEODE-7760: NPE in Locator during auto-reconnect (#4668)
* GEODE-7760: NPE in Locator during auto-reconnect
* empty commit
* fixes for stress-testing
* working on another stresstest failure
This test passes all the time outside of stress testing
* ignoring test that seems to have trouble with workingDir/configDir and
temporary folders in stress testing
* remove use of static locator variable in InternalLocator. added crash test.
unset shutdownHandled after locator restarts
* fixing stresstest issues
> NPE in reconnecting Locator
> ---
>
> Key: GEODE-7760
> URL: https://issues.apache.org/jira/browse/GEODE-7760
> Project: Geode
> Issue Type: Bug
> Components: management, membership
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A v1.9 locator was forced out of the cluster and then threw an NPE when it
> was reconnecting. Apparently the new DistributedSystem was also kicked out
> of the cluster during this time.
> {noformat}
> [fatal 2019/12/18 02:14:55.647 UTC
> tid=0xb1a5] Uncaught exception in thread Thread[Location services restart
> thread,5,main]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:690)
> at
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalLocator.java:1124)
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1062)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$1(InternalLocator.java:983)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This wasn't from a CI run and there are no other artifacts available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7760) NPE in reconnecting Locator
[
https://issues.apache.org/jira/browse/GEODE-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032690#comment-17032690
]
ASF subversion and git services commented on GEODE-7760:
Commit af8307243e3c8dfb4f0c03b4539eace0b3ea11b3 in geode's branch
refs/heads/mass-test-run from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=af83072 ]
GEODE-7760: NPE in Locator during auto-reconnect (#4668)
* GEODE-7760: NPE in Locator during auto-reconnect
* empty commit
* fixes for stress-testing
* working on another stresstest failure
This test passes all the time outside of stress testing
* ignoring test that seems to have trouble with workingDir/configDir and
temporary folders in stress testing
* remove use of static locator variable in InternalLocator. added crash test.
unset shutdownHandled after locator restarts
* fixing stresstest issues
> NPE in reconnecting Locator
> ---
>
> Key: GEODE-7760
> URL: https://issues.apache.org/jira/browse/GEODE-7760
> Project: Geode
> Issue Type: Bug
> Components: management, membership
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> A v1.9 locator was forced out of the cluster and then threw an NPE when it
> was reconnecting. Apparently the new DistributedSystem was also kicked out
> of the cluster during this time.
> {noformat}
> [fatal 2019/12/18 02:14:55.647 UTC
> tid=0xb1a5] Uncaught exception in thread Thread[Location services restart
> thread,5,main]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:690)
> at
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalLocator.java:1124)
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1062)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$1(InternalLocator.java:983)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This wasn't from a CI run and there are no other artifacts available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7752) Update ConfigurationServiceBuilder to be more intuitive
[ https://issues.apache.org/jira/browse/GEODE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032683#comment-17032683 ] ASF subversion and git services commented on GEODE-7752: Commit 7028f601680fee3f57cbdff63951128d7180ca13 in geode's branch refs/heads/mass-test-run from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7028f60 ] GEODE-7752: Removed the current optionality on the ClusterManagementServiceBuilder. (#4650) The Transport is not responsible to set the ConnectionConfig. > Update ConfigurationServiceBuilder to be more intuitive > --- > > Key: GEODE-7752 > URL: https://issues.apache.org/jira/browse/GEODE-7752 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > With the introduction of ClusterManagementServiceBuilder, an inadvertent > confusing configuration manner was introduced. > In the Builder pattern, the setter methods are optional and required fields > are either added on the constructor or build method. > The current ClusterManangementServiceBuilder introduced the notion of > required optionality. Where you had to pick at least one of the setters. > To fix this, I removed `setConnectionConfig` which is really only required > for the Transport and removed that option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7752) Update ConfigurationServiceBuilder to be more intuitive
[ https://issues.apache.org/jira/browse/GEODE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032685#comment-17032685 ] ASF subversion and git services commented on GEODE-7752: Commit 9c102e4f8836ca32ad51a05bbd4d0107e8fc0343 in geode's branch refs/heads/mass-test-run from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9c102e4 ] GEODE-7752: Fix distributedTests failing (#4676) > Update ConfigurationServiceBuilder to be more intuitive > --- > > Key: GEODE-7752 > URL: https://issues.apache.org/jira/browse/GEODE-7752 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > With the introduction of ClusterManagementServiceBuilder, an inadvertent > confusing configuration manner was introduced. > In the Builder pattern, the setter methods are optional and required fields > are either added on the constructor or build method. > The current ClusterManangementServiceBuilder introduced the notion of > required optionality. Where you had to pick at least one of the setters. > To fix this, I removed `setConnectionConfig` which is really only required > for the Transport and removed that option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7758) Add unit test for SetExecutor
[ https://issues.apache.org/jira/browse/GEODE-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-7758. --- Fix Version/s: 1.13.0 Resolution: Fixed > Add unit test for SetExecutor > - > > Key: GEODE-7758 > URL: https://issues.apache.org/jira/browse/GEODE-7758 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.13.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7780) Geode session management could update a stale state and cause some session attributes to be lost if enableLocalCache is set to true
[
https://issues.apache.org/jira/browse/GEODE-7780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032699#comment-17032699
]
Eric Shu commented on GEODE-7780:
-
Currently we do not have a good way to update the last access time of an entry
if the get is on a client local cache. The last access time is not propagated
to servers, and certainly won't update it on entries in other local client
caches used by tomcat servers.
It seems that put follows after a get would solve the early expiry problem --
however, it incurs additional put operation (distributed operation) for a get.
Shall we just stop allow caching proxy being used/set when using session
caching through tomcat servers?
If this is not feasible, one option could be providing a new method that can be
invoked on client so that server will do an update of a key using its latest
value.
Another option is to provide a way that get on a local client cache will update
lastAccessTime of the same entry on all servers and all other local client
caches. (I am not sure if there is a way to do this.)
> Geode session management could update a stale state and cause some session
> attributes to be lost if enableLocalCache is set to true
> ---
>
> Key: GEODE-7780
> URL: https://issues.apache.org/jira/browse/GEODE-7780
> Project: Geode
> Issue Type: Bug
> Components: http session
>Reporter: Eric Shu
>Priority: Major
>
> I have analyzed the test failure
> (https://issues.apache.org/jira/browse/GEODE-7753) and found out the cause.
> What happened is that for every session get (get through geode client local
> caching), geode session management will do a put of that session to reset the
> lastAccessTime on all servers and local caches used by Tomcat servers.
> Please see the code below:
> {code:java}
> public void commit() {
> if (!isValidInternal())
> throw new IllegalStateException("commit: Session " + getId() + "
> already invalidated");
> // (STRING_MANAGER.getString("deltaSession.commit.ise", getId()));
> synchronized (this.changeLock) {
> // Jens - there used to be a check to only perform this if the queue is
> // empty, but we want this to always run so that the lastAccessedTime
> // will be updated even when no attributes have been changed.
> DeltaSessionManager mgr = (DeltaSessionManager) this.manager;
> if (this.enableGatewayDeltaReplication && mgr.isPeerToPeer()) {
> setCurrentGatewayDeltaEvent(
> new DeltaSessionAttributeEventBatch(this.sessionRegionName,
> this.id, this.eventQueue));
> }
> this.hasDelta = true;
> this.applyRemotely = true;
> putInRegion(getOperatingRegion(), true, null);
> this.eventQueue.clear();
> }
> }
> {code}
> However, because this is a client local cache, the get could have stale data
> (some delta updates have not been delivered yet through HARegionQueue). This
> new update will update on server to be a staled data (lost some of the
> attributes).
> The stack shows the get and the following put of the session are:
> {noformat}
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1312)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.modules.session.catalina.AbstractSessionCache.getSession(AbstractSessionCache.java:69)
> at
> org.apache.geode.modules.session.catalina.DeltaSessionManager.findSession(DeltaSessionManager.java:340)
> at
> org.apache.catalina.connector.Request.doGetSession(Request.java:2951)
> at
> org.apache.catalina.connector.Request.getSessionInternal(Request.java:2677)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
> at
> org.apache.tomcat.util.net.Soc
[jira] [Commented] (GEODE-7780) Geode session management could update a stale state and cause some session attributes to be lost if enableLocalCache is set to true
[
https://issues.apache.org/jira/browse/GEODE-7780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032703#comment-17032703
]
Eric Shu commented on GEODE-7780:
-
Please note when using sticky session set on tomcat servers, this issue would
not occur without tomcat server failover. If connection to one Tomcat server
failed and then fail over to another tomcat server, this issue could
potentially occur if there are events still in HARegionQueue for the particular
session.
> Geode session management could update a stale state and cause some session
> attributes to be lost if enableLocalCache is set to true
> ---
>
> Key: GEODE-7780
> URL: https://issues.apache.org/jira/browse/GEODE-7780
> Project: Geode
> Issue Type: Bug
> Components: http session
>Reporter: Eric Shu
>Priority: Major
>
> I have analyzed the test failure
> (https://issues.apache.org/jira/browse/GEODE-7753) and found out the cause.
> What happened is that for every session get (get through geode client local
> caching), geode session management will do a put of that session to reset the
> lastAccessTime on all servers and local caches used by Tomcat servers.
> Please see the code below:
> {code:java}
> public void commit() {
> if (!isValidInternal())
> throw new IllegalStateException("commit: Session " + getId() + "
> already invalidated");
> // (STRING_MANAGER.getString("deltaSession.commit.ise", getId()));
> synchronized (this.changeLock) {
> // Jens - there used to be a check to only perform this if the queue is
> // empty, but we want this to always run so that the lastAccessedTime
> // will be updated even when no attributes have been changed.
> DeltaSessionManager mgr = (DeltaSessionManager) this.manager;
> if (this.enableGatewayDeltaReplication && mgr.isPeerToPeer()) {
> setCurrentGatewayDeltaEvent(
> new DeltaSessionAttributeEventBatch(this.sessionRegionName,
> this.id, this.eventQueue));
> }
> this.hasDelta = true;
> this.applyRemotely = true;
> putInRegion(getOperatingRegion(), true, null);
> this.eventQueue.clear();
> }
> }
> {code}
> However, because this is a client local cache, the get could have stale data
> (some delta updates have not been delivered yet through HARegionQueue). This
> new update will update on server to be a staled data (lost some of the
> attributes).
> The stack shows the get and the following put of the session are:
> {noformat}
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1312)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.modules.session.catalina.AbstractSessionCache.getSession(AbstractSessionCache.java:69)
> at
> org.apache.geode.modules.session.catalina.DeltaSessionManager.findSession(DeltaSessionManager.java:340)
> at
> org.apache.catalina.connector.Request.doGetSession(Request.java:2951)
> at
> org.apache.catalina.connector.Request.getSessionInternal(Request.java:2677)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:460)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
> at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> and
> {noformat}
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1628)
> at
> org.apache.geode.modules.session.catalina.DeltaSession.putInRegion
[jira] [Created] (GEODE-7781) CI Failure: TCPConduitDUnitTest.basicAcceptConnection
Ivan Godwin created GEODE-7781:
--
Summary: CI Failure: TCPConduitDUnitTest.basicAcceptConnection
Key: GEODE-7781
URL: https://issues.apache.org/jira/browse/GEODE-7781
Project: Geode
Issue Type: Bug
Components: core
Reporter: Ivan Godwin
TCPConduitDUnitTest.basicAcceptConnection failed with the following stacktrace:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1557
{code:java}
org.apache.geode.internal.tcp.TCPConduitDUnitTest > basicAcceptConnection[0]
FAILED
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.10(1:locator):41001 started at Fri Feb
07 21:28:15 GMT 2020: for testing, caused by
org.apache.geode.ForcedDisconnectException: for testing
Caused by:
org.apache.geode.ForcedDisconnectException: for testing
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-4263) CI Failure: ResourceManagerWithQueryMonitorDUnitTest. testRM* are failing
[
https://issues.apache.org/jira/browse/GEODE-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032750#comment-17032750
]
Ivan Godwin commented on GEODE-4263:
Failed again:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1557]
{code:java}
org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest >
testRMButDisabledQueryMonitorForLowMemAndNoTimeoutSetOnServer FAILED
java.lang.AssertionError: queryExecution.getResult() threw Exception
java.lang.AssertionError: An exception occurred during asynchronous invocation.
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doTestCriticalHeapAndQueryTimeout(ResourceManagerWithQueryMonitorDUnitTest.java:848)
at
org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doCriticalMemoryHitTestOnServer(ResourceManagerWithQueryMonitorDUnitTest.java:699)
at
org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.testRMButDisabledQueryMonitorForLowMemAndNoTimeoutSetOnServer(ResourceManagerWithQueryMonitorDUnitTest.java:224)
{code}
> CI Failure: ResourceManagerWithQueryMonitorDUnitTest. testRM* are failing
> -
>
> Key: GEODE-4263
> URL: https://issues.apache.org/jira/browse/GEODE-4263
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Nabarun Nag
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
>
> {noformat}
> java.lang.AssertionError: queryExecution.getResult() threw Exception
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doTestCriticalHeapAndQueryTimeout(ResourceManagerWithQueryMonitorDUnitTest.java:738)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doCriticalMemoryHitTest(ResourceManagerWithQueryMonitorDUnitTest.java:321)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.testRMAndTimeoutSet(ResourceManagerWithQueryMonitorDUnitTest.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62
[jira] [Commented] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032761#comment-17032761 ] ASF subversion and git services commented on GEODE-7109: Commit 04e3c3f0c42599fe378d73f56742dbb2d5b61476 in geode's branch refs/heads/feature/GEODE-7109 from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=04e3c3f ] GEODE-7109: add test case that multiple sessions can be maintained. > Improve DUnit test coverage for Tomcat session state module > --- > > Key: GEODE-7109 > URL: https://issues.apache.org/jira/browse/GEODE-7109 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Benjamin P Ross >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Time Spent: 1h > Remaining Estimate: 0h > > Our DUnit test coverage is significantly lacking for the Tomcat session state > module. This story aims to improve test coverage of that module. > Write DUnit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.4#803005)
