[
https://issues.apache.org/jira/browse/ARTEMIS-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved ARTEMIS-3450.
-------------------------------------
Fix Version/s: 2.19.0
Resolution: Fixed
> StaticPoolTest and DiscoveryPoolTest fail sporadically in CI
> ------------------------------------------------------------
>
> Key: ARTEMIS-3450
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3450
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
> Affects Versions: 2.18.0
> Reporter: Robbie Gemmell
> Assignee: Domenico Francesco Bruscino
> Priority: Major
> Fix For: 2.19.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The StaticPoolTest and DiscoveryPoolTest tests added in ARTEMIS-3365 fail
> sporadically in CI
> Some examples:
> https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2325
> https://github.com/apache/activemq-artemis/runs/3433060966?check_suite_focus=true#step:5:2223
> Looking at the tests I do see a few small issues, though they may not explain
> the failures:
> - The MockTargetProbe contains a HashMap used from multiple threads (test and
> pool) in a manner that isnt thread safe. It actually threw
> ConcurrentModificationException during at least one CI run (e.g
> https://github.com/apache/activemq-artemis/runs/3416448949?check_suite_focus=true#step:5:2163).
> That may or may not be the cause of the test failure seen in the same log
> (note it isnt seen in the other test log, though it failed at a different
> assertion). It should use ConcurrentHashMap or perhaps alternatively protect
> use of the map more generally.
> - The PoolTestBase#testPoolQuorumWithMultipleTargets test creates and starts
> a pool but doesnt ensure it is stopped on assertion failure. The
> DiscoveryPoolTest subclass runs this test with a pool using a scheduled
> executor, so it should presumably be cleaned up in the same manner the other
> tests all use.
> - One of the tests asserts there are no 'createdTargets' entries, and then
> immediately iterates those [non-existent] entries to assert on the
> non-existent values, which seems quite strange.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
