@s198  If I am following your description correctly, It appears to be working as designed.   The number of retry attempts is set to 3. However, after all retry attempts are exhausted, the process does not complete and ends up queuing in the Retry relationship.   When you set "Retry" on a relationship, it tell NiFi to attempt that many retries before on the component BEFORE routing the FlowFile to the relationship (So FlowFile stays on current inbound connection and you see the hour glass indicating a FlowFile is penalized on that connection).  See in your dataflow InvokeHTTP will retry up to 3 times to process the inbound FlowFile. If processing of the FlowFile results in a "retry" relationship destination, it will get penalized again until configured number of retries completes and the route to "retry" relationship connection.  And that is waht we see happening in your dataflow.  After those three attempts the FlowFile get transferred to "retry" relationship which you have in a connection looping back on the processor.  We then see the hour glass there meaning the 3 reties is happening again.  This will continue forever unless that FlowFile is eventually successful. I think what you really wanted to do is retry 3 times and if all three times result in routing to retry relationship, terminate the FlowFile (delete it).    So in this case you would check both "terminate" and "retry" boxed on the retry relationship.  After 3 unsuccess FlowFile get terminated. If you want to retain the FlowFile after 3 failed retry attempts, don't loop the "retry" relationship back on the processor, but instead route to some other processor for your error handling/notification/etc... 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

@pasq  Did you know that Cloudera makes managing and deploying your MiNiFi agents easy with Cloudera Edge Management?  Our ManagementHub provides a UI to build, deploy and update the dataflow you deploy to one too many MiNiFi agents. You can create parameters for various properties like passwords to provide those at deployment time through Edge Management Check out this Video. NiFi processors with "sensitive" properties are designed to encrypt those password when written to the flow.json.gz.  Even in MiNiFi these component classes will expect that the passwords are encrypted.  The defined sensitive.props.key property value in the minifi.properties or nifi.propertes is used in the encryption/decryption of these sensitive properties stored in the flow.json.gz file. 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

@rajivswe_2k7  The error you shared points to an authorization issue. With a secured (https) enabled NiFi all actions must be performed by an authenticated and authorized user/client. When using the invokeHTTP processor the configured SSL Context service keystore provides the authenticated client via the clientAuth private key entry.   That client is not authorized view on the specific parameter context. So while your user that authenticated into the NiFi UI may be authorized to create and modify a parameter context, that does not mean a processor executed by that user nor inherits some special authorization.     Your client derived from the keystore will need to be authorized to both view and modify the parameter context.  You should check the nifi-user.log for the not authorized action which will show you the client identity which is missing the required authorizations on the parameter context.   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

@hus  Java garbage collection will not kick in until JVM heap usage reaches ~80% usage.  So setting up MonitorMemory reporting task to monitor at 1% is just going to be noisy. Now you are reporting that your NiFi will eventually use the full 32GB of allocated heap memory.  This is most commonly related to one of the following:  A memory leak in a custom processor added to your Apache NiFi install. Creating excessively large FlowFile attributes.  NiFi FlowFiles are held in heap memory (FlowFile attributes/metadata held in heap, FlowFile content is NOT held in heap).  So be careful if anywhere in your dataflow where you may be extracting large amount of content to FlowFile attributes. Leaving FlowFiles accumulated in connections. Since FlowFiles live in heap memory, leaving connections queued with FlowFiles all over your dataflows will consume heap.  Don't use NiFi connections to hold your data, I have seen many datflows where failure relationships connect to a stopped component and the queue has grown large. Poor dataflow design around memory intensive processor components.  The built in usage documentation for each component includes a "resource consideration" section. Just because resource consideration says "MEMORY"  does not always mean it will use a lot of memory. Often it depends on how the processor is configured. (examples: MergeContent , SplitText) Keeping templates (deprecated) stored NiFi.  When you create a NiFi template, the template is written to the flow.json.gz/flow.xml.gz files that also holds everything you see on the canvas.  The flow.json.gz/flow.xml.gz is loaded into heap memory.  Download yoru templates to store off of NiFi and then delete them from internally being stored within NiFi.  Better option is to stop using templates completely.  They were deprecated awhile ago and no longer exist as all in the new Apache NiFi 2.x releases. Using the build in distributedMapCacheServer controller service to store large amounts of cache entries since controller service stores that in NiFi heap memory. While Java Garbage Collection will clean-up unused heap memory, it can not clean-up heap that is still in use.   You can startup your NiFi will all components on the canvas stopped by changing the following property in the nifi.properties to false: nifi.flowcontroller.autoResumeState This will allow you to see what your heap usage looks like from just loading starting up NiFi without anything running yet.  The heap usage would reflect the loading of NiFi (which includes flow.json.gz uncompressed, loading of NIFi nars, and loading of queued FlowFiles). The memory usage should stay relatively flat after all is loaded.   Then starts your dataflows one at a time to see how each impacts heap.    You could also take java heap sumps to analyze what is using the heap (although 32 GB heap would require at least that much free memory somewhere to look a it, so you may want to decrease your heap allocations while troubleshooting).  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

