When I receive a route request from the AES, 5ms later I end the request by calling the "sendCstaRouteEndInv" method (i have no extension for it to route to). I however get a "PERFORMANCE_LIMIT_EXCEEDED" error. My understanding of this error is that if i take too long to respond then this error is thrown. However I am responding withing 5ms so this error makes no sense.

About 10 to 15 secs later i get a "INVALID_CROSS_REF_ID" error. My understanding of this error is that either i sent it an invalid "routeRegisterReqId" or "routingCrossRefId" on the "sendCstaRouteEndInv" call but i have verified that I am giving it the correct values and more over this conflicts with the "PERFORMANCE_LIMIT_EXCEEDED" error i got earlier that claims that I never ended the route in the first place!

I am at a loss for whats going on and any help would be appreciated.

Make sure there is a "wait-time" step immediately after the "adjunct routing" step in your vector.

If you do feel that your vector is correct. I you should open a Tech Support ticket for me to be able to investigate more thoroughly. Please note that, for non-paid members, there is a fee for this service.

Martin

It turns out that my issue seems to be that I wasn't draining the AES queue from my application quickly enough. I send the AES 10 agent state requests per sec but I am only calling "acsGetEventPoll" every 100 ms. This seems to cause a back up of unprocessed message responses from the AES (this is just a guess by the way). As the back up continues it starts impacting the AES performance.

So when I end the route request in time, it takes the AES a while to get the message (past the time limit) and so I get the PERFORMANCE_LIMIT_EXCEEDED message. Once the AES processes my end route message, it then throws the INVALID_CROSS_REF_ID because it had already ended the route for me because it thought i was late in responding and so the cross ref id is no longer valid.

I'm new to all of these and most of this is just an educated guess. But once i started polling more frequently (every 20 ms) my problem went away.

That would certainly explain it.

Polling for events may not be the best solution as it can unnecessarily waste processor cycles and you have to limit how many events you can process.

It is possible to get events in different ways, for example:

1. The application can do a blocking read using acsGetEventBlock(). That way the event receiver thread does not waste any cycles and the application receives events immediately.
2. A Windows application can request to be notified when there is an event available using acsEventNotify().

"TSAPI for Avaya Communication Manager
Programmer’s Reference" gives some information on these methods and even how you can mix-n-match. The TsapiSamples sample code that comes with the TSAPI SDK uses acsEventNotify(), followed by acsGetEventPoll() to receive the message.

Martin

So the problem for me is that my application is written in c# not c++ and I haven't found a good way to implement the "acsEventNotify()".

A technique i started using was to call "acsGetEventBlock" in a loop. If there a message becomes available i then call "acsGetEventPoll" every 20 ms to drain the queue. When there are no messages left, i go back to blocking again until a message becomes available.

What do you think of this approach?

That seems reasonable. However, as you only poll for events when you know that there is (probably) one, you could reduce your delay to even lower than 20mS. That way your application could handle more than just 50 events per second.

Martin

actually it turns out that even the strategy I just discussed did not work out so well. Anything below 70ms lead to some odd behavior from the AES. Most prevalent was the ACSERR_STREAM_FAILED. In the end i could only poll for events every 70 ms and I could only query no more than 10 agent states per second. This level was unacceptable for what I needed to accomplish.

So i decided to look into the idea of acsGetEventNotify(). Since I'm not using a gui app I was left with acsSetESR() which calls my callback when it has an event for me, then i used the acsGetEventBlock() to retrieve the event. I was able to get a c# version working and now it is working beautifully. I am no longer polling the AES so this should relieve it a lot. I will have to do more testing today but it seems that in theory I can send it as many requests as I like and it will let me know as it has responses ready.

I will let you know how it went. I really appreciate all the help you have given. If there are any pitfalls to my latest strategy please let me know.

ACSERR_STREAM_FAILED usually indicate a problem in the network between the AE Services and application server or incorrect behavior on that part of the application.

The application an either be too slow removing events from the incoming queue or it can starve the TSAPI Client from servicing the queue.

Your plan to use acsSetESR() seems reasonable. However, you must heed the warnings in the Programmers Guide. IE. do not get and process the incoming event in the ERS callback - you do not own the notification thread. Instead, use the callback to trigger the collection of the event using a thread that is owned and controlled by the application.

Martin

Excellent I am already doing that. When i receive notification from the callback, I immediately call another method that I created to handle the event I received from the AES. Again thanks so much for your help on this. So far my testing has gone incredibly well and I have yet to see an issue.