Hello, I've been busy with other parts of the project this afternoon. Peter please file the report i like, if I find anything more I will add it later.
I will add the TimerManager.js patch tomorrow and se how it works. Best regards Per-Ola At 15:33 2010-06-29, you wrote: >On Christian Hagendorn wrote: >> Hi Peter, >> >> yes, maybe that's the reason. Could you please add this to the bug report. > >Sure, as soon as there is one ;) Per-Ola wanted to file that one. >I will add all the informations/patches I have to the issue-report when it's >available. > >/Peter > > >> 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 -------------------------------------------------------------------- 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
