Hey Per-Ola, Christian, Martin, I did some quick research on this and I think I have some information: It seems to me that the listeners that will be added by the Manager will not be removed. Whenever I do a <code>tid = timer.start(....);</code> followed by <code>timer.stop(tid); </code> the "entryList" in qx.event.Manager#removeListener() seems to be longer and longer. maybe the context is not right? Sometimes a thought I saw a "this" to be a strange object...
Nevertheless, maybe this helps. /Peter On 2010-06-29 13:45 Per-Ola Stenborg wrote: > 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
