[
https://issues.apache.org/jira/browse/NIFI-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590525#comment-16590525
]
Alex Aversa commented on NIFI-5548:
-----------------------------------
{color:#333333}Thanks Matt. Yeah I will go ahead and pull down the latest
browser versions at home and see if I can replicate the problem as the versions
I'm working with are slightly out of date right now. Here are the answers to
your questions below:{color}
{color:#333333}*{color:#205081}Was the canvas not being interacted with at
all?{color}* Yes, the graph was left untouched for approximately 4-5 hours or
longer when the script error/browser crash was observed. The behavior does not
appear to occur as long as the graph is actively being used. {color}
{color:#333333}*{color:#205081}The page was simply left open and the canvas
continually polling for updated stats?{color}* Yes, it continued to refresh and
my status refresh rate is set at 30s{color}
{color:#333333} *{color:#205081}What is your flow like?{color}* My test flow
was comprised of ~15 processors, 1 funnel, 5 process-groups. All except 2 items
on the graph remained in a stopped state. At no time were there flow files
moving through any queue during the testing period. .{color}
{color:#333333} *{color:#205081}Which components are used?{color}* Generate
FlowFile, Update Attribute, PutFile, Log Attribute {color}
{color:#333333} *{color:#205081}Was the canvas zoomed in close enough to render
the component details?{color}* Yes, however the error can be replicated
regardless of zoom depth in FireFox and Chrome.{color}
{color:#333333} *{color:#205081}How many components were on screen (and one
screen in every direction)?{color}* Approximately 5-10 items on the graph when
the behavior was observed with components in every direction (NSEW) on the
graph. Behavior was also observed with the entire flow zoomed out and centered
on the canvas element. {color}
{color:#333333} *{color:#205081}Did the number of components on screen make a
difference for the behavior you saw?{color}* The behavior occurred regardless
of number of components, but I did not look at if it occurred faster with more
components on the graph.{color}
{color:#333333} *{color:#205081}How were you measuring client RAM
usage?{color}* RAM usage in FireFox appeared to be hitting between ~0.9 - 1.2
GB when the script error would be thrown. I failed to observe the memory
metrics in Chrome, but will attempt to replicate at home with the latest
versions and report back. . {color}
{color:#333333}**On a side note, I am mainly observing the behavior on a
Windows 7 client. I ran the same tests on Firefox v52.8 on CentOS7 and can not
reproduce the behavior. I'll run devtools at home to see if I can get some
better insight as to what specifically is locking up. {color}
> Memory leak in graph user interface
> -----------------------------------
>
> Key: NIFI-5548
> URL: https://issues.apache.org/jira/browse/NIFI-5548
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI
> Affects Versions: 1.6.0, 1.7.0
> Environment: Chrome, Firefox
> Reporter: Alex Aversa
> Priority: Minor
>
> When the graph interface is left up on a browser tab for an extended period
> of time (several hours) the client RAM usage continues to grow to the point
> where the page no longer responds. This behavior has been observed in both
> versions of Firefox and Chrome on Windows 7 clients and throws an
> unresponsive script error attributable to the d3.min.js library.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
