Failover
Desktop apps starting with 6.2.x.18 have the ability to fail over from one
BlackBerry AtHoc
server (the primary) to a secondary server. When the primary server becomes unresponsive and CUs fail, desktop apps that have a failover URL will fail over; that is, they will swap the Base URL with the failover URL.Server version | Notes |
|---|---|
6.1.8.76 | Failover URLs appear on the Desktop Software tab. |
7.4 | Failover URLs appear in Settings > Desktop App . |
Desktop app version | Notes |
|---|---|
6.2.x.263 | (2010) More robust failover support. |
6.2.x.269 | (2014) Fixed issues in failover URL handling. |
6.2.x.272 | (2016) Fixed issue with invalid user token on failover and failback. |
6.2.x.278 | (2018) The desktop client attempts to contact the current server the number of times configured in the "Reconnect Attempts Before Failover" setting before trying the failover server. |
There can be only one failover URL. You can configure the failover server URL in the
BlackBerry AtHoc
management system at Settings
> Desktop App
. The desktop app picks up the failover URL at SO but not at CU.The desktop app stores the failover URL in the registry value “alternateBaseUrl1.”
Failover occurs automatically. If the desktop app is unable to connect at CU, it will keep trying until it exceeds the value in “Reconnect Attempts Before Failover” in the Failover section of the Desktop App settings. The desktop app then increments the LastBaseUrlIndex registry value. If this value is not present, the desktop app creates the string value and sets it to 1. The desktop app then attempts to connect using the next alternateBaseUrl(n), where n is the value in LastBaseUrlIndex in
hkcu\software\
.AtHoc
[edition]\After the desktop app is connected to the failover server, if that server stops responding, the desktop app resets LastBaseUrlIndex to 0 and attempts to connect using the original Base URL value.
BlackBerry AtHoc
desktop apps running versions earlier than 6.2.x.269 do not reset the LstBaseUrlIndex correctly.Caveats to consider when configuring Failover URLs
For desktop app versions 6.2.x.268 and lower, the secondary server must have the same number of Failover URLs, otherwise the desktop app clears the registry values for any alternateBaseUrl(n) that does not exist in Failover Servers. However, the desktop app increments the LastBaseUrlIndex during fail back. This causes the desktop app to attempt to use the empty alternateBaseUrl(n) value. Subsequent CUs fail, and LastBaseUrlIndex is incremented. The fix is to delete LastBaseUrlIndex or set it to 0.
For desktop app versions 6.2.x.271 and lower, the user token (and possibly the userid) may be invalid when failing over or failing back. Users should be present in the failover system because it should be a recent copy of production. However, the user token or session ID may not be current which causes the server to reject the SO.