Hey Per-Ola,
as you wrote you are using qooxdoo 1.1: I experienced similar problems, so this
thread
http://qooxdoo.678.n2.nabble.com/Missing-destruct-definitions-in-qx-io-remote-transport-XmlHttp-v1-1-tt5018573.html
might be about the same root-cause.
I was able to reduce my memory-leakage problems dramatically by applying the
patch that I proposed on that thread[1]. It just adds a missing destructor.
Unfortunately this has not (yet) been added to the repository (AFAIK).
This does _not_ change any timer related memory leaks, but it might be of
interest anyway.
Maybe this helps. If it does, we have a 2nd "test" for the patch that it does
not break anything ;)
/Peter
[1] I've attached it to this post as well
On 2010-06-29 09:28 Per-Ola Stenborg wrote:
> Hi all,
>
> I'm developing an application which you can think of as a point of sale
> client. It needs to be running for days without browser restart. I noticed
> when starting to test the client that it started to loose performance and
> consume the PC:s resources after a few hours. This problem might be depending
> on two different things.
>
> In the client I have a timer that among other things periodically (like 30s)
> communicate with the server to refresh data. I might have a deallocation
> problem when using qx.io.remote.Request(). After enabling the
> "source-disposerDebug" job I get these log entries after every communication:
>
> 001622 Missing destruct definition for '$$user_requestHeaders' in
> qx.io.remote.transport.XmlHttp[undefined]: [object Object] Native.js (rad 61)
> 001627 Missing destruct definition for '$$user_parameters' in
> qx.io.remote.transport.XmlHttp[undefined]: [object Object] Native.js (rad
> 61)001631 Missing destruct definition for '$$user_formFields' in
> qx.io.remote.transport.XmlHttp[undefined]: [object Object] Native.js (rad 61)
>
> After commenting out the communication, things maybe seems a bit better. But
> the timer it self still start to consume memory and cpu cycles after a few
> hours.
>
> I have tried this with both Firefox 3.6.6 and Crome 5.0.375.70. After 9 hours
> cromes memory consumption has gone up from 39 to 58MB and ff:s from 93 to
> 185MB.
>
> And the cpu utilization is almost 50% on both browsers (on a two core
> machaine). ProcessExplorer images here
> http://www.sadata.se/files/temp/firefox.jpg and here
> http://www.sadata.se/files/temp/crome.jpg
>
> The only code necessary to show the problem is:
>
> ---%<---
> var timer = qx.util.TimerManager.getInstance();
>
> timer.start(function(userData, timerId) {
> // this.debug("Time!");
> },
> 100,
> this,
> null,
> 0);
> ---%<---
> Even this empty timer gives this problem. Complete test source here
> http://www.sadata.se/files/temp/Application.js
>
> I need help to sort those problems out. I will be happy to supply more info
> if I can. I'm using qooxdoo ver 1.1
>
> Best regards
>
> Per-Ola
> [...]
Index: Abstract.js
===================================================================
--- Abstract.js (Revision 96)
+++ Abstract.js (Arbeitskopie)
@@ -501,5 +501,21 @@
return true;
}
+ },
+
+
+
+
+ /*
+ *****************************************************************************
+ DESTRUCTOR
+ *****************************************************************************
+ */
+
+ destruct : function()
+ {
+ this.setRequestHeaders(null);
+ this.setParameters(null);
+ this.setFormFields(null);
}
});
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel