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
