Here's another one ;)
It seems that my thought in the last post (wrong context at "removeListener")
was correct.
@Per-Ola: Could you please try the attached patch and see what happens.
/Peter
On 2010-06-29 13:57 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
> --------------------------------------------------------------------
Index: TimerManager.js
===================================================================
--- TimerManager.js (Revision 96)
+++ TimerManager.js (Arbeitskopie)
@@ -297,7 +297,8 @@
{
// ... then stop listening for the periodic timer
qx.event.Idle.getInstance().removeListener("interval",
- this.__processQueue);
+ this.__processQueue,
+ this);
}
}
}
------------------------------------------------------------------------------
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
