shashank created CAMEL-26084:
--------------------------------
Summary: 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
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)
