[
https://issues.apache.org/jira/browse/CAMEL-26084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-26084:
--------------------------------
Fix Version/s: 4.24.0
> camel-vertx-http - an exchange in flight when the CamelContext stops is never
> completed (the caller waits for ever)
> -------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26084
> URL: https://issues.apache.org/jira/browse/CAMEL-26084
> Project: Camel
> Issue Type: Bug
> Components: camel-vertx-http
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> When the CamelContext stops while a vertx-http request is in flight (the
> graceful shutdown timeout runs out, or an application stops its context
> during a slow call), the exchange is never completed: {{callback.done}} is
> never called and the caller waits for ever (a {{ProducerTemplate}} request,
> an upstream synchronous consumer, a scheduled job thread). netty-http and
> undertow fail such an exchange within about a second of the stop.
> Root cause (main 6a2f66ddec3e, checked with logging in the result handler):
> {{VertxHttpEndpoint.doStop}} (line 136) closes the {{WebClient}}; Vert.x
> fails the pending request with {{HttpClosedException: Connection was closed}}
> and calls the result handler of {{VertxHttpProducer}} on its event loop. By
> then {{VertxHttpComponent.doStop}} (line 251) has set its {{vertx}} field to
> null (also for a Vert.x it does not manage), so
> {{getEndpoint().getVertx().executeBlocking(...)}} in {{createResultHandler}}
> (line 168) throws a {{NullPointerException}} inside the Vert.x handler, and
> the task that calls {{callback.done(false)}} is never submitted.
> *Fix*: take the Vert.x when the request is sent, not when its result arrives,
> so the task that completes the exchange is still submitted. A worker pool
> that is already shut down refuses the task: Vert.x 5.2.1 fails its future and
> throws the {{RejectedExecutionException}}, so the handler catches it (and has
> an {{onFailure}} on the future) and completes the exchange with it, once.
> *Tests*: new {{VertxHttpStopDuringCallCompletesTest}}, 3 tests: stop with the
> Vert.x managed by the component and with a Vert.x from the registry, both
> fail on main with {{expected: <java.util.concurrent.ExecutionException> but
> was: <java.util.concurrent.TimeoutException>}} (with the fix the reply fails
> with {{HttpClosedException}}); a worker pool shut down before the answer
> arrives, which times out the same way without the second part of the fix (the
> reply then fails with {{RejectedExecutionException}}). camel-vertx-http unit
> tests with the fix: 111 run, 0 failures, 1 skipped.
> *How it was found*: an exactly-once completion check of async producers on
> the path "stop during the call".
> *Affected*: main, camel-4.22.x, camel-4.18.x and camel-4.14.x (same code).
> Read, not run.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
