Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Date: Fri, 20 Jul 2012 00:59:34 +0000 (UTC)
From: "Saber Chebka (JIRA)" <jira@apache.org>
To: flex-dev@incubator.apache.org
Message-ID: <630082720.79893.1342745974863.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <387689769.69245.1342623754817.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (FLEX-33139) HTTPService memory leak using both
 resultFormat e4x and xml
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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