apupier opened a new pull request, #27613:
URL: https://github.com/apache/camel/pull/27613
Three independent bugs caused ConditionTimeoutException in
JGroupsRaftProducerTest, JGroupsRaftClusteredRoutePolicyTest and
JGroupsRaftMasterTest:
1. raftABC.xml: FD_SOCK was present but unnecessary for SHARED_LOOPBACK
in-process tests; FD_ALL had no explicit timeout so it used the
network-deployment default (~10 s), causing live in-process members to
be falsely suspected as dead on a loaded CI machine. This triggered
spurious re-elections that exhausted the 30-50 s awaitility budget. Removed
FD_SOCK, set FD_ALL timeout=3000/interval=500, bounded MERGE3 intervals,
tightened VERIFY_SUSPECT, and added an explicit raft.ELECTION vote_timeout=1000.
2. ClusterRoleChangeListener: the Role enum has three values (Follower,
Leader, Learner) but only Follower and Leader were handled; the default
branch threw UnsupportedOperationException. A node transitioning to
Learner (e.g. a re-joining node catching up on the log) would crash its own
role-listener callback thread, permanently preventing it from ever registering
a subsequent Leader/Follower transition, so waitForLeader() would always time
out for that node. Added case Learner falling through to the Follower de-master
block; changed default from throw to LOG.warn + break.
3. JGroupsRaftClusterView.doStop(): raftHandle.channel().disconnect() was
called unconditionally (no null check) while the log-close block
immediately below it already had a null guard. A race between shutdown
and a failed-start path could throw NullPointerException in doStop,
leaving channels open and leaking state into subsequent tests sharing the same
SHARED_LOOPBACK cluster namespace. Wrapped disconnect() in the same null guard
used for log.close().
Co-autored-by: IBM Bob 2.2.1
# Description
<!--
- Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
-->
# Target
- [ ] I checked that the commit is targeting the correct branch (Camel 4
uses the `main` branch)
# Tracking
- [ ] If this is a large change, bug fix, or code improvement, I checked
there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for
the change (usually before you start working on it).
<!--
# *Note*: trivial changes like, typos, minor documentation fixes and other
small items do not require a JIRA issue. In this case your pull request should
address just this issue, without pulling in other changes.
-->
# Apache Camel coding standards and style
- [ ] I checked that each commit in the pull request has a meaningful
subject line and body.
<!--
If you're unsure, you can format the pull request title like `[CAMEL-XXX]
Fixes bug in camel-file component`, where you replace `CAMEL-XXX` with the
appropriate JIRA issue.
-->
- [ ] I have run `mvn clean install -DskipTests` locally from root folder
and I have committed all auto-generated changes.
<!--
You can run the aforementioned command in your module so that the build
auto-formats your code. This will also be verified as part of the checks and
your PR may be rejected if if there are uncommited changes after running `mvn
clean install -DskipTests`.
You can learn more about the contribution guidelines at
https://github.com/apache/camel/blob/main/CONTRIBUTING.md
-->
# AI-assisted contributions
- [ ] If this PR includes AI-generated code, commits have proper
co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR
description identifies the AI tool used.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
