If a messaging engine is configured to use a data store
and cannot connect to its data store, for example because the database
that contains the data store is not running, the messaging engine
does not start. You can tune your system to increase the chance of
a successful start of the messaging engine.
About this task
In a single-server environment, when you start the application
server the messaging engine attempts to start. If the database is
unavailable for more than 15 minutes, the messaging engine might enter
the stopped state and need to be started manually.
In a high availability environment,
a messaging engine starts either as part of the server or cluster
startup, or as part of the failover process. During messaging engine
startup, the messaging engine attempts to connect to the data store,
for up to 15 minutes by default. If one of the following statements
remains true during that time, the messaging engine cannot start on
the server, and the server is disabled for high availability:
- The database is unavailable or not running.
- In a failover situation, the database does not detect the loss
of the network connection to the original application server, and
therefore does not release the locks on the data store.
This disabled state can propagate to all members of the cluster.
You must manually re-enable the servers to maintain your high availability
environment.
You can increase the chance of the messaging engine
starting successfully by configuring various parameters, such as the
15 minute default timeout, on the database server or application server.
Results
By configuring these parameters and custom properties, you
minimize the amount of time taken for the database server to detect
the loss of a network connection, and ensure that the messaging engine
waits for a reasonable amount of time for the database connection
to recover before attempting to start.
What to do next
You might want to configure the messaging engine and server
to restart in the event of a database connection failure. This behavior
reduces the risk of the messaging engine being in an inconsistent
state when the database connection is restored.