Real-time Messaging Module on IE9 uses a lot of memory

[khoward]

I am a Smart GWT Power User and I am evaluating the Real-time Messaging Module. I'm doing some testing to see how memory grows on the browser.

I have my server send a message containing an array of 10,000 doubles every second. On the client side I am subscribing to the channel but I never do anything with the data. My MessagingCallback.execute() method is merely a stub. The browser I am running is IE9. I observe that memory usage grows quite fast even with periodic drops due to what I assume is garbage collection. In less than 30 min, IE9 is using over 1.5Gb of memory. The memory usage on Firefox and Chrome also grow but not nearly as fast as IE9. Is the IE9 memory usage to be expected even though the data is not being used or even referenced?

[Isomorphic]

If you have any development tools active, including Fiddler, IE's f12 tools, Firebug for Firefox or other tools, they will cause false leaks. You will also get a false leak if you have the Developer Console open while testing.

[Isomorphic]

GWT Development mode also leaks constantly.

[khoward]

Thank you for the reply. I did not have any development tools open when I ran this test and I was not running in GWT Development mode. I also observed that when the memory usage was running high, the browser was non-responsive. It did not even repaint itself.

[Isomorphic]

Can you wrap up your stress test code so it would be runnable for us? Then we can compare it to the tests we run (where we're not seeing an issue).

[khoward]

Hopefully the following will be acceptable to you since it's quite small. On my server I have the following method called from a java.util.Timer which is scheduled to execute every second.

private void sendTestMessage() {
List<Double> vals = new ArrayList<Double>();
for(int i = 0; i < 10000; i++) {
vals.add(Math.random());
}

try {
ISCMessageDispatcher dispatcher = ISCMessageDispatcher.instance();
ISCMessage msg = new ISCMessage("TestChannel", vals);
dispatcher.send(msg);
} catch (Exception e) {
e.printStackTrace();
}
}

On my browser client I have the following subscriber:

Messaging.subscribe("TestChannel", new MessagingCallback() {
@Override
public void execute(Object data) {
}
});

That's it. I also have the following question. Can I have multiple subscribers to the same channel? I wish to have multiple browser tabs each subscribing to the same channel.

[khoward]

Is there any update on this?

[jamesC]

I am seeing similar slow downs with IE when Messaging traffic increases,
is there any updates on this?

[Isomorphic]

Looks like this thread was never updated..

In IE9 Microsoft has decided that eval() should leak memory. Yes, seriously - see http://support.microsoft.com/kb/2572253.

It's obviously a bug but they have marked it "by design".

This would explain an IE9-only leak with Messaging. We implemented the workaround June 5th for both 3.0p and 3.1d.

[Isomorphic]

A follow up on this issue: We worked around the memory leak by implementing Microsoft's suggested approach of evaluating freefrom javascript in a separate hidden iframe which gets periodically refreshed (http://support.microsoft.com/kb/2572253). It turns out this workaround can lead to a second bug where a JavaScript error is thrown if the evaluated script block contained certain object types which are then accessed after the hidden frame was refreshed - typically this occurs with Date or Javascript function objects. The error message is *"Can't execute code from a freed script"*.

This error is obviously very intrusive and could occur seemingly unpredictably (it would be dependent on the data returned by the server) - we therefore have disabled the workaround by default and documented a public flag (RPCManager.allowIE9Leak and RPCRequest.allowIE9Leak) to re-enable it for applications where memory usage is a concern.

We are also working on another long term workaround for this issue whereby we make use of the new native JSON.parse() method to evaluate json-formatted responses from the server.
This change should avoid both the memory leak and the crash, but has some limitations of its own, such as the native functionality only being available on pages with the HTML5 doctype specified, and requiring some changes to the format of our server-generated JSON responses. We are in the process of determining the details of the implementation and will update this thread when this feature is available.

Regards
Isomorphic Software

[Isomorphic]

An additional follow up.
We have now added support for "strict" JSON formatted dataSource responses for dataSources with dataFormat set to "json" or "iscServer" via an attribute DataSource.useStrictJSON.

When this attribute is set to true, server responses will be parsed using the native JSON.parse() function where available. This means the format of the response must match the "strict JSON" format described here http://www.json.org/js.html. For standard dataSources backed by the SmartClient server and derived from a .ds.xml file, we will detect the flag on the DataSource and write out appropriately formatted responses automatically. Developers assembling their own JSON responses will of course have to match this format themselves.

Since this mechanism avoids the call to "eval()", the IE9 memory leak associated with that method is avoided.

Regards
Isomorphic Software