Fail-Fast Mode for Synchronous Logging
A logger is configured to use fail-fast mode when all of the following are true:
The logger is synchronous.
The logger writes data to a database.
The logger uses a JDBC functional alias associated with a JDBC pool alias.
Fail-fast is enabled for the JDBC functional alias.
The logger is specified in the watt.server.audit.failFastLoggers server configuration property or the server configuration parameter is empty. When watt.server.audit.failFastLoggers is empty and fail-fast is enabled in the ISCoreAudit functional alias,
Integration Server, all synchronous loggers with a database destination will have fail-fast capability.
Fail-fast mode is a capability of a JDBC functional alias that allows requests for a database connection to fail immediately if a previous request failed because of a transient error. By causing requests that will not succeed to fail quickly, Integration Server eliminates the time a request spends making retry attempts.
When fail-fast mode is enabled and the JDBC pool alias used by the JDBC functional alias cannot establish a connection to the database, the JDBC functional alias enters fail-fast mode. In fail-fast mode:
All attempts by an
Integration Server component that uses the JDBC functional alias to get a database connection will return immediately with a SQLException.
The JDBC function monitors database connectivity. When database connectivity is restored, the JDBC functional alias exits fail-fast mode.
Integration Server components that use the JDBC functional alias to obtain a database connection will obtain a connection when one is requested.
Fail-fast mode can improve performance when used with synchronous audit logging. When a synchronous logger encounters a transient error while attempting to write to the audit logging database, the ISCoreAudit function, which is used by the logger, attempts to reconnect and write to the database after waiting the amount of time specified in the Wait Between Retries field for the logger. The ISCoreAudit function continues to retry connecting and writing to the database until it succeeds or the makes the maximum number of retries specified for the logger, which is specified in the Maximum Retries field. Additionally, if the transient error occurs because the database is unavailable, each attempt to connect to the database will pause while the logger waits for the connection attempt to fail. All of the waiting contributes to synchronous audit logging becoming very slow when the audit logging database is unavailable.
However, if the ISCoreAudit function has fail-fast enabled, the first time that audit logging fails because the database is unavailable, the affected loggers stop trying to write to the database. Any loggers that use the functional alias to request a database connection return with an exception immediately when the logger makes a request for a database connection. The logger does not make any attempts to retry. After connectivity is restored, the ISCoreAudit functional alias exits fail-fast mode The affected loggers resume normal operation. As a result of using fail-fast mode, client threads that generate audit records do not experience the pauses associated with database connection timeouts.
Note: For the initial audit log entry that cannot be written to the database because of a transient error that prevents a connection to the database, Integration Server retries writing the entry according to the Maximum Retries and Wait Between Retries properties configured for the logger. If connectivity to the database is not restored before Integration Server exhausts the retries, Integration Server writes the audit log entry to the FailedAudit log. That is, Integration Server writes the audit log entry that triggers fail-fast mode for the logger to the FailedAudit log if Integration Server makes the maximum number of retry attempts before connectivity to the database is restored.