[
https://issues.apache.org/jira/browse/NIFI-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15645600#comment-15645600
]
Michael Moser commented on NIFI-2996:
-------------------------------------
Is there much value in validating processor properties while that processor is
RUNNING or DISABLED? The properties on a running processor should always be
valid, else you should not have been able to start the processor. A disabled
processor doesn't show validation results, so it seems a waste to validate its
properties
I ran a test that would only do processor validation if (getScheduledState() ==
ScheduledState.STOPPED) in the framework StandardProcessorNode. This seemed to
have no ill effects on the UI and, as long as processors are running or
disabled, didn't scale up validation costs.
Thoughts?
> 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, 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)
