Mark Deckert created NIFI-4321:
----------------------------------
Summary: Entire UI becomes unresponsive when one GetFile processor
has invalid UNC path
Key: NIFI-4321
URL: https://issues.apache.org/jira/browse/NIFI-4321
Project: Apache NiFi
Issue Type: Bug
Components: Core UI
Affects Versions: 1.3.0
Environment: Windows Server 2012R2, Java 1.8
Reporter: Mark Deckert
* 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
