[Troubleshooting] Inconsistent JDBC SQL Logging in Ambience/Repertoire 202x

Repertoire 202x
,
1

Overview

JDBC SQL statements may appear in the logs during initial datasource executions but stop appearing after repeated executions.

This behaviour can occur because DuplicateMessageFilter is enabled in logback.xml. The filter suppresses repeated log messages even with the JDBC datasource logger set to DEBUG.

Step 1: Identify The Logging Pattern

Execute the affected datasource several times and compare the returned data with the application log.

A typical pattern is:

Execution Datasource result SQL log
Initial executions Data returned successfully SQL appears
Further executions of the same query Data returned successfully SQL stops appearing

This pattern can make logging appear inconsistent between datasources.

Step 2: Verify The Active Logging Configuration

Locate etc/logback.xml in the installation responsible for datasource execution.

Ensure the following declaration is present within <configuration>:

<logger name="com.elixirtech.data2.datasource" level="DEBUG" />

Inspect the application log configured to receive the DEBUG messages.

Step 3: Review Duplicate-Message Filtering

Locate etc/logback.xml in the installation responsible for datasource execution.

Verify whether the following filter declaration is active:

<turboFilter class="ch.qos.logback.classic.turbo.DuplicateMessageFilter" />

This filter suppresses repeated messages after its repetition allowance is exceeded. Consequently, a SQL statement may cease to appear while a different statement continues to be logged.

Step 4: Verify Whether The Filter Causes The Behaviour

Perform the following comparison in a test environment.

With the filter enabled:

  1. Restart the application.
  2. Execute the affected datasource repeatedly, for example eight times.
  3. Keep the SQL and parameter values unchanged.
  4. Record whether each execution returns data and prints its SQL.

With the filter disabled:

  1. Back up logback.xml.

  2. Temporarily comment out the duplicate message filter:

    <!--
<turboFilter class="ch.qos.logback.classic.turbo.DuplicateMessageFilter" />
-->

  3. Keep the JDBC datasource logger set to DEBUG.

  4. Save the file and restart the application.

  5. Repeat the same executions and inspect the same log destination.

If disabling the filter restores consistent SQL logging across repeated executions, the behaviour is attributable to duplicate-message suppression.

Temporarily disabling DuplicateMessageFilter allows repeated messages to be captured during troubleshooting. Leaving it disabled can increase log volume across the application.

What This Clarification Achieves

  • Explains why SQL logging may appear inconsistent between datasources.
  • Clarified why enabling DEBUG alone may not capture every execution.
  • Provides a controlled test to confirm duplicate-message suppression.