This ERROR messages is informing you that the configured buffer in your putKafka processor was not large enough to accommodate the batch of files it wanted to transfer to Kafka. So the log above shows that a batch of 3 files was created, 2 of the files from that batch transferred successfully, and 1 file was routed to the putKafka's failure relationship. The total size of the batch was recorded as 4294967296 (4GB). These are very large files for Kafka... The Failure relationship should be looped back on to the putKafka processor so after a short penalization, the failed file will get re-transmitted. There are 4 settings at play here in the putKafka processor you will want to play around with. Max Buffer Size: <-- max amount of reserved buffer space Max Record Size: <-- max size of any one record Batch Size: <-- max number of records to batch Queue Buffering Max Time: <--- max amount of time spent on batching before transmitting. *** The batch will be transmitted when either the Batch Size is satisfied or Queue Buffering Max time is reached. Considering the size of the messages you are trying to send to your Kafka topic, I would recommend the following settings: Max Buffer Size: 2 GB Max Record Size: 2 GB Batch Size: 1 Queue Buffering Max Time: 100 ms Since you will be sending one file at a time, you may want to increase the number of Concurrent Tasks configured on the "Scheduling" tab of the putKafka processor. Only do this if the processor can not keep up with the flow of data. So start with the default of 1 and increase by only 1 at a time if needed. Keep in mind that the buffered records live in your JVM heap, so the the more concurrent tasks and the larger the Max Buffer Size configuration, the more heap this processor will use. Thanks, Matt ... View more

There is no direct correlation between the size of the content repository and the provenance repository. The size the content repository will grow to is directly tied to the amount of unique content that is currently queued on the NiFi canvas. If archive is enabled the amount of content repository space consumed will depend on the archive configuration settings in the nifi.properties file. nifi.content.repository.archive.max.retention.period=12 hours nifi.content.repository.archive.max.usage.percentage=75% nifi.content.repository.archive.enabled=true As you can see from the above archive will try to retain 12 hours of archived content (archived content being content that is no longer associated to an existing queued FlowFile on within any dataflow on the graph. This does not guarantee that there will be any archive or that the content repository will not grow beyond 75% disk utilization. Content still actively associated to queued FlowFiles will remain in the Content repository. So it is important to build in back pressure in to dataflows where there is concern that large backlogs could trigger disk to fill to 100%. Should Content repo fill to 100% corruption will not occur. New FlowFiles will not be able to be created until free space is available. This is likely to produce a lot of errors in the flow (anywhere content is modified/written). Provenance repository size is directly related to the number of FlowFiles and the number of event generating processors those events pass through on the NiFi canvas. In the case of disk utilization here, it is very controlled by setting in the nifi.properties file: nifi.provenance.repository.max.storage.time=7 days nifi.provenance.repository.max.storage.size=50 GB With the above settings, NiFi will try to retain 7 days of provenance events on every FlowFile that it processes, but will start rolling off the oldest events once the max storage exceeds 50 GB. It is important to understand that the 75% and 50GB are soft limits and should never be set to 100% or the exact size of the disk. FlowFile Repository and database repository each remain relatively small. The FlowFile repository is the most important repo if all. It should be isolated on a separate disk/partition that is not shared with any other process that may fill it. allowing the FlowFile repository disk to fill to 100% can lead to database corruption and lost data. for a 200 GB Content repository, a ~25 GB FlowFile repo should be enough. The database repository contains the user and change history DBs. The user db will remain 0 bytes in size for NiFi instances running http (non-secure). For those instances running https (Secure), the user db will track all users who log in to the UI. The change history db is tied to the little clock icon in the upper right corner NiFi tool bar. It keeps track of all changes made on the NiFi graph/canvas. It also stays relatively small. A few GB of space should be plenty to store a considerable number of changes. ... View more

I am assuming you are using the InvokeHTTP processor and that you want to use one of the new attributes created on your FlowFile in response to the request for adding to the content of the same Flowfile. You will want to make sure you have the "Put Response Body in Attribute" property configured in the InvokeHTTP processor. You can then use the ReplaceText processor with an Evaluation Mode of Entire text and Replacement Strategy of Append. This will allow you to write a NiFi Expression Language statement that uses the attribute you specified for the response body containing the return and append it to your original json content. ... View more