Here's a tricky one...

[Dionysis]

Anyone ever had a agent desktop application that disconnects from the TServer because it's "too slow"?

I have a message popping up in my logs very consistently for 1 of my call centres where the agent desktop is pushed out over a Citrix desktop.  The TServer and the Citrix Server are in the same comms room with 1 firewall between them.  Ping is sub 100 ms however.

The event flow that is causing issues is as follows:

Event Ringing
(sent to desktop application and all relevant components)
Application Disconnects "reason: too slow"

EventEstablished
(sent to all components except the desktop app)

Because of this the desktop application doesn't receive the established event and no screen pop is generated, meaning the agent cannot save any call results and no reporting data is generated for the call.  A user event is also sent on the agent's DN by our call recorder and this is not received.  Meaning the application can't send the call recorder id at the end of the call to assign the relevant attached data.

I'm stumped on how to fix this one.  The problem is completely random and can affect users at any time, whether the servers are under load or when everything's quiet.

Anyone?

[Mike Kamlet]

The too slow message occurs because the T-Server client does not pull the messages fast enough from T-Server.  It has nothing to do with the network speed.

You need to see what the client application is doing and/or if there are other network issues such as window size that is preventing msgs from being acknowledged.

[Fra]

I got the same problem at a customer using GAD and was all related with the firewall, not with delay.

[S]

Reiterating what Mike said- its for TServer Client...
so it could be any TServer client, the app or any other server which is too slow to respond back... I have seen this for a call recording server connected to the TServer... well ... but it connects back after sometime...

[Dionysis]

Ugh... sounds like I'm reading packets today then.

I was kinda hoping for some kind of magical undocumented TServer option that would make it all go away.  :p

[Dionysis]

Well, I ran a constant ping between the 2 servers today and the max ping time was 50 ms, the rest of the day we ran sub 1ms with the occasional 10ms ping time.

Genesys tells me that there is no actual timeout, there is a buffer in the TServer that will cause this error as soon as it is full.  The buffer size is not configurable.

More analyzing of packets required by the look of it.  My guess is that this is a Citrix problem, but of course our Citrix administrator is pointing the finger at the network guy, who is simply saying "but ping works".

[cavagnaro]

The fact that a ping with only 32bits working is not good enought as Genesys data exchange is much much bigger. Lets try something:

On windows OS:
ping genesys -l 1024 -t

With this you will launch 1024 bits instead of the 32 default number. You can try to increase the 1024 number and see if it answers. If it doesn't answer with 1024 something bad is going on, maybe OS issue with MTU window or some TCP IP driver issue. On linux you will have more details of the data.

[Dionysis]

That is worth a try, we've had mtu issues with another part of our business this week aswell. 

Strange thing though, we have used these same Citrix Servers to run a softphone application for another call centre of ours in Aukland.  So the environment is Agents in New Zealand, connecting to Citrix Servers in Australia, which in turn connects to a TServer in Aukland. 

That environment had no issues at all.  The only difference being that the TServer we're having problems with is an Avaya and the other is Alcatel.

Perhaps there's some kind of weird bug with the version of Avaya TServer we're running.