cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Handle creep?

36
Views
0
Helpful
0
Comments
This document was generated from CDN thread

Created by: Stewart Ponsford on 17-08-2009 01:38:51 PM
I seem to be getting a slow increase in the handles used by the java.exe when running my jtapi application.
 
Are there any cleanup processes that I need to be aware of to force garbage collection - I can't see anything in documentation.
 
Etc if you observe a call, when I get CallObservationEndedEv do I still need to remove my observation? Are there any other situations where I need to release resources and is there anyway of telling what I have kept hold of?

Subject: RE: Handle creep?
Replied by: Mohan Potluri on 17-08-2009 03:24:57 PM
Application need to dereference any call objects after seeing a CallInvalidEv or callobservationEndedEv.
If application adds a call observer, call activity on that address or terminal is reported until it is removed. Application has to clean any references to call objects when it receives CallInvalid or callobservationEndedEv.

Subject: RE: Handle creep?
Replied by: Stewart Ponsford on 17-08-2009 03:38:32 PM
Thanks I think I have found the cause, looks like I was sometimes adding a call observer twice. Doesnt seem to rise if I only do it once.
 
 

Subject: RE: Handle creep?
Replied by: Stewart Ponsford on 24-08-2009 08:27:53 AM
I have an update on this, the handle creep hasn't gone away but I seem to have found the cause but it looks like it is completely inside JTapi code.
 
If I call addObserver and RemoveObserver on a terminal repeatidly, the handle count rises by 7-8 each time and does not flatten out. 
 
The handles are not released by setting the terminal to null or forcing garbage collection.

Subject: RE: Handle creep?
Replied by: Bruno Rosenberger on 24-08-2009 11:17:52 AM
I do observe the same handle creep if a Transfer() is being called. The thread count increases each time for one thread, even if I dereference all the calls.

Subject: RE: Handle creep?
Replied by: David Staudt on 24-08-2009 12:38:23 PM
Can you guys perhaps provide a small sample application which demonstrates the problem? 

Subject: RE: Handle creep?
Replied by: Bruno Rosenberger on 24-08-2009 12:54:13 PM
David
 
We're using JTAPI by .Net. Between Java and .Net is a converter app which does the marshalling. I cannot send you the hole stuff - you would have to install the entire app and get licenses and so on.
 
I would have to write the Java demo-app from scratch, which is not possible now. I can provide some source code, but it would take a while for others to understand what is happening. The source code is in C# - almost like Java.
 

Subject: RE: Handle creep?
Replied by: David Staudt on 24-08-2009 02:27:19 PM
Interesting...can you describe the techniques whereby you are detecting the extra handles in the JTAPI code?  Is it possible the handles are leaked in the wrapper layer? 
 
I'm aware of partner applications that add/remove terminal observers very frequently...I would think if 7-8 handles are leaked per occurrence on this simple operation it would be noticed pretty quickly by the partner community, so I will be surprised if that's the case.  Certainly a simple Java-only sample which demonstrates the problem would be conclusive.
 
Barring that, you may be able to spot something from looking at the JTAPI logs.  Pls enable detailed-level/all-types for JTAPI logging, feel free to attach here if you are unable to find anything.

Subject: RE: Handle creep?
Replied by: Stewart Ponsford on 24-08-2009 02:31:32 PM
Hi David,
 
Sorry I seem to have found the cause, and it was me.
 
It was the event handler as I obviously get a TermOutOfServiceEv, it was due to how I worked out what event was received. I should have been using "instanceof". and not comparing to CiscoTermOutOfServiceEv.ID as that doesnt seem to free up when it goes out of scope.

Subject: RE: Handle creep?
Replied by: Bruno Rosenberger on 25-08-2009 07:12:29 AM
Hi David
 
In my case, the thread count only increases for one thread. This is the case, if I do a transfer operation. Other operations like answer, make a call, redirect don't show this leakage.
 
Yes, it is also possible that the handles are leaked in the wrapper layer. We're doing some analysis there too.
 
Attached is a log file as you suggested. The trace contains the starting of the application, then address 1037 calls 4050. 4050 answers, puts the call on hold, dials 1022, and before 1022 is answering, transfers the call, then the application gets closed.
4050 has a call control call observer, 1022 has a temporary call control call observer.
 
It would be great if you could take a look on it - maybe we see something there. - Thanks
CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards