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
