[
https://issues.apache.org/jira/browse/NIFI-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Yang updated NIFI-7005:
----------------------------
Environment:
centos 7
cpu 16cores
memory 64G
3 nifi nodes java heap 32G
was:
cenots 7
cpu 16cores
memory 64G
3 nifi nodes java heap 32G
> nifi process maybe crash while call controller-services api
> DBCPConnectionPoolLookup associate a great many jdbc pool
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-7005
> URL: https://issues.apache.org/jira/browse/NIFI-7005
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Core UI
> Affects Versions: 1.9.0
> Environment: centos 7
> cpu 16cores
> memory 64G
> 3 nifi nodes java heap 32G
>
> Reporter: Paul Yang
> Priority: Major
>
> have a DBCPConnectionPoolLookup associate a great many (for our environment
> 170+) DBCPConnectionPool configurations.
> nifi.properties:
> nifi.cluster.node.read.timeout=600 sec
> nifi.cluster.node.connection.timeout=600 sec
> nifi.ui.autorefresh.interval=300 sec
> While call controller-services rest api from anyway included clicking
> ProgressGroup's GUI configure menu, nifi node that called one's CPU and
> memory surge even process crash.
> Fortunately, the jdbc lookup service's function is unaffected. But for the
> amazing function the behavior should be perfect.
> The root cause is: 'controller-services' api return json object is so large,
> the json string size is even more than 1GB or more then cannot be
> observed.and the nifi process cannot handle so large size response. the
> DBCPConnectionPool's information referenced DBCPConnectionPoolLookup's
> information and vice versa.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
