- NiFi is running on a Windows server
- As part of a demo workflow I had a GetFile processor set up watching a given cifs share on a NetApp via UNC path.
- The processor is "stopped" but not "disabled". It was kept around as an example.
- The share was then deleted on the file server (but file server still exists)
- After this, the entire GUI become nearly unresponsive, taking minutes to display the canvas or refresh status.
- In chrome dev tools, it appears that calls to the REST endpoint "https://nifiserver1/nifi-api/flow/status" would take several minutes to complete.
- Other REST calls may have been stalling, but this hasn't been confirmed yet. Some REST calls were perfectly fine, like https://nifiserver1/nifi-api/access
- Resolution was to disable the problem processor, after which the GUI again behaved normally.
NiFi is awesome otherwise but this could be a showstopper for us. Obviously modified user behavior can avoid the issue, but in a multiuser environment it becomes a serious problem. In this case, the processor hadn't been modified for months before the share was removed. It took a significant amount of time to track down and correct since there were multiple teams involved and the non-intuitive behavior of a "stopped" processor deep in a process group hierarchy suddenly affecting the entire UI for all users.