[
https://issues.apache.org/jira/browse/NIFI-14707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Secules updated NIFI-14707:
--------------------------------
Description:
Affected versions: All
Impacts:
* Increased heap use
* Increased time taken to upload process groups with many connected components
I was investigating why it takes longer and longer to upload process groups
containing many connected components to nifi and after taking a flamegraph I
noticed only this call to getLogger inside `DebugEnabledTimedLock` was showing
up. All the other loggers I see in my nifi heap dump look like they only go as
specific as the Class name and not the specific instance. I believe this is
leading to excess heap use and increased time uploading process groups
containing many connected components.
I'm looking for feedback on the correct course of action. The simplest would be
removing the specificity and just using the logger for `TimedLock`. Or if we
still want this specific debugging feature we could use a system property to
gate whether we create `TimedLock` loggers with the instance ID or not.
was:
Impacts:
* Increased heap use
* Increased time taken to upload process groups with many connected components
I was investigating why it takes longer and longer to upload process groups
containing many connected components to nifi and after taking a flamegraph I
noticed only this call to getLogger inside `DebugEnabledTimedLock` was showing
up. All the other loggers I see in my nifi heap dump look like they only go as
specific as the Class name and not the specific instance. I believe this is
leading to excess heap use and increased time uploading process groups
containing many connected components.
I'm looking for feedback on the correct course of action. The simplest would be
removing the specificity and just using the logger for `TimedLock`. Or if we
still want this specific debugging feature we could use a system property to
gate whether we create `TimedLock` loggers with the instance ID or not.
> TImedLock creates too many loggers
> ----------------------------------
>
> Key: NIFI-14707
> URL: https://issues.apache.org/jira/browse/NIFI-14707
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.0.0, 2.4.0
> Reporter: Eric Secules
> Priority: Major
> Attachments: Screenshot 2025-07-02 at 2.14.32 PM.png
>
>
> Affected versions: All
> Impacts:
> * Increased heap use
> * Increased time taken to upload process groups with many connected
> components
> I was investigating why it takes longer and longer to upload process groups
> containing many connected components to nifi and after taking a flamegraph I
> noticed only this call to getLogger inside `DebugEnabledTimedLock` was
> showing up. All the other loggers I see in my nifi heap dump look like they
> only go as specific as the Class name and not the specific instance. I
> believe this is leading to excess heap use and increased time uploading
> process groups containing many connected components.
> I'm looking for feedback on the correct course of action. The simplest would
> be removing the specificity and just using the logger for `TimedLock`. Or if
> we still want this specific debugging feature we could use a system property
> to gate whether we create `TimedLock` loggers with the instance ID or not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
