Resolution:
Description:
= = = = = = =
This error occurs in situations where there are two EMS servers working in fault tolerant (ft)  mode and using a database (DB) for data storage. The main problem is that the active server is not able to send a heartbeat to the secondary server within the ft_activation time period, so that the standby server tries to become active while the active server is still active.

There are two situations when this issue happens:

1). The EMS server is busy. For the EMS server prior to EMS 5.1.4, the timers for the ft heartbeat and refresh locks are dependent, which could be blocked by the global lock. Sometimes when the EMS server is busy, it cannot send heartbeats in a timely fashion which will lead to this issue.

2). Network issues. The heartbeats from the active server are not reaching the standby server and the active server cannot connect to the database as well. This network glitch happens for more than the ft_activation period.

Workaround:
= = = = = = =
The issue can be avoided by increasing the ft_activation value. By default, the ft_activation is 10 seconds. You may increase this value to a higher value. By increasing the ft_activation value, the secondary server will wait for a longer time period to become active in case there is any intermittent network issue or a busy primary server.

Resolution:
= = = = = = =
Since EMS 5.1.4 server,  the following enhancement request has been implemented:
########################################
1-A1HUEA
Improve FT heartbeat response time when using database data store.
########################################
With this enhancement, the timers for ft heartbeat and refresh locks are now independent and the heartbeat is on its own thread. This will solve the issue where the heartbeat is blocked to be sent out to the standby server when the primary EMS server is busy.

EMS server log entry: “ERROR: lock not held by this server” .