[
https://issues.apache.org/jira/browse/NIFI-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16140629#comment-16140629
]
Matt Gilman edited comment on NIFI-4321 at 8/24/17 8:24 PM:
------------------------------------------------------------
I believe the unresponsiveness was due to lengthy validation. In this case,
likely the directory exists validator. Linking to an outstanding JIRA
(NIFI-950) to make all validation happen asynchronously.
was (Author: mcgilman):
I believe the unresponsive was due to lengthy validation. In this case, likely
the directory exists validator. Linking to an outstanding JIRA (NIFI-950) to
make all validation happen asynchronously.
> 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
> Labels: rest, slow, status, ui, unresponsive, web, windows
>
> * 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)
