Re: High CPU usage in FileSystemRepository.java

Adam, thanks for doing all the research and pointing out where the problem is. It is definitely a bug. Joe I’ve raised the https://issues.apache.org/jira/browse/NIFI-1200 Cheers Oleg On Nov 19, 2015, at 1:18 PM, Joe Percivall > wrote:

Re: High CPU usage in FileSystemRepository.java

Hello Adam, Are you still seeing high cpu usage? Sorry no has gotten back to you sooner, we are all working very hard to get 0.4.0 out. Joe - - - - - - Joseph Percivall linkedin.com/in/Percivall e: joeperciv...@yahoo.com On Friday, November 13, 2015 4:10 PM, Adam Lamar

Re: queued files

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

Re: queued files

Charlie, 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]. [1] https://cwiki.apache.org/confluence/display/NIFI/Interactive+Queue+Management Thanks Joe On Thu, Nov 19, 2015 at 10:30 PM, Corey

queued files

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

Re: queued files

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

Re: queued files

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

MergeContent Processor

Hello, I'm a bit confused about the relationship of certain properties of the MergeContent processor. Specifically, how do the properties min entries, max entries, max bin age, max number of bins interact? If the MergeContent processor receives the min number of entries, does it merge without

Re: MergeContent Processor

Elli, Your understanding of the functionality is correct. There are a couple of criteria that drive when a bin is "done." In this case, if you establish the optional maximum properties, these drive in closing out sooner. That is if a max age is specified, and any of the bins have gone beyond