[ppkarwasz]

What

Adds a job-level timeout-minutes: 30 to the test job in the Java CI workflow.

Why

The test job had no timeout, so a hung or deadlocked test runs until GitHub's 6-hour default before the job fails (as seen on #57, where a test got into a deadlock). The purpose of the cap is only to prevent such runaway builds, so 30 minutes leaves ample margin for the slowest matrix cells. The current slowness of the Ubuntu jobs is addressed separately in #93.

The cap is job-level, so it applies to every OS/JDK matrix combination. When it fires, the if: always() "Upload test reports" step still runs, preserving whatever surefire output exists to help locate the hang.

🤖 Generated with Claude Code

[the-thing]

I fixed the root cause of these long hanging macos tests in a separate PR, but this is a good change just in case something similar happens in the future.

Rationalizing in the comment is not necessary.

[the-thing]

15 timeout might not be valid anymore. We added some more tests in #77 and it takes almost (sometimes more) 15 minutes.

https://github.com/apache/mina/actions/runs/37960280693/job/113921075461

Ubuntu runners seem to be a lot slower than Windows / Mac.

[ppkarwasz]

Hi @the-thing,

The slow run on Linux is probably due to its TCP/IP stack, fixed in #93 by adding TCP_NO_DELAY.

That said, what would a reasonable timeout be? 30 minutes?

[elecharny]

Ubuntu/debian seems to have a weird way to handle small packet of data. Enabling the NAGLE algorithm does not seems necessary those days, but well, the test you have modified sends 4096 packet of 4 bytes, so I guess it takes a bit of time.

Setting the timeout to 30mins sounds reasonable.

[the-thing]

Too late.

# Prevent runaway builds from running until the 6-hour GitHub default. - this comment was probably too obvious, but ok.

[elecharny]

Yeah... But the next one will be ok ;-)