Uploaded image for project: 'Apache NiFi'
  1. Apache NiFi
  2. 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
    • Fix Version/s: None
    • Component/s: Core UI
    • Environment:
      Windows Server 2012R2, Java 1.8


      • 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



              • Assignee:
                mdeckert Mark Deckert
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: