IE script warning

jonasby1

Hi, we've been having significant trouble on our lightstreamer based web app with the IE script warning appearing from time to time in ie8. We haven't ruled out the possibility of our app's code causing this, but I wondered if there was any history of problems with this warning and use of lightstreamer? For instance, any usage patterns to avoid, specific to lightstreamer. Does each update consumed by lightstreamer run in a seperate JS-worker? I may try introducing worker queue-timeout style processing at various points to see if it has an impact.

We're using several non visual tables subscribed to around 10-30 items each, pushing that data into ExtJS grids. There's no general problem with speed of the browser or CPU usage. The visual symptom is that after anything between 10 minutes and several hours of use, one of the tables stops rendering any updates for a few seconds (though the stream of updates should be constant), and then seems to consume a lot of updates (on the order of tens), triggering the slow script warning. This can happen just as frequently while using other functions on the site as when leaving the browser idle. Thanks for any light you can shed on this issue.

Mone

Does each update consumed by lightstreamer run in a seperate JS-worker?

no it doesn't.

I haven't heard of anything similar to your issue before so that I haven't specific suggestions for you. Usually the heavy part is the DOM manipulation; try to remove any update on the screen to see if the browser still have the issue.

If the issue is still there you may use IE8's developer tools profiler and try to understand where time is spent.

Also note that the client will switch to a polling session if the slowing-algorithm is enabled and the client is slow handling the updates; see http://www.lightstreamer.com/docs/client_html_jsdoc/Policy.html#setSlowingEnabled. Is the algorithm enabled on your application? Do you notice the client switching to polling in your onStatusChange callback?

HTH.

jonasby1

@Mone, Wrote: no it doesn't.

I haven't heard of anything similar to your issue before so that I haven't specific suggestions for you. Usually the heavy part is the DOM manipulation; try to remove any update on the screen to see if the browser still have the issue.

If the issue is still there you may use IE8's developer tools profiler and try to understand where time is spent.

Also note that the client will switch to a polling session if the slowing-algorithm is enabled and the client is slow handling the updates; see http://www.lightstreamer.com/docs/client_html_jsdoc/Policy.html#setSlowingEnabled. Is the algorithm enabled on your application? Do you notice the client switching to polling in your onStatusChange callback?

HTH.

Thanks for the reply. We've just implemented this kind of pattern for itemUpdate

table.onItemUpdate = function (item, itemUpdate, itemName) {
	...
	setTimeout(function () {
		handleItemUpdate(...)
	}, 0);
	...
};

And it appears to have made a difference - IE can now run for a much longer time, so far no script warnings - without any noticeable performance hit. There is a huge hit to performance in FF so we're only doing this in IE.

You're of course correct about the DOM manipulation; it probably is the source of these problems. I forced polling and streaming separately, and saw the same behaviour in each test. The app wasn't switching to polling automatically, and it is allowed to by default.

Mone

glad you solved.

anyway please note that UpdateItemInfo instances are reused by the library so do not use them in your setTimeout closure, save the needed values and use that instead.

Good:
[SYNTAX="JS"]table.onItemUpdate = function (item, itemUpdate, itemName) {
...
var val = itemUpdate.getNewValue("field");
setTimeout(function () {
doSomething(val);
}, 0);
...
};[/SYNTAX]

Bad:
[SYNTAX="JS"]table.onItemUpdate = function (item, itemUpdate, itemName) {
...
setTimeout(function () {
doSomething(itemUpdate.getNewValue("field"));
}, 0);
...
};[/SYNTAX]

HTH