I post the problem in DD forum but it seems here is a better location^^

>>
This problem is mainly like the post https://devconnect.avaya.com/public/forum/d_forum_3.jsp?t=6583&f=6,
But tomcat does not shutdown.

The system contains one AES server, one VP server with 101 ports, one tomcat 5.5 server running a DD 4.1.7 application and the CTI Connect.

System runs normally in the first week. But after that, it will random meet a problem that CTI connector can not connect to the AES server in one or two times per week.

I have review the log file of cti connector and aes server. The common points is the following two line:
-----------------------------
ERROR:WARNING:trans_serv:queueMsgsToMciLink:Message discarded, receive queue is full client= 6514 Switch= aes
ERROR:WARNING:asailink:RecvDataTimeoutEH:Can't queue TIMER message for recv Switch= aes CtiLink= 1 link= 0 errno= 2
-----------------------------
When this error happens, it will leads to mass errors like ASAI request C_VQ_REQ to switch timed out, DCAAO 70021 request C_3PDC_REQ to switch timed out aaoID and so on. The DD application will also crash. We must restart the AES server and Tomcat Server to fix the problem.

In the refered post, Neil suggested to add another AES server. will this the only way to fix the problem.
And Wing said that he would try to find the fact why receive queue is full, do you get the true reason?

Thanks

From looking at the other forum thread, ... 4.2 is not the most recent AE Service release. At a minimum you should be using 4.2.2, even better, 5.2.1 or 5.2.2 which will be released in June 2010. This would get you on the latest versions of AE Services bug fixes.

Next this looks to be a field issue. You need to get the customer to open an Avaya Global Services support request and have them investigate why the receive queue in the MciLink is full... most likely because there was some HUGE burst of traffic, or over time your application has added the same monitor many times and is getting multiple redundant events for a relatively small set of devices. Global services is the best group to investigate what is going on inside this server

Neil's last comment about a second/backup server seems oriented to being able to recover from the failure condition more quickly. While that would help you, it would not get the root cause of a AE Services issue investigated, isolated and resolved (if that is where this lies) - thus the need to involve Avaya GS who could investigate what is happening on this particular server more thoroughly.

Thanks you a lot~
I'll try the latest AES version on the system. Local Avaya GS support guys also help us a lot on detecting the real problem, and ask our call center vendor to check their applications on network traffic events.
I'll update the post if there are any progress.