Github user markap14 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2362#discussion_r159309499
--- Diff:
nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-0-10-processors/src/main/java/org/apache/nifi/processors/kafka/pubsub/PublisherLease.java
---
@@ -71,9 +72,18 @@ void publish(final FlowFile flowFile, final InputStream
flowFileContent, final b
tracker = new InFlightMessageTracker();
}
- try (final StreamDemarcator demarcator = new
StreamDemarcator(flowFileContent, demarcatorBytes, maxMessageSize)) {
+ try {
byte[] messageContent;
- try {
+ if (demarcatorBytes == null || demarcatorBytes.length == 0) {
+ // Send FlowFile content as it is, to support sending 0
byte message.
+ final ByteArrayOutputStream bos = new
ByteArrayOutputStream();
--- End diff --
This is expensive, as it will create a new ByteArrayOutputStream for each
FlowFile, then constantly re-copy that byte array each time that it needs to
expand the internal buffer. Instead, I would suggest we just do something like:
```
byte[] messageContent = new byte[(int) flowFile.getSize()];
StreamUtils.fillBuffer(flowFileContent, messageContent);
```
Even that, though, is going to create a good bit of garbage that we can
avoid. A better approach might actually be to use a BlockingQueue<byte[]> and
call poll() on that. If we get a byte[] back, then use it. If not, then create
a new byte[maxMessageSize] and then use that. At the end, add the byte[] back
to the queue. Then in the close() method clear the queue in case the processor
is re-scheduled with fewer threads. This is nice because it means that we can
avoid constantly creating these byte[] objects, which can cause stress on the
GC.
That being said, if you think it's out of scope for this ticket, I would
recommend just creating the byte[] inline as described above and then we can
create a new JIRA to optimize this.
---
