This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 244638 - memory leak in Network Monitor
Summary: memory leak in Network Monitor
Status: VERIFIED FIXED
Alias: None
Product: web
Classification: Unclassified
Component: HTML Project (show other bugs)
Version: 8.0
Hardware: All All
: P1 normal (vote)
Assignee: Tomas Mysik
URL:
Keywords:
: 246629 247533 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-05-21 23:19 UTC by David Konecny
Modified: 2014-09-30 06:10 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2014-05-21 23:19:13 UTC
There is some mean memory leak in the Network Monitor. I noticed that while working on internal project which upon start loads dynamically dozens of JS files and HMTL templates which end up all being logged in the Network Monitor - after working on such a project for a while and reloading it frequently I would notice memory going up and never get releases. After half a day my memory usage would be nearing 2GB. Afte taking a dump I could see that there was 100 000 instances of some NetworkMonitor class in memory (sorry I do not have the dump anymore and cannot remember which class was it) despite the Memory Monitor being closed.

I'm filing this and assuming that it should be pretty easy to reproduce it by creating some HTML5 sample project which does loggable network activity followed by closing it and forcing GC.
Comment 1 Tomas Mysik 2014-05-23 09:03:09 UTC
It seems to me that org.netbeans.modules.web.webkit.debugging.api.network.Network.activeRequests holds all the requests even if I close the Network Monitor component, the project and run GC several time. Could this be the cause, Davide? Or am I completely wrong?

Thanks.
Comment 2 Tomas Mysik 2014-05-23 09:51:06 UTC
Ha, I was wrong I guess. The problem seems to be in NetworkMonitorTopComponent.Model.allRequests. Values from this list are removed only if one clicks the Clear button (the "bin" icon).
Comment 3 Tomas Mysik 2014-05-23 10:46:52 UTC
If I understand correctly how Network Monitor works:
- if opened, it processes requests for the given project;
- if closed, it is deactivated (project requests are ignored).

This works, at least for me (verified using thread dumps). Davide, are you sure that you have closed the Network Monitor? If yes, it should not consume any additional memory.

Regarding the number of instances - I can confirm that the number of requests is much higher than the number of clicks (for me, one click created e.g. 8 requests but only 1 has been shown in the Network Monitor UI). Do we need all the requests or just the ones shown in the UI?

My conclusion:
(0) we should lower the number of requests held in the memory, it means to hold only visible requests (can we break something?)
(1) we can clear the requests once project is closed (if one reopens the project, the requests will be empty - that is OK and IMHO expected);
(2) we can clear the requests once Network Monitor is closed (not sure whether it is fine or not, I guess it is);
(3) we can keep only last X requests (keeping them all is IMHO not necessary and it consumes memory, of course).

I also found a bug - listening on request should be weak (there is no remove method call).

