Expand my Community achievements bar.

SOLVED

Session Garbage Collection

Avatar

Level 3

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

1 Accepted Solution

Avatar

Correct answer by
Former Community Member

Johny,

I am not going to fix it for you. If you want to change anything, go ahead but I won't help you for sure.

I don’t have a magic wand and I did made a few changes and couldn’t notice thing you mentioned and so I didn’t reply and I am well within my right to not reply.

Thanks

Hironmay Basu

View solution in original post

26 Replies

Avatar

Employee

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 ?

Avatar

Level 3

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

Avatar

Employee

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.

Avatar

Level 3

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

John

Avatar

Level 3

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?

Avatar

Employee

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

Avatar

Level 3

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

Avatar

Employee

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.

Avatar

Level 3

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

Avatar

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

Avatar

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

Avatar

Level 3

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

Avatar

Level 3

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

Avatar

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

Avatar

Level 3

Hironmay,

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

Help!

John

Avatar

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

Avatar

Level 3

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

Avatar

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

Avatar

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

Avatar

Level 3

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

The following has evaluated to null or missing: ==> liqladmin("SELECT id, value FROM metrics WHERE id = 'net_accepted_solutions' and user.id = '${acceptedAnswer.author.id}'").data.items [in template "analytics-container" at line 83, column 41] ---- Tip: It's the step after the last dot that caused this error, not those before it. ---- Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign answerAuthorNetSolutions = li... [in template "analytics-container" at line 83, column 5] ----