[ 
https://issues.apache.org/jira/browse/NIFI-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684402#comment-15684402
 ] 

ASF GitHub Bot commented on NIFI-2996:
--------------------------------------

Github user markap14 commented on the issue:

    https://github.com/apache/nifi/pull/1192
  
    @mosermw I reviewed the code and all looks good. I test with GetFile. 
Ensured that it was invalid when pointing to a directory that didn't exist. 
Created directory and refreshed status and saw that it was now valid. Start the 
processor, verified that it worked. Then deleted the directory and saw 
bulletins appear. Stopped Processor and saw the processor now shows as invalid, 
as expected. I'm a +1 but will hold off on merging until @mcgilman has a chance 
to review and/or comment, since he performed the original review. Thanks for 
digging in here!


> Processor/Service validation takes exponentially longer to run as the graph 
> grows
> ---------------------------------------------------------------------------------
>
>                 Key: NIFI-2996
>                 URL: https://issues.apache.org/jira/browse/NIFI-2996
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 1.0.0, 0.7.1
>            Reporter: Michael Moser
>            Assignee: Michael Moser
>
> As you add processors that reference controller services to your NiFi, the 
> validation that occurs during normal UI usage increases dramatically.
> When running in a cluster, I have to increase the nifi.properties 
> nifi.cluster.node.read.timeout well beyond its 5 sec default timeout in order 
> for the UI to work.  Eventually, simple operations in the UI take close to a 
> minute to happen.
> As a test, I created an SSLContextService using certs created with the 
> amazingly useful nifi-toolkit.  I created a DistributedMapCacheClientService 
> that references this SSLContextService.  Then I created 108 
> FetchDistributedMapCache processors that reference the 
> DistributedMapCacheClient service. I used ${hostname(true)} for my 
> FetchDistributedMapCache processor's Cache Entry Identifier property.
> When NiFi is up with no UI connected, during a single "NiFi status" phase I 
> noticed that the SSLContextService was validated 108 times and the EL 
> hostname(true) was evaluated 216 times.  When I connect the UI and go through 
> a normal status refresh cycle, the SSLContextService was validated 432 times 
> and the EL hostname(true) was evaluated 864 times. These validations take a 
> full second on my slowest machine.
> In NiFi 0.x, the expensive REST API call is 
> /nifi-api/controller/controller-services/node.
> In NiFi 1.x, it appears to divide the work among REST API calls to 
> /nifi-api/process-groups/UUID and 
> /nifi-api/flow/process-groups/UUID/controller-services and 
> /nifi-api/flow/status
> Rather than attempting to fix StandardSSLContextService or the EL 
> HostnameEvaluator, I wonder if there was a more generic approach to helping 
> resolve this?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to