Watchdog Mechanism

each watchdog executes the following actions control its own tomcat service and database; write information into its own logs communicate between each other and notify via heartbeat if a tomcat is down log the connection time to each instance if a master watchdog is down the next member takes on the mastership, after checking the down status if a master instance tomcat is down the watchdog notifies other watchdogs the next member takes on the mastership directly detailed table service master member action tomcat up down watchdog takes no extra action tomcat down up 1 master watchdog sends fail acknowledgment to another watchdog 2 member watchdog will initiate failover scenario tomcat down down watchdog takes no extra action watchdog up down watchdog takes no extra action watchdog down up 1 member will take on the mastership after checking the down status for three times (parametric) 2 member watchdog will initiate failover scenario watchdog down down watchdog takes no extra action wathdog,tomcat (happy path) up up master and member watchdog will send heartbeat and acknowledge information to each other and log all communication there are three services for the following actions a service checks the tomcat status it sends a request to the db; if it receives an answer (if there is connection), the service returns an ok a service runs the parameters, including instance information and threshold values related to the watchdog mechanism instance name, ip, and priority order from t instance table the threshold value of how many times it will check if an answer from the watchdog cannot be received, and how often the watchdogs will communicate those two values will be in the t system parameter table and will start with the watchdog a service will update the master instance information replication between each single connect instance is controlled periodically by watchdogs, and sapm jobs can also be checked and stopped, if necessary, along with the replication status for disabled sapm jobs disabled sapm job scenarios are outlined in the following table service master member action tomcat & database up down each watchdog stops sapm jobs in their instance replication status up down each watchdog stops sapm jobs in their instance watchdog up down active watchdogs stop sapm jobs in their instance tomcat & database down up each watchdog stops sapm jobs in their instance replication status down up each watchdog stops sapm jobs in their instance watchdog down up active watchdogs stop sapm jobs in their instance tomcat & database and replication (happy path) up up master and member watchdogs keep watching services and log all communications