Skip to content

CAMEL-23216 - remove concurrency for Mina sftp tests - #25043

Merged
apupier merged 1 commit into
apache:mainfrom
apupier:CAMEL-23216-flakyMinaSftp
Jul 23, 2026
Merged

CAMEL-23216 - remove concurrency for Mina sftp tests#25043
apupier merged 1 commit into
apache:mainfrom
apupier:CAMEL-23216-flakyMinaSftp

Conversation

@apupier

@apupier apupier commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Mina Sftp tests are flaky. They are failing around 1 out of 10 times on Jenkins CI, so given that they are played on various combination, almost 1 out 2 times per job run on Jenkins CI.

I'm unable to reproduce locally after launching 50 times.

It is not always the same tests which is failing first, but after one is failing almost all others are failing.

When going fine it takes 1 minutes on CI, when failing it takes 11 minutes.
Locally when playing them it takes 47", when removing parallelism, it takes 4'30. So on CI, I expect it to take 5'30. This is not ideal but the most reasonable solution I found so far to mitigate the problem. These tests are currently the ones which are failing the most often on CI by far.

Errors are mentioning things like: Cannot connect to mina-sftp://admin@localhost:42385
It is always on a different port so not a port conflict

Other opinions or ideas?

Description

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 filed for the change (usually before you start working on it).

Apache Camel coding standards and style

  • I checked that each commit in the pull request has a meaningful subject line and body.
  • I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

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.

Mina Sftp tests are flaky. They are failing around 1 out of 10 times on
Jenkins CI, so given that they are played on various combination, almost
1 out 2 times per job run on Jenkins CI.

I'm unable to reproduce locally after launching 50 times.

It is not always the same tests which is failing first, but after one is
failing almost all others are failing.

When going fine it takes 1 minutes on CI, when failing it takes 11
minutes.
Locally when playing them it takes 47", when removing parallelism, it
takes 4'30. So on CI, I expect it to take 5'30. This is not ideal but
the most reasonable solution I found so far to mitigate the problem.
These tests are currently the ones which are failing the most often on
CI by far.

Signed-off-by: Aurélien Pupier <apupier@ibm.com>
@github-actions

Copy link
Copy Markdown
Contributor

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

  • First-time contributors require MANUAL approval for the GitHub Actions to run
  • You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
  • You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
  • Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

@github-actions

Copy link
Copy Markdown
Contributor

🧪 CI tested the following changed modules:

  • components/camel-mina-sftp

🔬 Scalpel shadow comparison — Scalpel: 9 tested, 29 compile-only — current: 9 all tested

Maveniverse Scalpel detected 38 affected modules (current approach: 9).

⚠️ Modules only in Scalpel (29)
  • apache-camel
  • camel-allcomponents
  • camel-catalog
  • camel-catalog-console
  • camel-catalog-lucene
  • camel-catalog-maven
  • camel-catalog-suggest
  • camel-componentdsl
  • camel-csimple-maven-plugin
  • camel-endpointdsl
  • camel-endpointdsl-support
  • camel-itest
  • camel-jbang-core
  • camel-jbang-it
  • camel-jbang-main
  • camel-jbang-plugin-edit
  • camel-jbang-plugin-generate
  • camel-jbang-plugin-kubernetes
  • camel-jbang-plugin-test
  • camel-kamelet-main
  • camel-launcher
  • camel-report-maven-plugin
  • camel-route-parser
  • camel-yaml-dsl
  • camel-yaml-dsl-deserializers
  • camel-yaml-dsl-maven-plugin
  • coverage
  • docs
  • dummy-component

Skip-tests mode would test 9 modules (1 direct + 8 downstream), skip tests for 29 (generated code, meta-modules)

Modules Scalpel would test (9)
  • camel-jbang-mcp
  • camel-jbang-plugin-mcp
  • camel-jbang-plugin-route-parser
  • camel-jbang-plugin-tui
  • camel-jbang-plugin-validate
  • camel-launcher-container
  • camel-mina-sftp
  • camel-yaml-dsl-validator
  • camel-yaml-dsl-validator-maven-plugin
