Hi all, I've implemented the patch and I think it didn't break anything (yet :-) ). The debugger doesn't complain anymore about missing desturctor. Good work Peter! Time will show if it helps reducing the racing memory allocation.
Thanks! /Per-Ola At 10:04 2010-06-29, you wrote: >Hi Per-Ola, Hi Peter, > >could please some of you create a bug report for this issue. But please >describe the issue so good as possible perhaps with a code snippet. I >talked with Martin and he will have a look at it. > >Thanks! >Chris > >Am 29.06.2010 09:38, schrieb Peter Schneider: >> 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 >>> [...] >>> > > >-- >Christian Hagendorn >Software Entwickler > >1&1 Internet AG - Web Technologies >Ernst-Frey-Straße 9 · DE-76135 Karlsruhe > >Amtsgericht Montabaur / HRB 6484 >Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas >Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver >Mauss, Gert Nowotny, Jan Oetjen >Aufsichtsratsvorsitzender: Michael Scheeren > > >------------------------------------------------------------------------------ >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 -------------------------------------------------------------------- Per-Ola Stenborg Tele: +46 (0)346-16080 SA DataCom AB Dir: +46 (0)346-16088 Box 153 GSM: +46 (0)70-878 13 88 S-311 22 FALKENBERG Fax: +46 (0)346-84462 SWEDEN -------------------------------------------------------------------- ------------------------------------------------------------------------------ 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
