Is there a way to enable a stateful status update from a NIFI processor

[#1]

I have a flow running. The start of the flow is a GetHTTP. There seems to be no way to know where the flow is. Though the processor is active, its not clear if it attempts to access the URL, or if it is in the process of uploading the file from the URL.

Though I've set the Bulletin level to DEBUG, I simply dont get any useful state feedback from such a simple NIFI processor (GetHTTP should have very obvious states - e.g. connecting, uploading, waiting, etc).

I'd think that NIFI processors are designed to provide stateful feedback as to their current optional state. Is this possible, or is it simply missing from the design of NIFI?

Thanks in advance.

[#2 · Accepted solution]

Once a processor is started it is then running according to its configured schedule. For example, Run Schedule of 5 seconds means it is executed every 5 seconds. Depending on the processor, each execution may produce one or more flow files that are transferred to a relationship, or it may produce an error which is reported by a bulletin which shows a red error in the corner of the processor. So generally you should either be seeing flow files being transferred to one of the relationships, or bulletins.

[#3]

Thank You.

Yes.. i do know what you highlight.. and of course the GetHTTP processor behaves in exactly the way you describe.

What it does not do is provide me status about its progress. For example (having built many HTTP interfaces - in many languages) its relatively easy to keep track of the number of bytes that you've uploaded so far... its easy to keep track of the fact that you've gotten access to the upload URL (and begun the upload).

What I don't see is "status information" from the GetHTTP processor that would allow me to know where it is in its lifecyle: its progress towards completion of the "get". The DEBUG or INFO bulletins dont provide this.. I guess the answer is that whether or not there is adequate detail within a bulletin is up to the specific processor. I am guessing that some processors have more useful INFO and DEBUG bulletins than others.

[#4]

Yes it is up to the processor to decide what to log, the framework doesn't really know what the processor is doing.

In this case, the stuff that you would see in the log would be all the calls to the logger here:

https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-proce...

I suppose some logging statements could be added around the call to client.execute() but I'm not sure how you'd get more info about what the execute call is doing, you would just know it started or completed.

[#5]

Ty @Bryan Bende. That is sensible answer.. the follow-up comment also makes sense. I do think that even with the GetHTTP processor.. just knowing when the process has begun is useful.. indeed i'd think thats useful detail from any processor. I'd think that a DEBUG bulletin at the right level.. could provide that for any processor. Perhaps its already there and I just missed it.