Hi Peter, yes, maybe that's the reason. Could you please add this to the bug report.
Thanks, Chris Am 29.06.2010 13:52, schrieb Peter Schneider: > 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 > -- 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
