[
https://issues.apache.org/jira/browse/NIFI-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15657839#comment-15657839
]
Joseph Witt commented on NIFI-2996:
-----------------------------------
[~mosermw][~mcgilman] is unclear what the resolution here is but want to flag
this to get the fix version removed or understand when it will be resolved.
trying to close down the 1.1.0 release
> 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
> Fix For: 1.1.0
>
>
> 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)