Reverse AJAX - Browser JavaScript Memory Leak

Description

DWR-Version : 2.0.2-RC3

Using the Reverse AJAX functionality I have found a problem when pushing JavaScript back up into the browser where the browser does not clean up the objects being pushed up from DWR. The reason I am focusing on this issue is the application I am developing requires itself to stay up almost indefinitely during certain situations while supplying real-time data to people via the internet. Needless to say having even a small memory leak in the browser will eventually cripple any machine.

Below is a detail description of how I am able to create the problem. If needed I can supply the example code for your testing as well.

I am using the ScriptBuffer to setup my JavaScript. I then cycle through the ScriptSessions and send the script. I am not defining an entirely new script just calling and existing function I have loaded in my browser with the object that needs updating.

ScriptBuffer snippet :

fooUpdate(foo) {

ScriptBuffer script = new ScriptBuffer();
script.appendScript("updateFoo(").appendData(foo).appendScript(");");

// Push change out to clients viewing the page
Collection<ScriptSession> sessions = new HashSet<ScriptSession>();
sessions.addAll(sctx.getScriptSessionsByPage(pageUrl));
System.out.println(sessions.size());

for (ScriptSession session : sessions) {
session.addScript(script);
}
}

Once the JavaScript function has been run in the browser a small amount of memory is left in its memory space. This can be accomplished by simply running an empty method with the passed object. I notice that the DOM element count for the page does not increase, just the memory that is being used by the browser.

From the example being called above here is the JavaScript defined that is being called:

function updateFoo(foo) {
}

The memory usage is very apparent in IE7. It seems that Firefox handles the artifact much cleaner and actually regulates its memory where IE7 simply continues to add the elements to its memory set.

I have used Firefox and IE's tools for JavaScript debugging and found that no stray objects are created. I am using Firebug on Firefox and MS Script Debugger on IE.

Activity

Show:
Rich Faber
April 22, 2008, 3:38 PM

Still not working when I test dwr.jar 2.0.3 with IE6 sp2.
I was testing a very active "Stocks" demo (10-20 values changing per sec)
I still get IE memory leaking...
Without maxWaitAfterWrite: 20M to 110M (1hr);
With maxWaitAfterWrite: 20M to 120M (30min);
I did a quick test....maybe I did something wrong...

My servlet web.xml with this...
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<display-name>DWR Servlet</display-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param> <param-name>debug</param-name> <param-value>false</param-value> </init-param>
<init-param> <param-name>activeReverseAjaxEnabled</param-name> <param-value>true</param-value> </init-param>
<init-param> <param-name>maxWaitAfterWrite</param-name> <param-value>500</param-value> </init-param>
</servlet>

FFox Firebug console entries like this with XHR debugging on.
http://faber-lws.planalytics.com/pt/dwr/call/plainpoll/ReverseAjax.dwr (avg 650ms) engine.js (line 684)

Mike Wilson
April 22, 2008, 10:54 PM

Richard, could you try the reverse ajax clock example? (from demo/ and web/ in the source tree or just get the WAR from https://dwr.dev.java.net/servlets/ProjectDocumentList?folderID=9081)
It refreshes the time every second so it's not as "fast" as your example, but it would give us a common reference as it is the one I have been using for reverse ajax memory tests.
Also, it would be great if you could do this with 2.0.4 RC1 (same link as above) so we know you are not affected by any other memory leaks that have now been fixed in the new version.
Thanks / Mike

Rich Faber
April 28, 2008, 3:15 PM

Seems to be working fine after more testing.

Tested with 2.0.3 for 30 minutes (so far) with no (or insignificant) memory growth!
Tested the Clock: (1 value per sec) IE6 16.75M to 16.88 M in 30minutes.
Also tested the Fast Stocks demo (10-20 values per sec) IE6 18.8M to 19.2M in 30minutes
(This is wonderful results compared to before... basically no memory leak)

Thanks for fixing this issue!!!!

Rich Faber
August 27, 2008, 6:59 PM

I am suspicious of the return of a memory leak when doing DWR comet with javascript lazy loading.
I am running a complicated web app (financial risk management)... previously no leak with DWR comet.
Then with lazy loading... I get a leak. (I have to test more to be 100% sure)
So far in only 4 hours I have 60M in the leaky app (DWR+lazy) and 31M in the app w/o DWR reverse ajax or lazy loading.
Sorry, I need to do more testing... to confirm... I'm not 100% sure since its a complicated app.
But just curious if anyone else does javascript lazy loading with DWR reverse ajax and long running apps?

Mike Wilson
August 28, 2008, 9:32 AM

Hi Richard,
You are probably better off asking this on the mailing list as not so many people are reading the bug reports.
For a reference test, you can run the Reverse Ajax Clock example from DWR demos in your environment, to see if it leaks.
Best regards
Mike

Assignee

Mike Wilson

Reporter

ThomasT

Labels

None

Documentation Required

None

Fix versions

Affects versions

Priority

Major
Configure