Hi it's not seen on tracelogs by Applicaiton Link side
And here is the answer by genesys side, from Ticket archive..
*********************************************************
.........do not see any attempt by Tserver to send a CSTA request across the Applink.
The MD110 Engineers cannot see any CSTA message of the Applink side either.
To me, this indicates that the Tserver is maintaining some state information for the ADN/ODN, as it reports immediately that the "resouce is out of service"
I also noticed in the Tserver log that the following message appears
"write is checked"
It may be that the Tserver is buffering the requests to the Applink for some reason, or may be not.
This problem results in agents not being able to login or go ready/not ready.
The number of extensions this impacts goes up to at least 50 over a few days, after which the customer is forced to restart the Tserver and Applink.
The MD110 Engineers have noticed that the following occurs as they see it on the MD110 and Applink.
Agent goes ready/not ready 30 times in one minute, works fine
Agent goes ready/not ready 45 times in one minutes, resource error occurs.
Tserver reports extension as being ready.
MD110 and Applink report extension as being not ready.
Sending a request from Desktop application to Tserver to go ready does not result in any message being sent to Applink.
Tserver reports resource out of service immediately.
Doing the above, they can simulate the problems we see easily on the lightly loaded TServer at ST2.
The main problems we see are at the Tserver at PHP 30th and 31st floor ,we are using the Tserver at ST2 for testing.
DN Information
ODN = 8269
ADN = 21269
ACD = 1898
Login = 6000
Password = 6000
We restarted the Tserver and the Applink, the retested.
I sent multiple ready/not ready requests as fast as possible, but could not get the "resource out of service" message using the Genesys Deskotp 5.1 client
I did see "write is checked" messages with up to 145 write checks at one stage.
We then tested using the in house CIC softphone.
After going ready/not ready for 30 seconds we got the resource out of service message after about 30 seconds.
I did notice that the CIC softphone does not buffer requests, the agent can press ready/not ready at will without waiting for any acknowledgement from Tserver.
The log file "event_request_sequence.log" shows the events and requests coming from the CIC Softphone.
I can see a sequence of 4 RequestAgentReady messages one after the other that do not result in an EventAgentReady being sent back to the CIC Softphone.
There is no indication in the log that the reference ID for these requests ever gets responded to.
This shows up as......
05/21/03 17:09:06.750 Trace ts_st2 TServer_ST2 GCTI-00-04541 Message RequestAgentNotReady received from 476 ( regular DesktopToolkitX )
05/21/03 17:09:07.734 Trace ts_st2 TServer_ST2 GCTI-00-04541 Message RequestAgentNotReady received from 476 ( regular DesktopToolkitX )
05/21/03 17:09:08.640 Trace ts_st2 TServer_ST2 GCTI-00-04541 Message RequestAgentNotReady received from 476 ( regular DesktopToolkitX )
05/21/03 17:09:09.640 Trace ts_st2 TServer_ST2 GCTI-00-04541 Message RequestAgentNotReady received from 476 ( regular DesktopToolkitX )
There are other instances of the Softphone sending unacknowledged messages to Tserver.
Is this a problem with the softphone or with the Tserver in that it is not forcing the serialization of events or losing events.
We then retested using five softphones and getting the users to send events about on every two seconds.
After 60 seconds, 2 extensions had come back with "resource out of service" -- see log file TServer_ST2.five_phones_over_one_minute_8275_and_8272.log
for extensions 8275 and 8272.
Finally we tested the same scenario as above (5 phones) using Genesys Softphone 5.1. We did not see any instance on the "resource" error, but instead got
generic state errors -- these could be fixed by changing the ADN and/or ODN into ready or not ready.
So, from all of this, is there something inherent in the Tserver that causes the "resource out of service" errors or can we conformtably resolve these by altering the softphone?
Is there some protection mechanism in the Tserver for multiple events that causes this error. ?
Answer/Resolution
This problem has relation to stability of reporting from the Application Link. Please note that customer configured all Agent devices with Switch Specific type 10. For such devices T-Server does not start monitor on Application link until Request Agent Login is requested from the application..
Before the RequestAgentLogin all requests except RequestRegisterAddress and RequestQueryAddress will be rejected with error "Resource Out Of Service" without interaction with the switch (because monitor is not started for that device).
All requests became acceptable only after RequestAgentLogin. And monitor will be stoped after Agent is requested RequestAgentLogout.
Therefore, to resolve this issue Agent should perform RequestAgentLogin regardless of actual Agent status is reported in Attribute Extension in event Registered (i.e. force request Login).
For the reference please see chapter "Limitation and Restrictions" in T-Server for Ericsson MD110 Reference Manual :
1. From Application Link service pack 4, Genesys cannot guarantee Ready/NotReady status for ODNs/ADNs at T-Server start/restart. With Application Link using service pack 4 or earlier, the switch fails to report the initial state for device and agent work modes at T-Server startup.
If customer is using Switch Specific type 10 for Agent DNs this paragraph became applicable not only to Startup scenarios, but also to Login-Logout scenarios.
PS. The situation with handling of incorrect reporting of initial Agent state on device might be improved in T-Server version 6.5.304.02. This version was built specifically for this customer. But anyway - force Request Login is the best solution.
Customer upgraded to HotFix TServer 6.5.304.02 and retested okay.
