Hi Chris and Peter I'll do some more invetigation on the timer issue and will then file a report. It still seems lika a bug. I'm running crome without debuging in the build right now and it still increases cpu usage.
Best regards Per-Ola At 11:26 2010-06-29, you wrote: >Hi Peter, > >yes, sorry. Please provide one for the qx.io.remote.transport.Abstract >and one for the timer issue. > >Thanks! >Chris > >Am 29.06.2010 11:12, schrieb Peter Schneider: >> Hi Chris, >> >> I can provide a bug/report for the qx.io.remote.transport.Abstract thing. >> Shouldn't the "timer" issue be handled in a different bug? >> >> @Per-Ola: I will create a report on the "transport" issue, right? So we don't >> do double work. >> >> /Peter >> >> On Christian Hagendorn 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 >>>>> [...] >>>>> >>>>> >>> >>> >> ------------------------------------------------------------------------------ >> 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 >> > > >-- >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
