Bound MSSQL testcontainer startup and retry on transient crashes

[AlexeyKuznetsov-DD]

What Does This Do

Adds .withStartupTimeoutSeconds(120), .withConnectTimeoutSeconds(120) and .withStartupAttempts(2) to the MSSQLServerContainer in RemoteJDBCInstrumentationTest.

Motivation

The SQL Server container occasionally crashes on startup in CI (exited with code 139 / SIGSEGV). JdbcDatabaseContainer defaults to a single 240s connection wait, so one bad container burned ~4-5 min per case and blew the :jdbc:forkedTest 20-min timeout. Splitting the same 240s budget into two 120s attempts retries with a fresh container, so a transient crash recovers instead of failing the whole run.

[dd-octo-sts]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b1f96c3189

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep MSSQL's 240-second startup window

On slow or cold CI runners where SQL Server needs more than 120s but less than the previous MSSQLServerContainer 240s default to accept JDBC connections, this now fails both attempts: withStartupAttempts(2) restarts from a fresh container after the first timeout, so the second attempt loses all progress rather than continuing the original startup. That makes the previous 240s success window unavailable and can turn slow-but-valid MSSQL starts into deterministic test failures.

Useful? React with 👍 / 👎.

[AlexeyKuznetsov-DD]

Good catch. That is actually I'm investigating. If those 120 seconds will be a problem I will revert.

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.02 s	13.94 s	[-0.1%; +1.2%] (no difference)
startup:insecure-bank:tracing:Agent	12.88 s	12.99 s	[-1.7%; -0.0%] (maybe better)
startup:petclinic:appsec:Agent	16.91 s	16.87 s	[-0.7%; +1.2%] (no difference)
startup:petclinic:iast:Agent	16.82 s	16.91 s	[-1.5%; +0.3%] (no difference)
startup:petclinic:profiling:Agent	16.73 s	16.88 s	[-2.1%; +0.4%] (no difference)
startup:petclinic:sca:Agent	16.89 s	16.06 s	[+1.0%; +9.4%] (maybe worse)
startup:petclinic:tracing:Agent	16.05 s	16.06 s	[-0.9%; +0.8%] (no difference)

Commit: b1f96c31 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.