[NIFI-4321] Entire UI becomes unresponsive when one GetFile processor has invalid UNC path

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.3.0
• Component/s: Core UI
• Labels: rest slow status ui unresponsive web windows
• Environment: Windows Server 2012R2, Java 1.8
• Assignee: Unassigned
• Reporter: Mark Deckert
• Created: 24/Aug/17 19:43
• Updated: 24/Aug/17 20:24

Description

• 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.

Issue Links

• relates to: NIFI-950 Perform component validation asynchronously