Session Garbage Collection

[johnnyFlash4AFC]

I'm unable to garbage collect a ConnectSessionContainer. I've run close on it and individulally on each of it's managers, removed all listeners removed it from the displayList and set it = to null. Still the session persists.

I haven't been able to find much info on it in the docs. Any direction / suggestions would really help.

John

[Raff_]

Can you explain what you are trying to do and what do you mean by "the session persists" ?

Calling ConnectSessionContainer.logout should disconnect your client. Are you saying somehow you still see your client connected after calling logout and/or close ?

[johnnyFlash4AFC]

No calling logout removes the user from the room, but the ConnectSessionContainer, ConnectSession, UserManager, RoomManager, RoomManager, FileManager and I'm sure a few more related classes stay in memory. I haven't been able to get them garbage collected.

These classes are orphans so opening a new session creates duplicates of these classes and results in a pretty serious memory leak.

John

[Raff_]

Well, I am still not sure of what you are trying to accomplish. Are you putting your "connected" components in a view that gets created and deleted all the time ?

Here are a couple suggestions:

* there is a "global variable" _primarySession in com.adobe.rtc.session.ConnectSession. This get set to the first session created and I guess it never gets set to null again. You may want to try to set it to null when you "destroy" your ConnectSessionContainer

* don't use ConnectSessionContainer but instead create a ConnectSession programmatically. Each visual component in LCCS has a "connectSession" property that you can bind to your ConnectSession. When you want to destroy the session, set your connectSession variable to null (so that all components will nullify their connectSession pointer). Note that even in this case you may need to set ConnectSession._primarySession to null in order to remove all references to your connect session.

The ConnectSessionContainer is only useful if you want to make its children invisible until the connect session is established, otherwise there is no difference between using ConnectSessionContainer and ConnectSession.

[johnnyFlash4AFC]

Forgive me for my ignorance, but how would I reference this _primarySession variable. Can you give me an example?

John

[johnnyFlash4AFC]

I see a primarySession variable on com.adobe.rtc.session.ConnectSession.primarySession but it's read-only. How can I clear this variable as you suggest?

[Raff_]

Subclass ConnectSession and access _primarySession: it's declared as protected so it will be accessible to your object.

[johnnyFlash4AFC]

Raff,

Seems to me that these components should handle internal destruction better than this. Are there plans to fix this in a future release?

John

[Raff_]

We can open a bug but I am not sure of what the real fix is.

ActionScript doesn't have a concept of "destructor" for an object so we can't just set ConnectSession.primarySession to null when the ConnectSession is released. We can make primarySession writable so that you can nullify it, but that will open the door to other bugs (I can change primarySession or set it to null even when I don't want to destroy the object).

Anyway, you still didn't explain what your use case is. Maybe that would help coming up with a cleaner solution.

[johnnyFlash4AFC]

Sorry if I wasn't more clear our app is used for hrs at a time by our users. They have the option to open live sessions and close them and return to their work. The live sessions need to be completely disposed of when they are closed. I'm finding this difficult with the LCCS components.

Your suggestions helped me get the session disposed of and garbage collecting properly by extending the ConnectSession Class with a static reference to set primarysession and setting that value to null on cleanup. If I add a handful of components to the SessionContainer like the AudioPublisher for instance. It fails to clean up properly even after close and deleteReferenceOnParentDocument, but AudioSubscriber cleans up nicely. Can you give me insight into what could be holding it up? Are you aware of other Components that don't clean up well?

Here's what I've found so far

Components that don't clean up well.

ConnectSession ( solved )

AudioPublisher

WebcamSubscriber ( I havent' dug into this one yet and it's in a Repeater which could be the problem with it )

Components that clean up fine

AudioSubscriber

Roster

Any insight you can give me is greatly appreciated.

John

[Former Community Member]

Thanks for the detailed post, John - we'll definitely have a look into

this. If we can't make it into the next release, we'll at least get you some

code patches that will help.

cheers - posts like this really help us narrow down issues.

nigel

[Former Community Member]

Hi Johnny,

I can help you a bit regarding any cleanup on

AudioPublisher/WebcamSubscriber.

You can subclass AudioPublisher( or change in its source if you are

linking source directly) to override its close function

override protected function close():void

{

super.close();

streamManager.removeEventListener(StreamEvent.CODECCHANGE,onCodecChange);

if ( _stream) {

_stream.attachAudio(null);

_stream.close();

_stream = null;

}

}

Try this out and see if it helps to cleanup AudioPublisher better , and

also let us know if WebcamSubscriber is due to repeater or the problem

is in WebcamSubscriber itself.

Hope this helps

Thanks

Hironmay Basu

[johnnyFlash4AFC]

Hironmay,

Thanks for the feedback, but there must be more as it still isn't cleaning up. I'm using these components in a ConnectSessionContainer. Is there something hanging around from SessionContainerProxy? I see it holds a reference to the container component and adds an _uiComponent.addEventListener(FlexEvent.PREINITIALIZE,onADD); that never gets cleanup. I noticed that it is also used in the AudioSubscriber though which clean up fine. ( The proxy itself doesn't get collected, but I can live with that, although it's a bit sloppy ).

Help!

John

[johnnyFlash4AFC]

To close the loop it looks like the WebcamSubscriber cleans up fine. So I believe my only remaining open item is the AudioPublisher clean up.

Thanks

John

[Former Community Member]

Hi,

Great John. I will take another pass at AudioPublisher to see if there

is something missing that's stopping it from cleaning up.

Thanks

Hironmay Basu

[johnnyFlash4AFC]

Hironmay,

Have you made any progress with this component? I have a feature release that is being held up by this component.

Help!

John

[Former Community Member]

I scanned the component couple of times but I couldn't find off hand something that could be referencing after close. May be you can close the _connectSession inside AudioPublisher as a first step and see how it behaves.

Thanks

Hironmay Basu

[johnnyFlash4AFC]

Hironmay,

Thanks for doing the quick review, but Is there anyone on your team that can trouble shoot this component clean up, or are you leaving it up to me to find the problem in adobe's component?

I'm doing nothing funky with the component it's just instantiated in mxml in a ConnectSessionContainer.

Any help would be appreciated.

Help!

John

[Former Community Member]

No, it's me only. Tell me the exact steps you are doing in terms of seeing memory leak. You can take it offline and mail me on this directly at hibasu@adobe.com

Thanks

Hironmay Basu

[Former Community Member]

One of the things I realized johny is the onSessionClose event handler as this is what I find different from WebcamPublisher which cleans up fine.

So, You can override this function to do this

Override protected function onSessionClose(p_evt:ConnectSessionEvent):void

{

super.onSessionClose(p_evt);

if ( _stream) {

_stream.attachAudio(null);

_stream.close();

_stream = null;

}

}

Let me know if it fixes your problem or not. It should ideally.

Thanks

Hironmay Basu

[johnnyFlash4AFC]

I will try this, but I'm manually calling the close function on cleanup which already has this script in it, so I'm doubtful this will help. I will let you know though.

John