nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <>
Subject Re: queued files
Date Fri, 20 Nov 2015 03:33:47 GMT

The fact that this is confusing is something we agree should be more
clear and we will improve.  We're tackling it based on what is
mentioned here [1].



On Thu, Nov 19, 2015 at 10:30 PM, Corey Flowers <> wrote:
> These guys are right. The file to look in for the uuid is the nifi-app.log.
> Also if you wanted to see what the processor itself was doing, you could
> right click on the processor, get its uuid and while it is running, run
> (assuming it is on Linux):
> tail -F nifi-app.log | grep uuid
> This will just scroll the logs for that specific processor and will show you
> what it is doing. It should also tell you specific file names and uuids of
> the failing files.
> Hope that helps! Have a great night and good luck!
> Sent from my iPhone
> On Nov 19, 2015, at 9:27 PM, Juan Sequeiros <> wrote:
> You can also check the NiFi logs for a searchable id or for what the
> previous processor ID produced to help search provenance.
> On Nov 19, 2015 21:22, "Bryan Bende" <> wrote:
>> Charlie,
>> The behavior you described usually means that the processor encountered an
>> unexpected error which was thrown back to the framework which rolls back the
>> processing of that flow file and leaves it in the queue, as opposed to an
>> error it expected where it would usually route to a failure relationship.
>> Is the id that you see in the bulletin a uuid?
>> There should still be some provenance events for this FlowFile from the
>> previous points in the flow. If it looks like the uuid of the FlowFile, that
>> should be searchable from provenance using the search button on the right.
>> Let us know if we can help more.
>> -Bryan
>> On Thu, Nov 19, 2015 at 9:10 PM, Charlie Frasure
>> <> wrote:
>>> I have a question on troubleshooting a flow.  I've built a flow with no
>>> exception routing, just trying to process the expected values first.  When a
>>> file exposes a problem with the logic in my flow, it queues up prior to the
>>> flow that is raising the bulletin.
>>> In the bulletin, I can see an id, but can't tell which file it is.  Data
>>> provenance doesn't seem to help as it passed the flow on the last processor,
>>> but hasn't been logged (to my knowledge) on the next one.
>>> Is there a way to match the bulletin back to a file without creating a
>>> route for failed files?

View raw message