[MINOR] Cap UT_FT_10 Azure install to -T 2 to avoid flaky compiler heap OOM

[wombatu-kun]

Describe the issue this Pull Request addresses

The Azure CI job "UT FT common & other modules" (UT_FT_10) intermittently fails its initial full-reactor mvn clean install with maven-compiler-plugin:compile ... Bad service configuration file, or exception thrown while constructing Processor object: Java heap space, most recently while compiling hudi-kafka-connect-bundle (for example the Azure run for PR #19004, buildId 14704, where the change itself is unrelated test-only code). The job builds the entire reactor with -T 3 inside a single -Xmx8g JVM on a memory-constrained Azure agent, so when several heavy module builds align in time the shared heap occasionally exceeds the 8g ceiling and OOMs. The annotation-processor line in the message is only where the allocation tips over, not the root cause.

Summary and Changelog

This scopes a lower build parallelism to just the job that OOMs, without touching any source code or the shared install options used by the other jobs. UT_FT_10's clean install now prepends -T 2 before $(MVN_OPTS_INSTALL) (which contains -T 3). Maven uses the first -T it sees on the command line (verified: -T 2 -T 3 resolves to a thread count of 2, -T 3 -T 2 to 3), so the effective thread count for this job's install becomes 2 while every other job keeps the shared -T 3. Lowering the concurrency from 3 to 2 reduces how many heavy compiles and shade operations can run at the same time, and therefore the peak heap.

The approach was chosen after measuring the heap profile of the full clean install locally: peak heap is about 2.4 GB at -T 1, about 2.4 GB at -T 2, and about 2.9 GB at -T 3, all far below the 8 GB ceiling, which shows the failure is a rare concurrency-driven tail spike rather than a systematic over-use of memory. -T 2 keeps essentially the same wall-clock as -T 3 (about half a minute slower in the local run) while bringing the measured peak heap back down to the -T 1 level. An earlier idea to disable annotation processing on the bundle modules was measured and rejected, because it did not change the compile's heap requirement at all. No code was copied from third-party sources.

Impact

CI-only change scoped to the UT_FT_10 Azure job. No production code, public API, configuration default, or runtime behavior changes. The job's install phase becomes slightly slower (about half a minute in the local measurement) in exchange for lower peak heap; all other CI jobs are unaffected.

Risk Level

none

CI-only change that lowers build parallelism for a single job. It cannot affect build output or test results, and the verified -T precedence guarantees the intended thread count.

Documentation Update

none

Contributor's checklist

• Read through contributor's guide
• Enough context is provided in the sections above

[hudi-agent]

🤖 This review was generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.

No reviewable code files in this PR.

cc @yihua

[hudi-bot]

CI report:

• e8066d3 Azure: SUCCESS

Bot commands

@hudi-bot supports the following commands:

• @hudi-bot run azure re-run the last Azure build