@ALWOSABY  This looks related to the driver version you may be using in the processor.  Perhaps trying a different driver version may resolve you issue.  Perhaps try ojdbc6 version 11.1.0.7.0? Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@jame1997  Not much to look at from a NiFi side. NiFi is writing to the network successfully and there is some loss then happening between NiFi and your syslog server.   Resource usage affecting your NiFi would only slow down processing but not result in dataloss within NiFi.  So the PutSyslog would successfully write all bytes to the network before passing the FlowFile to the "success" relationship.  Using TCP of course would allow NiFi to confirm successful delivery thus allowing NiFi to appropriately retry, or route to either failure or success relationships. You could look at the data rate NiFi is writing from the putSyslog by looking at the stats on the processor.  Then maybe you could experiment with: 1. netstat - nsu to check for UDP packet loss.   2. using a network monitoring tool Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@TreantProtector  Everything the user adds to the canvas including controller service and reporting tasks are auto-saved in the flow.json.gz.  Each time a change is made the current flow.json.gz is archived and new flow.json.gz is generated.   Within the flow.json.g are all components (processors, connections, controller services, reporting tasks, funnels, process groups, ports, parameters, etc.)  and their configurations.  Any configuration property that is "sensitive" (passwords) are going to be encrypted in the flow.json.gz file.  So in order to load that flow.json.gz in another NiFi, you would need to know the nifi.sensitive.props.algorithm and nifi.sensitive.props.key used by the original NiFi which it came from. Encrypted Passwords in Flows If you don't have that info, the flow.json.gz can still be loaded on another NiFi after manually editing the file to remove all the "enc{...}" values.  Once flow.json.gz loads, an authorized user would need to re-enter all passwords in all components where it is needed via the NiFi UI. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@jpalmer From the image you shared the bottleneck is actually in the custom non Apache NiFi out-of the-box PutGeoMesa 4.0.4 processor.  A connection has backpressure settings to limit the amount of FlowFiles that can queue be queued (it is a soft limit which means back pressure gets applied once Connection backpressure threshold is reached or exceeded).  Once backpressure is applied it will not be release until queue drops back below the configured thresholds.  Backpressure when applied prevents the upstream processor from being scheduled to execute until that backpressure is removed.  The connection turns red when backpressure is being applied and since the connection after PutGeoMesa 4.0.4 is not red, no backpressure is being applied on that processor.  So you issue is the PutGeoMesa 4.0.4 is not able to process the FlowFiles being queued to it fast enough thus causing the backup in every upstream connection leading to the source processor.  Since it is a custom processor I can't speak to its performance capabilities or tuning capabilities.   I also don't know it the PutGeoMesa 4.0.4 processor will support concurrent executions either, but you could try: If you right click on the PutGeoMesa 4.0.4 processor and select configure, you can select the SCHEDULING tab.  Within the Scheduling tab you can set "CONCURRENT TASKS".  The default is 1 and this custom processor might ignore this property.  What concurrent task does is allow the processor execute multiple times concurrently (so think of it as for each additional concurrent task, you are creating another identical processor).  A processor component is scheduled to request a thread to execute base on the configured Run Schedule (for Timer Driven Scheduling Strategy the default 0 secs means schedule as fast as possible).  So when it is scheduled the processor request a thread from the NiFi Timer Driven thread pool. That thread is then used to execute the processors code against a source connection FlowFile(s).  The scheduler will the try to schedule it again based on run schedule and if concurrent task is still set to 1 and the previous execution is still running.  it will not execute again until the in use thread finishes.  But if you set concurrent tasks to say 3, the processor could potentially execute 3 threads concurrently (each thread working on different FlowFile(s) from source connection).   Again I don't know if this custom processor will ignore this property or support it.  Nor do I know if this processor was coded in a thread safe manor meaning that concurrent thread executions would not cause issues. so even if this appears to improve throughput, verify your data integrity coming out of the processor. Also keep in mind that adding concurrent tasks to a processor (especially a processor like this that appears to have long running threads. We can see it only processed 23 FlowFiles using 4.5 minutes of CPU time which is pretty slow) can quickly lead to this processor using all the available threads from the Max Timer Driven Thread pool resulting in other processors appearing to perform slower as they get an available thread to execute less often.  You can increase the size of the Max Timer Driven Thread pool from the NiFi global menu in upper right corner, but need to do so carefully while monitoring CPU load average and memory usage as you slowly increase the setting. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more