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
