The long startup times are the result of the number of queued FlowFile that are being recovered/reloaded in to your flow on startup. There is an existing JIRA ticket to address this process. nifi-32. Your out of memory issues are related to the very large number of FlowFile you are loading in to memory for your mergeContent processor. Try splitting that merge process between two different mergeContent processors. First mergeContent merges bundles of 10,000 and the second merges bundles of 100. The end result will still be bundles of 1,000,000; however, the memory impact will be far less.
Matt On Jun 24, 2016 5:29 AM, "ddewaele" <[email protected]> wrote: > I've added a gist > <https://gist.github.com/ddewaele/f84c223fff2c18af4efe3b7fabcab946> to > show you some logging threaddumps of when the issue occurs. In this > particular case I was unable to bring up Nifi .... > > I had to kill my mqtt broker so that the ConsumeMQTT processor wouldn't be > picking up any new messages. > Then I was able to start Nifi and enter the UI. However, I was unable to > stop the ConsumeMQTT processor. (spinning refresh wheel of death). > > There is some activity in the logs but no msgs are processed and ui / api > is > unresponsive. > > nifi.sh dump also doesn't work due to a socket timeout (probably tries to > contact the api). > > > > > > > -- > View this message in context: > http://apache-nifi-developer-list.39713.n7.nabble.com/UI-can-take-a-very-long-time-to-become-available-tp12201p12204.html > Sent from the Apache NiFi Developer List mailing list archive at > Nabble.com. >
