Hi.

I have a large system (DD 5.1SP3) that when it gets traffic has error like:

25/08/2015 07:27:34:160 ERROR - CallInfo.doGetCallInfoInitialCall: No call info available for extension 29498

25/08/2015 07:27:44:380 ERROR - CallInfo.doGetCallInfoInitialCall: No call info available for extension 29155

25/08/2015 07:28:10:097 ERROR - CallInfo.doGetCallInfoInitialCall: No call info available for extension 29029

I sent it to AES support but they said everything was normal. Upon looking at Tomcat we saw that there are several threads with very long times hanging on CTICall (see attached picture). Of course, if we restart Tomcat these disappear and things are normal for a while.

Inside the code the getcticallinfo (which is sent about 5 secs after the call starts) fails and the system handles it. The question is: Why is it failing so much?

Can you attach an AESC log as things start to hang?

How busy is your system and how many ports are you using? Is it possible this system is overloaded?

Have you increased the thread count and heap size of Tomcat?

They had 200 threads, we moved it up to 800. Yes, they do have a lot of channels (about 500), shared across 2 Tomcats.
Attached the log.

The thing is, the system has not increased in size or traffic lately, but this started happening.

Seems like you might have cross channel communication. The apps gets the IP to talk to the AESC from the request object. This is how it communicates. If you are on a load balancer, the IP is actually that of the load balancer itself, so the app on Tomcat1 might talk to the AESC on Tomcat2 which won't work.

The way around this is to either modify the load balancer to pass through the IP of the server. This way the app always gets the IP of the Tomcat it resides on.

or
you can go to the PDC page in your app's properties and on the AESC PDC, there is a setting:
communicate to AESC using localhost (recommended for load balancing).

This will always use localhost to communicate and avoid getting IP out of the request object (this is recommended).

The only load balancing we are using is provided by Experience Portal itself, so there is no other hardware or software balancing.

Does this PDC setting apply to DD5 as well?

Do you have AESC logging turned down? It should be at 3 (see the settings in the runtime config servlet).

Can you upgrade to a newer version of OD? DD 5 is about 5 years old and we have had many changes to the code since then. The code is much more efficient as well. I believe the change was introduced into DD 5.1 SP2.

On DD 5.1.0.1702 (SP3 I believe) the CTI Connector PDC screen has no setting.

Can this be setup via a change in web.xml inside the connector or a property somewhere on 5?

Checked and it didn't go in until OD 6.0. No, the setting only works in 6.0 and beyond.

Changed to 6.0SP3, redeployed but we are still getting threads with enormous times of execution connecting to /aesconnector/BlindCall?callee%3D4555%26uui%3D1%7C0%7C4390845%7C%7CBOG.....

That one has been going on for 16240536ms (so 4.5 hours of processor time). We will try with the localhost pdc setting and let you know what happens.

Yes, use localhost