Hi,

BlazeDS doesn't destroy the clients session right after the connection closed.  The undeliverable messages are kept until the client timeout. The Flex Client can be restored if the same ID is used.  In order to prevent high usage of memory, it should make the flex client timeout short. After the Flex Client timeout, the messages(AsyncMessage) are discarded. For the memory management, we can also have custom OutBoundQueueProcessor to limit the number of messages in the queue. (for the blazeds posting)

In short, the problem can be solved by setting the flex client timeout to 1 minute.

This is on server only. We are investigating the browser leak issue. We did some MTBF test, one of the JMS test used polling amf. We didn't see any memory issue in 7 days run. Can you let me know which build did you find the memory leak? Mohd.

William

I have tracked down (and fixed locally) a serious memory leak in PollingChannel.as. It turns out that PollCommandMessageResponder objects are getting created for every polling message but never getting released because they are getting held in memory by an event listener.

I filed a bug: https://bugs.adobe.com/jira/browse/SDK-27883

The fix is simple -- just cleanup the event listener. The nice thing about this bug is that you don't have to take my word for it -- please just look at PollingChannel.as code and notice at the bottom:

  public function PollCommandMessageResponder(agent:MessageAgent, msg:IMessage, channel:PollingChannel, log:ILogger)

    {

        super(agent, msg, channel);

        _log = log;

        // Track channel connected state.

        // If the channel disconnects while this poll is outstanding, suppress result/fault handling.

       channel.addEventListener(PropertyChangeEvent.PROPERTY_CHANGE, channelPropertyChangeHandler);

    }

Now look (in vain) to see where that event listener is cleaned up -- it isn't.

My fix is simple -- just release the event listener after it is no longer needed. I do it two places:

Place 1:

override protected function resultHandler(msg:IMessage):void

    {     

        var pollingChannel:PollingChannel = channel as PollingChannel;       

//

//VANTOS: This line was added to remove a serious memory leak

channel.removeEventListener(PropertyChangeEvent.PROPERTY_CHANGE, channelPropertyChangeHandler);

Place 2:

    override protected function statusHandler(msg:IMessage):void

    {       

//

//VANTOS: This line was added to remove a serious memory leak

//

channel.removeEventListener(PropertyChangeEvent.PROPERTY_CHANGE, channelPropertyChangeHandler);

************

Please note that I've although I've verified that this does stop the memory leak (using the Flash Builder profiler), it is possible that there is a better way to fix this. But this fix seems to work for us.

Yes, I agree these do appear to be two separate issues. Thank you for clearly separating them.

There really is a memory leak on the client. If you have any doubts please run the Flash Profiler and watch the counts for PollCommandMessageResponder (you will need to set up a polling connection of course).

Did you get a chance to look at the code that I pointed out in PollingChannel.as? You can see that for each poll a PollCommandMessageResponder is getting created. And each one of those registers an event listener in its constructor. That means Flash has to keep that PollCommandMessageResponder in memory. I don't see any way around that, but perhaps I'm missing something here? I'm asking that with honest curiosity.

By the way, if I'm right it actually is worse than just a memory leak -- if we did happen to get the error event that all those PollCommandMessageResponder are listening for, all of them would suddenly have to be called which could be quite a large amount of work that might explain some of the random crashes we've seen.

I found the same bug on my application, I use Flex 4.1, Blazeds 4, spring flex 1.5.2, spring 3.0.6., Weblogic 10, Websphere MQ 7.

Does anyone know the cause of this issue and how it can be overcome. Please help.