build: Fix py3-sdk maven dependency

[mc-nv]

What does the PR do?

Fixes two failure modes in the py3-sdk client/SDK image build (Dockerfile.sdk):

1. Maven dependency resilience. Replaces the wget fetch of Apache Maven (which flaked with exit code: 4 / Network is unreachable against archive.apache.org) with curl -fSLk --retry 3, and switches the pinned version to a full URL build-arg (JAVA_BINDINGS_MAVEN_URL, Maven 3.9.16) that CI already points at the internal Artifactory mirror. The extracted dir is resolved with a glob-based symlink and the install is verified with mvn --version.
2. Build OOM. Caps client-build parallelism at --parallel 16. A bare cmake --build --parallel emits an unbounded make -j, which spawned one cc1plus per ready gRPC translation unit (1–2+ GB each) and tripped the OOM killer (cannot allocate memory). 16 matches the RHEL Dockerfile's existing -j16.

Checklist

• PR title reflects the change and is of format <commit_type>: <Title>
• Changes are described in the pull request.
• Related issues are referenced.
• Populated github labels field
• Added test plan and verified test passes.
• Verified that the PR passes existing CI.
• Verified copyright is correct on all changed files.
• Added succinct git squash message before merging.
• All template sections are filled out.
• Optional: Additional screenshots for behavior/output changes with before/after.

Commit Type:

• build

Related PRs:

N/A — server-only change.

Where should the reviewer start?

Dockerfile.sdk — the "Install Maven 3.9+ manually" block (ARG JAVA_BINDINGS_MAVEN_URL + the curl … | tar | ln -s | mvn --version RUN) and the client build RUN … cmake --build . -v --parallel 16 ….

Test plan:

• Rebuild py3-sdk and confirm the Maven step pulls 3.9.16 from Artifactory and mvn --version succeeds. Verified in pipeline 59299689 (py3-sdk green — Maven step + capped client build both pass).

• Confirm the client build no longer OOMs on the dl325g11-* builder class.

• CI Pipeline ID: 59299689

Caveats:

curl -k skips TLS verification for the tarball fetch (retains prior lenient behavior on the internal build network); --retry 3 absorbs transient drops. The credentialed JAVA_BINDINGS_MAVEN_URL build-arg is not exposed in the published image (multi-stage build discards the sdk_build stage history — verified against the built SDK image).

Background

CI py3-sdk / py3-sdk-rhel intermittently failed fetching apache-maven from archive.apache.org (wget … exit code: 4), and py3-sdk separately OOM'd during the gRPC client compile. This makes both steps resilient.

Related Issues:

• Resolves: TRI-1621

^{CI (internal): [#59299689](http://tritonserver.local/ci/pipelines/59299689)}

[mc-nv]

@greptileai

[greptile-apps]

Greptile Summary

This PR hardens the py3-sdk Dockerfile against two intermittent CI failures: a flaky wget fetch of Apache Maven is replaced with curl -fSLk --retry 3 plus a BuildKit secret override, and a bare --parallel CMake build argument (which spawned unbounded compiler processes) is replaced with a capped TRITON_CLIENT_BUILD_PARALLEL build-arg defaulting to 4.

• Maven download: JAVA_BINDINGS_MAVEN_URL now carries a full URL default (3.9.16) and can be overridden via a BuildKit secret; the extracted directory is located with a find glob and verified with mvn --version. However, the top-level ARG JAVA_BINDINGS_MAVEN_VERSION=3.9.9 was removed while line 149 still consumes ${JAVA_BINDINGS_MAVEN_VERSION} (passed to install_dependencies_and_build.sh) with no fallback — any build that omits --build-arg JAVA_BINDINGS_MAVEN_VERSION=... will silently pass an empty value to the script.
• Build parallelism: TRITON_CLIENT_BUILD_PARALLEL is declared with a default of 4, but the PR description claims the default is 16 (to match the RHEL Dockerfile's -j16); the mismatch should be resolved.

Confidence Score: 4/5

Safe to merge once the JAVA_BINDINGS_MAVEN_VERSION default gap is resolved — any build omitting that build-arg will pass an empty value to install_dependencies_and_build.sh and fail at the Java bindings step.

The Maven URL migration and curl retry logic are sound. The build-parallelism cap is a reasonable OOM guard. The main concern is that the top-level ARG JAVA_BINDINGS_MAVEN_VERSION=3.9.9 was removed while the same variable is still declared without a default in sdk_build (line 118) and consumed without a guard at line 149.

Dockerfile.sdk — specifically lines 118 and 149 where JAVA_BINDINGS_MAVEN_VERSION is declared without a default and then forwarded to install_dependencies_and_build.sh.

Important Files Changed

Filename	Overview
Dockerfile.sdk	Replaces wget Maven fetch with curl+retry and secret-based URL override, adds capped build parallelism via TRITON_CLIENT_BUILD_PARALLEL; JAVA_BINDINGS_MAVEN_VERSION retains no default while still being consumed at line 149, which will cause a build failure on any build that doesn't supply the build-arg explicitly.

_{Reviews (7): Last reviewed commit: "build: Lower limit of the parallel threa..." | Re-trigger Greptile}