@P_Rat98   Per our PM discussion,  in your flow use DetectDuplicate before sending an email.   This should rate limit the # of messages you send based on your configuration of detectDuplicate.  Additionally when this is linked in your flow, and duplicates are auto-terminated it will drain the flow and stop it from filling up the queue.    Also as suggested you can chose to retain the duplicates, but move them into a much bigger Queue which isnt going to back up the main flow.  Then once you see the email, you can go look at flow, see what flowfiles were causing issues, and take some corrective action.   If you really need to monitor flow for a queue being full,  you would need to use the nifi API to check the status of the queue.  This maybe more work than it is worth, when you can solve as above much easier.  However, i would recommend you check the api out,  there are a lot of api capabilities and I am beginning to use nifi api calls within my flow to monitor, stop, start, and take actions automatically that would normally require a human doing them in the UI.   If this answer resolves your issue or allows you to move forward, please choose to ACCEPT this solution and close this topic. If you have further dialogue on this topic please comment here or feel free to private message me. If you have new questions related to your Use Case please create separate topic and feel free to tag me in your post.   Thanks, Steven ... View more

@P_Rat98 Creating an API with NiFi using HandleHttpRequest and HandleHttpResponse is something I have done quite a few times for Hortonworks and NiFI Customers.  This is a great use case for NiFi and sending receiving JSON to NiFi, processing JSON, and completing actions downstream is super easy.   I have created a basic template for you which includes the HandleHttpRequest (inbound port 80 call) a process group for doing something with the JSON, and HandleHttpResponse (provides 200 response code) to respond to inbound call.    This is an API in the simplest form with NiFi.   Depending on your use case you can build out Process Api Request Process Group to suit your needs.   Out of the box you should be able to send to import template, add/start the StandHttpContextMap Controller Service, Start the flow, send a call to http://yourhost:80 and have JSON sitting in the bottom of the flow Success Queue.   You can find the template here: https://github.com/steven-matison/NiFi-Templates/blob/master/NiFi_API_with_HandleHttpRequest_Demo.xml     Some API suggestions: Be sure to take a look at both HandleHttp Processors for the properties you can configure.  Ports, hostname, acceptable methods, ssl, authentication, and more. If your API call does not care if the Process API Request finishes,  you can put HandleHttpResponse right after HandleHttpRequest, and let all the downstream work happen after the request/response is completed.  This is common when I expect my API to be only giving inbound data, and doesn't care what the response is (other than just 200 to know it was received).  In this case I accept the payload, return 200, and rest of the flow is decoupled from the connection.     If my processing time is lengthy I usually do this so the system initiating the api call is not left waiting. Once you have the basic framework built,  consider handling errors, and or returning different status codes as a variable (created before the response) in the Status Code for Handle Http Response.  Sometimes I even have different HandleHttpResponse at end of different flow branches.  For example:  if someone sends invalid JSON,  I return maybe 302 or 404 with the invalid error as the content body. Have fun with it.       If this answer resolves your issue or allows you to move forward, please choose to ACCEPT this solution and close this topic. If you have further dialogue on this topic please comment here or feel free to private message me. If you have new questions related to your Use Case please create separate topic and feel free to tag me in your post.     Thanks, Steven @ DFHZ ... View more