oscerd opened a new pull request, #26734: URL: https://github.com/apache/camel/pull/26734
## What `http:` and `https:` resources are now resolved with a connect and a read timeout instead of waiting forever. Fixes [CAMEL-24756](https://issues.apache.org/jira/browse/CAMEL-24756). ## Why `DefaultResourceResolvers.HttpResource` called neither `setConnectTimeout` nor `setReadTimeout`, and the JDK default for both is `0` — wait indefinitely: ```java URLConnection con = URI.create(getLocation()).toURL().openConnection(); con.setUseCaches(false); setContentType(con.getContentType()); // blocks here, forever ``` Resource resolution usually happens in `doStart()`, on the bootstrap thread. So a slow or black-holed server did not fail the one route — it stalled `CamelContext` startup, with no log line saying what it was waiting for and no way to bound it short of killing the process. A refused connection fails fast on its own, so this only ever appeared against a host that accepts the connection and then goes quiet, which is exactly the case nobody can reproduce locally. Everything resolving through `ResourceHelper` inherited it: `camel-groovy`, `camel-velocity`, `camel-xslt`, `camel-opa`'s `policyBundle`, and the rest. ## How Both timeouts are applied through a single `openConnection()`, used by `exists()` and `getInputStream()` alike — the issue only mentioned the latter, but both blocked. `HttpsResolver` returns the same `HttpResource`, so `https:` was affected identically and is covered by the same change. That was not in the issue text either. Defaults are **10s connect** and **30s read**, overridable through the properties component, with `0` restoring the old behaviour: ```properties camel.resource.http.connect-timeout = 10000 camel.resource.http.read-timeout = 30000 ``` Reading them off the properties component follows `OAuthTokenValidationConfigResolver`, which resolves `camel.oauth.*` exactly this way — it keeps the change inside `camel-base-engine` with no new `camel-main` surface and no generated config metadata. Resolution happens per resource rather than once per resolver, because a resolver is a long-lived service while the properties under it can be reloaded. On the values: there is no single convention to follow here. Across the components, connect timeouts run 10s (`camel-ftp-common`) / 15s (`camel-rest-postman`) / 30s (`camel-a2a`) / 180s (`camel-http`), and read timeouts 30s (`camel-jt400`) / 60s (`camel-azure-functions`) / 180s (`camel-http`) / 300s (`camel-ftp-common`). 10s/30s is chosen for startup safety. The read timeout is **per read**, not for the transfer as a whole, so a large resource arriving slowly over a thin link is unaffected as long as bytes keep coming. ## Testing Four tests against a server that accepts the connection and then writes nothing, which is the only shape that reproduces the problem — pointing at a closed port proves nothing, because a refused connect already fails fast. - `getInputStream()` throws `SocketTimeoutException` - `exists()` surfaces the same timeout as the cause of its `IllegalArgumentException` - an `https:` resource is bounded too, since it shares `HttpResource` - a 404 still reports absent, guarding against the timeouts breaking ordinary responses The `@Timeout` on these is `SEPARATE_THREAD` on purpose. The default mode only measures elapsed time once the method returns and cannot abort a blocked socket read, so a regression would **hang** the build rather than fail it. Found this the hard way while checking the tests actually bite. Removing the two setter calls reddens three of the four (the fourth is the 404 guard, which should pass either way). 21 tests green in `ResourceHelperTest` + the new class. Assertions are JUnit rather than AssertJ to match `ResourceHelperTest` and the rest of that module. ## Scope Behaviour change from "wait forever" to "fail after N seconds", so an upgrade-guide entry is included. The `camel-opa` documentation named CAMEL-24756 as a live caveat for `policyBundle` over `http:`; that paragraph is updated here rather than left stating something this PR makes untrue. Its catalog mirror is updated with it, and a `camel-opa` module build confirms the packaging plugin does not rewrite either. _Claude Code on behalf of @oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
