src/main/asciidoc/how-to/operations/logging.adoc, section [[logging-levels]] (L50), presents third-party log suppression as something done entirely in arcadedb-log.properties, and uses a Ratis entry as its one worked example (L66):
org.apache.ratis.grpc.server.GrpcLogAppender.level = SEVERE
Since ArcadeData/arcadedb#7208 (issue #6991, v26.10.1) that is no longer the whole picture, and the page as written implies it is.
What changed
A second Ratis warning is now suppressed:
Snapshot file SingleFileSnapshotInfo(t:N, i:M):[.../sm/snapshot.N_M] has missing MD5 file.
It was logged at WARNING once per rediscovered snapshot marker, on every checkpoint and every restart, so the volume grew with node uptime. It is suppressed by a java.util.logging.Filter in Java - com.arcadedb.server.ha.raft.ratis.RatisSnapshotDigestWarningFilter - not by a properties entry.
The reason it cannot be a properties entry is the part worth documenting, because it is the general rule rather than a one-off: org.apache.ratis.statemachine.impl.SimpleStateMachineStorage also emits Failed to updateLatestSnapshot from ... for genuine I/O failures on the snapshot directory, and a JUL properties file cannot express a per-message threshold. Pinning that logger to SEVERE would hide the real failures along with the noise.
Suggested changes
1. logging.adoc, after the GrpcLogAppender example. A short note that not every suppression is a properties line: where a logger mixes by-design noise with genuine failures, ArcadeDB installs a message-scoped JUL Filter instead, and RatisSnapshotDigestWarningFilter is the current instance. Worth adding that the filter drops the record only at WARNING or below, so a future Ratis release that raised the same text to SEVERE would still be heard.
This matters for two audiences: someone who notices the warning disappeared after upgrading and wants to know why, and someone who wants it back and will otherwise search arcadedb-log.properties and find nothing.
2. how-to/operations/ha.adoc, under Troubleshooting (which today holds only "Performance: insertion is slow" and "Verbose HA logging"). A short entry explaining the warning itself, for operators reading logs from an older version:
ArcadeDB's real snapshot is the set of database files already flushed by the TransactionManager, so the file Ratis inspects is a zero-byte marker whose name carries the (term, index) used for log-purge bookkeeping. It deliberately has no .md5 companion, so this warning never indicated corruption.
Applies from the release carrying ArcadeData/arcadedb#7208 (v26.10.1).
Related: ArcadeData/arcadedb#7209, filed during the same work - SimpleStateMachineStorage.cleanupOldSnapshots only advances its delete index past markers that have an md5, so these zero-byte markers are never pruned and accumulate for the life of a node. That is an engine fix, not a docs task, but it is why the warning count grew with uptime.
src/main/asciidoc/how-to/operations/logging.adoc, section[[logging-levels]](L50), presents third-party log suppression as something done entirely inarcadedb-log.properties, and uses a Ratis entry as its one worked example (L66):Since ArcadeData/arcadedb#7208 (issue #6991, v26.10.1) that is no longer the whole picture, and the page as written implies it is.
What changed
A second Ratis warning is now suppressed:
It was logged at WARNING once per rediscovered snapshot marker, on every checkpoint and every restart, so the volume grew with node uptime. It is suppressed by a
java.util.logging.Filterin Java -com.arcadedb.server.ha.raft.ratis.RatisSnapshotDigestWarningFilter- not by a properties entry.The reason it cannot be a properties entry is the part worth documenting, because it is the general rule rather than a one-off:
org.apache.ratis.statemachine.impl.SimpleStateMachineStoragealso emitsFailed to updateLatestSnapshot from ...for genuine I/O failures on the snapshot directory, and a JUL properties file cannot express a per-message threshold. Pinning that logger toSEVEREwould hide the real failures along with the noise.Suggested changes
1.
logging.adoc, after theGrpcLogAppenderexample. A short note that not every suppression is a properties line: where a logger mixes by-design noise with genuine failures, ArcadeDB installs a message-scoped JULFilterinstead, andRatisSnapshotDigestWarningFilteris the current instance. Worth adding that the filter drops the record only at WARNING or below, so a future Ratis release that raised the same text to SEVERE would still be heard.This matters for two audiences: someone who notices the warning disappeared after upgrading and wants to know why, and someone who wants it back and will otherwise search
arcadedb-log.propertiesand find nothing.2.
how-to/operations/ha.adoc, underTroubleshooting(which today holds only "Performance: insertion is slow" and "Verbose HA logging"). A short entry explaining the warning itself, for operators reading logs from an older version:Applies from the release carrying ArcadeData/arcadedb#7208 (v26.10.1).
Related: ArcadeData/arcadedb#7209, filed during the same work -
SimpleStateMachineStorage.cleanupOldSnapshotsonly advances its delete index past markers that have an md5, so these zero-byte markers are never pruned and accumulate for the life of a node. That is an engine fix, not a docs task, but it is why the warning count grew with uptime.