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
Is there an existing mobile phone application that works with Cisco Unified Intelligence Center? The request is to be able to run reports from an app on a smart phone. I realize a browser could be used to display web pages. Don't want to reinven...
We created a proxy user who is in "Standard EM Authentication Proxy" Group. If I try to get information about another user using this credential, it still says "No Authentication Proxy Rights" <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XM...
After testing it in multiple different CCE version it looks like I found a bug on the Media Dialog on the Finesse API. I tested with CCE version 11.6 and 12.0 and also did the same on a dCLoud PCCE 12.0 environment.The startTime and the stateChangeTime fo...
Having an issue with trying to display a CUIC Report Permalink (UCCX) in a browser. When going to the link it shows "Error Fetching datasource info". I made sure that my Permalink has authentication off. I made sure "All Users" have Execute acc...
Hello Community, I have been reading CURRI documentation and I found that it is possible to modify the calling number and called number using CURRI, to apply business rules. I tested it calling from one internal agent to another successfully, bu...