Waiting for feedback, please reopen. Thanks.
Comment 4 Tomas Mysik 2014-05-28 05:55:10 UTC
Another problem is that whenever the Network Monitor window is opened, a new TopComponent is created (and the old ones are not GC'ed).

So, please, specify expected behavior (can we keep just X requests in the list? should the requests disappear once one closes the Network Monitor window? or the project?) and reopen this issue. Thanks.
Comment 5 David Konecny 2014-05-29 04:36:33 UTC
(In reply to Tomas Mysik from comment #3)
> If I understand correctly how Network Monitor works:
> - if opened, it processes requests for the given project;
> - if closed, it is deactivated (project requests are ignored).

Yeah, when the window is closed it should do nothing.

> This works, at least for me (verified using thread dumps). Davide, are you
> sure that you have closed the Network Monitor? If yes, it should not consume
> any additional memory.

I cannot rememember what I did and I tried to reproduce it over last two days without success.

> Regarding the number of instances - I can confirm that the number of
> requests is much higher than the number of clicks (for me, one click created
> e.g. 8 requests but only 1 has been shown in the Network Monitor UI). Do we
> need all the requests or just the ones shown in the UI?

No, we do not want to log everything - only AJAX calls.

> My conclusion:
> (0) we should lower the number of requests held in the memory, it means to
> hold only visible requests (can we break something?)

Currently Breeze when started loads issues about 240 requests. Maybe we should limit the figure of requests which UI shows - last 1000 requests?

> (1) we can clear the requests once project is closed (if one reopens the
> project, the requests will be empty - that is OK and IMHO expected);

yes

> (2) we can clear the requests once Network Monitor is closed (not sure
> whether it is fine or not, I guess it is);

I cant remember the details of when events are logged and when not and when they should be cleared.

> (3) we can keep only last X requests (keeping them all is IMHO not necessary
> and it consumes memory, of course).

this is the same as (1), right? I agree.

> 
> I also found a bug - listening on request should be weak (there is no remove
> method call).
> 
> Waiting for feedback, please reopen. Thanks.

I will keep an eye on it and report more if I reproduce the issue.

Thanks for looking into this Tomas!
-David
Comment 6 David Konecny 2014-05-29 04:37:42 UTC
(In reply to Tomas Mysik from comment #4)
> Another problem is that whenever the Network Monitor window is opened, a new
> TopComponent is created (and the old ones are not GC'ed).

This sounds like an issue which I've had originally! But I cannot reproduce ti again.
Comment 7 Tomas Mysik 2014-05-29 05:31:42 UTC
(In reply to David Konecny from comment #5)
> Currently Breeze when started loads issues about 240 requests. Maybe we
> should limit the figure of requests which UI shows - last 1000 requests?

This will be a bit tricky since the model holds all requests for all projects.

(In reply to David Konecny from comment #6)
> This sounds like an issue which I've had originally! But I cannot reproduce
> ti again.

This would not consume your memory since the model is shared between Network Monitor windows (the Network Monitor component itself took just a small amount of memory).

Reopening, will look at it and do my best.

Thanks.
Comment 8 Tomas Mysik 2014-05-29 11:38:42 UTC
Main problems should be fixed now. Davide, please review the patch, thanks. Láďo, please verify that I did not make any regressions (try requests, web sockets).

Thanks.

http://hg.netbeans.org/web-main/rev/244fc40fdc36
Comment 9 Tomas Mysik 2014-05-29 11:41:01 UTC
BTW more instances of TopComponent is NOT fixed - feel free to submit a new issue for that (P3, it consumes a little memory, the model is shared).

Thanks.
Comment 10 Quality Engineering 2014-05-30 02:22:08 UTC
Integrated into 'main-silver', will be available in build *201405300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/244fc40fdc36
User: Tomas Mysik <tmysik@netbeans.org>
Log: #244638 - memory leak in Network Monitor

Main problems should be fixed now.
Comment 11 Vladimir Riha 2014-05-30 08:23:20 UTC
Seems OK to me, requests are displayed ("normal", web sockets, jsonp), broken requests are red, it is possible to delete (clear) the list, reopen the panel etc. 

  Product Version         = NetBeans IDE Dev (Build 201405300001) (#addc00d7038d)
  Operating System        = Linux version 3.2.0-60-generic-pae running on i386
  Java; VM; Vendor        = 1.8.0_05; Java HotSpot(TM) Client VM 25.5-b02; Oracle Corporation
  Runtime                 = Java(TM) SE Runtime Environment 1.8.0_05-b13
  Java Home               = /home/vriha/jdk1.8.0_05/jre
Comment 12 Tomas Mysik 2014-05-30 08:39:20 UTC
I forgot to add - there is a limit for number of requests in the list (1 000 requests at maximum). Not sure whether you want to test it, Láďo :)

Thanks.
Comment 13 Vladimir Riha 2014-05-30 09:21:29 UTC
Nothing that a little for loop wouldn't handle :) I just tried it and it works, only 1000 latest requests are displayed
Comment 14 Tomas Mysik 2014-06-10 09:51:35 UTC
(In reply to Tomas Mysik from comment #9)
> BTW more instances of TopComponent is NOT fixed

Not true aymore.

http://hg.netbeans.org/web-main/rev/0f0079eeef26
Comment 15 Tomas Mysik 2014-08-22 09:03:48 UTC
*** Bug 246629 has been marked as a duplicate of this bug. ***
Comment 16 Jaroslav Havlin 2014-09-30 06:10:33 UTC
*** Bug 247533 has been marked as a duplicate of this bug. ***