@hegdemahendra  When using the "Defragment" merge strategy, the order of the FlowFiles will not have any affect. Defragment is dependent on the following FlowFile attributes being set on the FlowFiles: Fragment.identifier - For each unique fragment.identifier, the FlowFile will will be allocated to a different bin in mergeContent. fragment.index - This one-up number controls the order in which the content will be merged. fragment.count - This records the total number of splits for this specific fragment.identifier. The MergeContent will only merge a defragmented FlowFile if all fragments are allocated to a bin before the max bin age is reached. The bin age starts the moment the first fragment is allocated to a bin. Lets look at the two scenarios that would result in what you are seeing: Insufficient bins - lets say max bins are set to 18 but you have more then 18 unique fragment.identifiers.  The first 25 FlowFiles that arrive consist of 18 unique fragment.identifiers.  That means that some of those 18 bins have more then one FlowFile associated to them because you have 7 FlowFiles that had a fragment.identifier that matched a fragment.identifier already used for one of the 18 bins.  Lets assume the oldest bin (first to have a FlowFile allocated to it) has 3 of the 25 allocated to it and the next FlowFile to get queued to MergeContent has a totally different fragment.identifier then the first 25.  In this scenario mergeContent is forced to route all FlowFiles allocated to the oldest bin to failure (you would see the ERROR you reported) in order to free up a bin so the FlowFile with the new fragment.identifier could be allocated to a bin.  Now you know that that bins FlowFiles that went to failure still have x number of fragments upstream in your dataflow somewhere that will eventually go to failure as well. Max bin age reached before all fragments are allocated to bin - In this case you have set max num bins high enough to account for all unique fragment.identifiers being binned at same time.  However bin age is set to maybe 60 minutes.  If the time from which the first fragment being allocated to bin reached 60 minutes, all the fragments in that time expired bin will route to failure (you would see the ERROR you reported). I verified both these scenarios on my Apache NiFi 1.26 based NiFi cluster setup. Another thing to consider... flow design. Are you running a NIFi Cluster or a single NiFi instance If clustered, are your redistributed your split FlowFiles across different nodes (maybe using load balanced connections?).  Each node in a NiFi cluster is only aware of the FlowFiles present on that specific node. So if you ends up with some  fragments on different nodes, they will never merge and end up eventually routing to failure because of one of the two scenarios I described. I assume you are not clustered since you stated that waiting for all upstream processing to complete before starting MergeContent it resulted in success. Run schedule: Changing run schedule from 0 sec to 60 sec just controls how often MergeContent gets scheduled to execute (when it executes it allocates FlowFiles from the inbound connection to bins and merges bins eligible to be merged.  With 60 second between scheduled runs it allows more time for upstream to process the fragments, but creates latency in your dataflow of a minute. Increasing concurrent tasks allows for more then one thread to execute at same time for  binning FlowFiles and merge of bins.  From your screenshot, it appears your fragments are small so merging should be pretty quick as evident from the tasks/time in your mergeContent screenshot.  So I don't see this change contributing to any impact. Things you can check and try: Add a funnel before MergeContent and connect that funnel to your MergeContent.  Route your upstream dataflow in to the funnel. Also route the "failure" relationship from MergeContent into the funnel.  this creates a loop where the FlowFiles continuously loop until all fragments successfully arrive and can be binned together for merging.   You may consider adding an updateAttribute (used to set an attribute you can increment with each loop) and routeOnAttribute to your failure loop to create a loop counter that would allow RouteOnAttribute to kick FlowFiles out of the infinite loop after x number of looped attempts. 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

@David26  I am not familiar with this specific processor "Plc4xListenRecordProcessor 0.12.0".   I could not find it in Apache NiFi 1.x or 2.x versions.  I could find it in Maven Central either.  Where did you download this nar that you added to your NiFi? What version of Apache NiFi are you using? You may need to reach out to the originator of this custom nar you have added to you NiFi for this processor specific query. 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

@BuffaloDaddy  You are creating your DBCP Controller service in the wrong location. I see from your attached image you have created your DBCP Controller service from the NiFi Global menu --> Controller Settings --> Management Controller Services. Controller Services create here are for use by Reporting tasks that are also created through this same Controller Settings UI. Controller Service you want accessible to processors on the NiFi canvas must be created on the process group. Child process group(s) will be able to see the controller services of parent process groups unless explicit policy is applied to child Process Group preventing this inheritance. When NiFi is started for the first time, NiFi will create the root Process Group for you (Default Root PG name is " NiFi Flow").    This is the canvas you see when you access the NiFi.  You can access "Controller Services" by right clicking on any unoccupied space on the canvas to bring up a context menu: From this context menu select "Controller Services".  From there you can add controller service to that process group which your processors can use. Please help our community grow and 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

@BuffaloDaddy  What method of user authentication is configured in your NiFi? Single-user ldap-provider Kerberos-provider etc? Thank you, Matt ... View more

@nifier  In order to answer this question, more detail is needed about your NiFi setup. How is your NiFi authentication configured?  Are you authenticating to your secured NiFi via a ClientAuth user certificate, using LDAP/AD, Kerberos, Spnego, etc...? Thank you, Matt ... View more