Modules with tests skipped (29)
  • apache-camel
  • camel-allcomponents
  • camel-catalog
  • camel-catalog-console
  • camel-catalog-lucene
  • camel-catalog-maven
  • camel-catalog-suggest
  • camel-componentdsl
  • camel-csimple-maven-plugin
  • camel-endpointdsl
  • camel-endpointdsl-support
  • camel-itest
  • camel-jbang-core
  • camel-jbang-it
  • camel-jbang-main
  • camel-jbang-plugin-edit
  • camel-jbang-plugin-generate
  • camel-jbang-plugin-kubernetes
  • camel-jbang-plugin-test
  • camel-kamelet-main
  • camel-launcher
  • camel-report-maven-plugin
  • camel-route-parser
  • camel-yaml-dsl
  • camel-yaml-dsl-deserializers
  • camel-yaml-dsl-maven-plugin
  • coverage
  • docs
  • dummy-component

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

All tested modules (38 modules)
  • Camel :: All Components Sync point
  • Camel :: Assembly
  • Camel :: Catalog :: CSimple Maven Plugin (deprecated)
  • Camel :: Catalog :: Camel Catalog
  • Camel :: Catalog :: Camel Report Maven Plugin
  • Camel :: Catalog :: Camel Route Parser
  • Camel :: Catalog :: Console
  • Camel :: Catalog :: Dummy Component
  • Camel :: Catalog :: Lucene (deprecated)
  • Camel :: Catalog :: Maven
  • Camel :: Catalog :: Suggest
  • Camel :: Component DSL
  • Camel :: Coverage
  • Camel :: Docs
  • Camel :: Endpoint DSL
  • Camel :: Endpoint DSL :: Support
  • Camel :: Integration Tests
  • Camel :: JBang :: Core
  • Camel :: JBang :: Integration tests
  • Camel :: JBang :: MCP
  • Camel :: JBang :: Main
  • Camel :: JBang :: Plugin :: Edit
  • Camel :: JBang :: Plugin :: Generate
  • Camel :: JBang :: Plugin :: Kubernetes
  • Camel :: JBang :: Plugin :: MCP
  • Camel :: JBang :: Plugin :: Route Parser
  • Camel :: JBang :: Plugin :: TUI
  • Camel :: JBang :: Plugin :: Testing
  • Camel :: JBang :: Plugin :: Validate
  • Camel :: Kamelet Main
  • Camel :: Launcher
  • Camel :: Launcher :: Container
  • Camel :: MINA SFTP
  • Camel :: YAML DSL
  • Camel :: YAML DSL :: Deserializers
  • Camel :: YAML DSL :: Maven Plugins
  • Camel :: YAML DSL :: Validator
  • Camel :: YAML DSL :: Validator Maven Plugin

⚙️ View full build and test results

@apupier
apupier marked this pull request as ready for review July 23, 2026 08:29

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach of using reuseForks=false to give each test class its own JVM is sound and correctly eliminates the cross-class interference causing flakiness.

Verified:

  • The fix correctly removes the @Tag("isolated") mechanism and the two-execution failsafe setup in favor of a simpler reuseForks=false approach
  • JVM isolation prevents the PathUtils.setUserHomeFolderResolver() global state mutation from leaking across test classes
  • CI passes with all tests green
  • Git history confirms a clear progression: CAMEL-22379CAMEL-23921 → this PR (CAMEL-23216), each addressing more of the flakiness

Minor note: <camel.failsafe.parallel>true</camel.failsafe.parallel> is now effectively a no-op with reuseForks=false (each JVM has only one class). Consider setting it to false for clarity, though this is cosmetic.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet

@apupier
apupier merged commit adb5ef4 into apache:main Jul 23, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants