[
https://issues.apache.org/jira/browse/FLEX-33139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418846#comment-13418846
]
Saber Chebka commented on FLEX-33139:
-------------------------------------
Mansour, back to the example you provided, on function
"resultHTTP(event:ResultEvent)", after getting used the xml data result, I
added next code snippets:
// Dispose the XML for gc, the force the garbage collection
System.disposeXML(xmlData);
xmlData = null;
gc_perform(event);
gc_perform(event);
where gc_perform() is the gc forcer method:
private function gc_perform(event:Event):void
{
// Garbage Collection
try
{
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
}
catch(e:*)
{
}
memory.text=(System.totalMemory/(1024*1024))+" Mb"
}
// Some other workaround was done on function updateXMLC() to make it look like:
// TRY NOT TO RE USE THE HTTP SERVICE ONCE AGAIN
private function updateXMLC(event:TimerEvent):void
{
if(httpS){
httpS.removeEventListener(ResultEvent.RESULT, resultHTTP);
httpS.clearResult(true);
httpS.disconnect();
httpS = null;
}
httpS = new HTTPService();
httpS.url = "data.xml";
httpS.addEventListener(ResultEvent.RESULT, resultHTTP);
httpS.resultFormat="e4x";
httpS.send();
}
==> As a result: Memory Leak seems to be disapeared.
I know the use of gc forcer method is not advised, but it seems to be the key
for a non solved issue by Adobe.
> HTTPService memory leak using both resultFormat e4x and xml
> -----------------------------------------------------------
>
> Key: FLEX-33139
> URL: https://issues.apache.org/jira/browse/FLEX-33139
> Project: Apache Flex
> Issue Type: Bug
> Components: RPC: HTTPService
> Affects Versions: Adobe Flex SDK 4.6 (Release)
> Reporter: Mansour Blanco
> Priority: Critical
> Labels: memory_leak
> Attachments: UrlLoaderString.PNG, XLC.zip
>
>
> Steps to reproduce:
> 1.download the zip file
> 2.import as a project
> 3.profile using e4x or xml resultFormat
> 4.create 2 memory snapshots from the Flex profiler
> 5.use "Find Loitering Object" View between the 2 snapshots.
> 6.analyse String objects using "Open Objects Reference"
> Note : Forcing GC cannot remove Loitering String Objects
>
> UrlLoader is accumulating String objects on each refresh of data which cannot
> be GC .
> The attached screenshot shows the URLLoder string variables.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
