" /> HA - client behaviour - Genesys CTI User Forum

Author Topic: HA - client behaviour  (Read 3840 times)

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
HA - client behaviour
« on: September 18, 2008, 02:10:32 AM »
Advertisement
Hi guys,
I'm finishing my HA lab and have one question and would like to know how you handle this, I already have a solution but would like to now if there is another as mine requires modifying source code and would like to avoid it.

When Main Tserver is down and backup Tserver is up, usually our clients will try to connect directly to Main Tserver port, but as it is down, connection will fail. So anyway so handle this on Genesys Framework? Maybe installing HA Proxy? Because my solution is to modify the code that when main connection fails it tries to connect to the second one, however a connection failure doesn't mean necesarilly that main TServer is down.

Thanks for any ideas...

Offline Steve

  • Sr. Member
  • ****
  • Posts: 298
  • Karma: 11
Re: HA - client behaviour
« Reply #1 on: September 19, 2008, 11:49:18 AM »
It depends on the client you are talking about.  :-\

If it's a desktop/soft phone type app that connects directly to the T-Server, then you would need to code in the HA switchover.

If it's a T-server client like Stat-server or URS, the framework will take care if it. Providing you have set up the primary/backup properly in CME.

Steve

Offline Dionysis

  • Sr. Member
  • ****
  • Posts: 408
  • Karma: 8
Re: HA - client behaviour
« Reply #2 on: September 19, 2008, 01:20:38 PM »
It also depends on the TServer.

On an Avaya TServer the switchover events are different to an Alcatel TServer for example. 

Using an Alcatel you get a specific event when a switch over occurs, "EventPrimaryChanged", so provided the client is connected to the TServer when it switches over it will work perfectly.  However if the TServers switch when the client is not connected it doesn't know where to connect to when it doesn't get a successful connection on the first attempt.

On an Avaya this event doesn't get sent, meaning you cannot have a hot standby softphone without specifically coding a reaction to the "EventLinkDisconnected" message.

HA softphone apps are a lot of fun.  When I've been involved in building them it's very often been a case of everything working in testing, then you move into production and restart the TServers in the middle of the day, only to bring down 1000 agent desktop apps in one hit.  *eek*





Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: HA - client behaviour
« Reply #3 on: September 19, 2008, 03:52:46 PM »
Hi guys,
I have been testing efectively Alcatel Tserver HA, it works fine at lab. CME applications switch over easily and no notice from any error. We have a small agent group who are like rat labs hehe
When I talk about agent desktop I mean activex desktop toolkit for example or any other that I have made to talk directly to TServer. When on operation and running as soon as Tserver main goes down the clients receives the switchover event, very nice as I didn't have to code anything. But a "problem" raised yesterday when testing and did a forced shutdown of main TServer and an agent came to work late and he couldn't connect. So we had to modify an INI file to make him work, and that is how my question raised.

Another question, is there any way to know which TServer is main? Some command I can launch, query, something?

Offline LeszekM

  • Newbie
  • *
  • Posts: 23
  • Karma: 0
Re: HA - client behaviour
« Reply #4 on: September 19, 2008, 05:02:39 PM »
The connection / reconnection procedure recommended by Genesys (in the TLib reference guide) is:


1. You have got to know the host / port for both TServers (primary and backup)

2. Try to connect to the primary.
3. If it wasn't possible to connect goto 6
4. handle events (normal work of the application - as we are connected)
5 If you received EventLinkDisconnected goto 6

6. Wait a few seconds
7. Try to connect to the backup TServer.
8. If it wasn't possible to connect then goto 11
9. handle events (normal work of the application - as we are connected)
10 If you received EventLinkDisconnected goto 11
11. Wait a few seconds
12. Goto 2


This procedure is universal in the sense that it works in the case of warm-standby and hot-standby modes (then you never receive EventLinkDisconnected as the TLibrary hides this and reconnects by itself).


You can check the current state of a TServer by calling RequestQueryServer which sends back EventServerInfo which has ServerRole attribute. But you have to be connected to the TServer to call RequestQueryServer....
So at the initialization in my opinion you should just try to conect: if you can connect to the TServer, it is primary......

As I know it will be (is?) possible (using the Platform SDK) to ask SCS about which TServer is primary at the moment.

Regards,
Leszek

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: HA - client behaviour
« Reply #5 on: September 19, 2008, 05:32:42 PM »
Nice! Thanks a lot!