'EventReleased' Queued in TServer?

[Ritchie]

The following is a small extract from my tserver log. Does anyone have any ideas why each request is queued? Why is the switch not responding, seemingly, quick enough?


Mon Apr 14 17:34:13 2003.627 Trace donald LucentG3 GCTI04541 Message RequestAgentReady
received from 176 ( regular )
@17:34:13.6276 [0] Received from 176 (c508 ): message RequestAgentReady
AttributeThisQueue '25061'
AttributeThisDN '20248'
AttributeAgentWorkMode 0
AttributeReferenceID 52
TESTLV2: request queued
Mon Apr 14 17:34:13 2003.628 Trace donald LucentG3 GCTI04541 Message RequestAgentReady
received from 82 ( regular )
@17:34:13.6281 [0] Received from 82 (c4ab ): message RequestAgentReady
AttributeThisQueue '25061'
AttributeThisDN '20224'
AttributeAgentWorkMode 0
AttributeReferenceID 74
** ts6.5.202[1] ** 17:34:13.6283
08 00 00 2B 08 02 14 88 64 96 1C 23 91 A1 20 02 01 85 02 01 8F 40 18 96 48 01 81 49 06 81 32 35 30 3
6 B1 49 06 83 32 30 32 32 B4 49 02 86 83
=== parsed message ===
prot_discr = 8
CRV = 1488
MsgType = 100 (REGISTER)

Facility: serv_discr = 17(q932_suppl) fac_ie = component_tag = A1(INVOKE)
invoke_id tag: 02, value = 133
operation tag: 02, value = 143(FeatureRequest)
params = q931_tag = 40
list =
Feature: feature = 1(ChangeWorkModes)
Domain: # elems = 3
type = 1(ACD_Split) address = [5] 32 35 30 36 31 '25061'
type = 3(Extension) address = [5] 32 30 32 32 34 '20224'
type = 6(WorkMode) address = [1] 03

Mon Apr 14 17:34:13 2003.629 Trace donald LucentG3 GCTI04541 Message RequestAgentReady
received from 82 ( regular )
@17:34:13.6292 [0] Received from 82 (c4ab ): message RequestAgentReady
AttributeThisQueue '25061'
AttributeThisDN '20224'
AttributeAgentWorkMode 0
AttributeReferenceID 75
TESTLV2: request queued
** link[1] ** 17:34:13.6382

[Vic]

I did not spend too much looking at it, but I have noticed the following which is really strange:
You have an agent at 20224 trying to enter Ready state:
@17:34:13.6281 [0] Received from 82 (c4ab ): message RequestAgentReady
AttributeThisQueue '25061'
AttributeThisDN '20224'
AttributeAgentWorkMode 0
AttributeReferenceID 74

Then you are issuing the same requestagentready message again 10ms later from the same client (client 82)

@17:34:13.6292 [0] Received from 82 (c4ab ): message RequestAgentReady
AttributeThisQueue '25061'
AttributeThisDN '20224'
AttributeAgentWorkMode 0
AttributeReferenceID 75
TESTLV2: request queued

Here is what my first guess would be:
you had a network congestion which lasted for less than 3 seconds and caused your first Ready request from your softphone to take for example 3 seconds to reach TServer. Your agent not gettng the expected response right away, pressed the ready button again and probably it was queued at the router to. So, they arrived at Donald TServer at the same time, causing this error.

If not then check your softphone to see that you are not issuing double requestagentready! I know it sounds bizzare because probably you are using the same softphone with the rest of the agents, but this is the only thing I can think off other than that

Anything in release notes? What TServer version do you have?

[Ritchie]

Cheers Vic, I actually noticed that myself after I posted the log file. I showed my developer and a fix was rolled out last night. There is a button which they recently put on the app that releases the call and puts the agent ready. I was here that the code sent 2 requests.

Unfortunately, the real problem is still with us. It appears that after getting a C_NETCONJ message from the switch for a DN, TServer will 'hold' on to this DN and Queue any Events issued later. The only way to resolve so far is to either use a different DN or bounce TServer (which I did last night also).

I think it has to do with TServer not understanding the response from the switch properly, and thus not dealing with the DN in a partictularly helpful way!

[Vic]

Ritchie,

so it was a softphone bug and net congestion, right?
You are 100% right about NETCONJ it is not being handled correctly. I think it would be interesting to ask Genesys about the logic behind TServer's response to NETCONJ... Any volunteers?

[Ritchie]

Yup here is the official response from Genesys:
'...it is probably caused by a defect in tserver. We believe this defect has been fixed in the latest hotfix, 6.5.307.03. I suggest to put this version in place if we are getting cases of 'stuck' DNs...'

So, new version to put live this weekend then!