Joe Witt created NIFI-16315:
-------------------------------
Summary: PutUDP should reject oversized FlowFiles before copying
content into a datagram
Key: NIFI-16315
URL: https://issues.apache.org/jira/browse/NIFI-16315
Project: Apache NiFi
Issue Type: Improvement
Reporter: Joe Witt
Assignee: Joe Witt
PutUDP documents that a FlowFile larger than the UDP transport limit (generally
just under 64KB) is marked failed. It never checks size.
onTrigger always copies the entire FlowFile with IOUtils.toByteArray, then
sendEvent. The only oversized handling is whatever Exception the send throws
after that copy. testSendLargeFileInvalid (1 MB) already takes that path: the
array is allocated, send fails, catch Exception routes to failure.
That does not hold for a FlowFile large enough to exhaust the heap. toByteArray
can throw OutOfMemoryError. The catch is Exception, not Throwable, so OOM never
reaches REL_FAILURE and can take down the timer thread.
IPv4 UDP payload cannot exceed 65,507 bytes (65,535 − 8 UDP − 20 IP). A
FlowFile larger than that cannot be a single datagram and should be rejected
using flowFile.getSize() before any content copy.
Proposed change:
- If getSize() exceeds the IPv4 UDP maximum payload, penalize and route to
failure without reading content.
- Keep the existing send-failure path for sizes that are legal for UDP but
still rejected by the local stack (the current tests treat ~32 KB as sendable).
- Do not change hostname/port EL or the Netty sender.
Out of scope:
- Do not add record splitting or delimiter framing. PutUDP is one FlowFile, one
datagram.
- Do not start a campaign to remove toByteArray from other processors.
Tests (TestPutUDP, in-process DatagramSocket):
- FlowFile larger than 65,507 bytes routes to failure. Do not allocate a
multi-GB array in CI; enqueue a modest oversize (e.g. 70 KB) and assert failure
plus that the processor returns without depending on send.
- Existing ~32 KB success path still sends.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
