shashank created CAMEL-25154:
--------------------------------
Summary: camel-vertx-http - a file body that is not a local
java.io.File (such as a file from ftp, sftp or smb) is never sent and the
exchange never completes, so the route hangs (regression of CAMEL-22044)
Key: CAMEL-25154
URL: https://issues.apache.org/jira/browse/CAMEL-25154
Project: Camel
Issue Type: Bug
Components: camel-vertx-http
Reporter: shashank
Since CAMEL-22044 (4.12.0) {{VertxHttpProducer.process}} handles file bodies in
their own branch (line numbers of main):
{code:java}
if (body instanceof File || body instanceof WrappedFile) { // :98
File file = message.getBody(File.class); // :100
if (file != null) { // :101
... request.sendBuffer(buf, resultHandler) or sendMultipartForm(...)
}
}
...
return false; // :154
{code}
When the body is a {{WrappedFile}} that cannot be converted to a
{{java.io.File}}, {{file}} is null: nothing is sent, the callback is never
called, and {{process}} returns false (continue asynchronously). The exchange
never completes.
This is the case for the remote file consumers without {{localWorkDirectory}}:
camel-ftp (FTP, FTPS, SFTP) and camel-smb put a {{RemoteFile}} on the message
whose content is already downloaded as {{byte[]}} (or an {{InputStream}} with
{{streamDownload=true}}); {{GenericFileConverter}} has no converter from those
to {{File}} and returns null. Before 4.12.0 such a body went through
{{getMandatoryBody(Buffer.class)}} and was sent.
Effect: {{from("sftp:...").to("vertx-http:https://...";)}} (download and upload
by HTTP) never sends the first file. The exchange stays inflight, the calling
thread waits for it (for a polling consumer such as sftp the consumer thread
blocks, so the route stops polling), and a graceful shutdown waits for the full
timeout.
h3. Reproduction
A local Vert.x HTTP server counts the requests; route
{{from("direct:in").to("vertx-http:http://localhost:port/upload?httpMethod=POST";)}};
the exchange is sent with {{asyncSend}} and awaited for 5 s:
* body a {{GenericFile}} whose file handle is not a {{java.io.File}} and whose
content is {{byte[]}} (what the ftp/sftp consumers produce): not completed
after 5 s, 0 requests at the server, inflight 1. 3 of 3 runs, and 5 of 5 in a
loop;
* controls: a {{GenericFile}} of a local file, and a {{byte[]}} body:
completed, response 200, 1 request each.
h3. Proposed fix
Add the missing else branch: when the file body cannot be converted to a
{{File}}, send its content ({{getMandatoryBody(Buffer.class)}}), as a multipart
file upload with the {{CamelFileNameOnly}} header as the file name
({{multipartUploadName}} when the header is missing) when
{{multipartUpload=true}}, else as a buffer. Any conversion failure then
completes the exchange with the exception through the existing catch block.
With the fix the remote-file case completes with response 200 and the server
receives the 12 bytes of content (3 of 3); the controls are unchanged. A test
with a {{GenericFile}} body with {{byte[]}} content, sent as a plain body and
as a multipart upload, times out without the fix and passes with it; the
camel-vertx-http tests pass (95 tests, 1 skipped).
Affected: 4.12.0 and later (the branch is not at camel-4.11.0; it is at 4.12.0,
4.13.0, 4.14.0, 4.18.0, 4.22.0 and main).
Duplicate check (2026-09-30): JIRA component camel-vertx-http since 2024 (15
issues: SSL, header filter, tracing, CAMEL-22044 multipart upload), text
"vertx-http" with "file" (44, none about a remote file body or a hang); GitHub
pull requests "VertxHttpProducer", "vertx-http WrappedFile", "vertx-http file
upload": none.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
