feat(config): remove ineffective RocksDB table setters

[bladehan1]

What does this PR do?

Remove RocksDB block-table setters that were applied after setTableFormatConfig() and therefore never reached the native table factory.

Keep the existing storage.dbSettings.blocksize entries and Java API for compatibility, while documenting in reference.conf that the value is not currently applied to native RocksDB table options.

Add regression tests for the shipped Options-level configuration and the effective native block-table behavior.

Why are these changes required?

setTableFormatConfig() materializes the native table factory from the Java configuration at call time. The later block-size, shared-cache, index/filter-cache, L0-pinning, and Bloom-filter setters only changed the Java object and did not affect the native factory.

Moving those setters before setTableFormatConfig() would activate several unverified settings at once. In a fixed 500-block Mainnet replay, activating the combined settings reduced throughput from 2.421 blocks/s to 1.969 and 1.680 blocks/s, while restoring the pre-change effective native behavior produced 2.418 blocks/s.

This change therefore removes the ineffective setter sequence while preserving the behavior that nodes actually used before the change.

This PR has been tested by:

• ./gradlew :common:test --tests org.tron.common.setting.RocksDbSettingsTest
• ./gradlew :framework:test --tests org.tron.core.config.ConfigurationTest
• ./gradlew :framework:checkstyleMain
• ./gradlew :framework:checkstyleTest

Follow up

Evaluate block size, Bloom filters, shared-cache capacity, ownership, lifecycle, and observability independently with representative SR and database-specific workloads before enabling another RocksDB table profile.

Extra details

• blocksize remains configurable and observable for compatibility but is not applied to the native table factory.
• The existing static shared-cache object and accessor remain for separate configuration design and validation.
• No API, protocol, database-format, or migration changes are introduced.

Closes #49

---

Summary by cubic

Uses RocksDB's native block-table defaults and keeps storage.dbSettings.blocksize only for compatibility. Old behavior set block size, bloom filter, and cached index/filter blocks; new behavior sets no table options (defaults: 4 KB blocks, no bloom, index/filter not cached). No API, protocol, or DB-format changes.

Refactors

• Remove table-option setters that never reached the native table factory.
• Document in reference.conf that blocksize is not applied to table options.
• Add tests to verify native table defaults and preserve effective non-table RocksDB settings.
• Keep the shared LRU cache for future configuration.

Closes tronprotocol#6939

^{Written for commit 14922c4. Summary will update on new commits.}

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 75ea0bd9-c15f-4413-9d0c-d1ea0c3cfedf

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

1 issue found across 8 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="framework/src/test/java/org/tron/core/config/ConfigurationTest.java">

<violation number="1" location="framework/src/test/java/org/tron/core/config/ConfigurationTest.java:101">
P3: assertFalse(config.hasPath("storage.dbSettings.blocksize")) can never detect a regression because that key does not exist in config.conf, reference.conf, or DbSettingsConfig. The per-database blockSize override lives under storage.properties (DbOptionOverride.blockSize), not storage.dbSettings. Drop the assertion, or if you intend to guard the removal, assert on the namespace that actually carried the option.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: assertFalse(config.hasPath("storage.dbSettings.blocksize")) can never detect a regression because that key does not exist in config.conf, reference.conf, or DbSettingsConfig. The per-database blockSize override lives under storage.properties (DbOptionOverride.blockSize), not storage.dbSettings. Drop the assertion, or if you intend to guard the removal, assert on the namespace that actually carried the option.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At framework/src/test/java/org/tron/core/config/ConfigurationTest.java, line 101:

<comment>assertFalse(config.hasPath("storage.dbSettings.blocksize")) can never detect a regression because that key does not exist in config.conf, reference.conf, or DbSettingsConfig. The per-database blockSize override lives under storage.properties (DbOptionOverride.blockSize), not storage.dbSettings. Drop the assertion, or if you intend to guard the removal, assert on the namespace that actually carried the option.</comment>

<file context>
@@ -91,4 +92,19 @@ public void getConfigurationWhenOnlyConfFileName() {
+    Config config = Configuration.getByFileName("config.conf");
+    StorageConfig.DbSettingsConfig settings = StorageConfig.fromConfig(config).getDbSettings();
+
+    assertFalse(config.hasPath("storage.dbSettings.blocksize"));
+    assertEquals(7, settings.getLevelNumber());
+    assertEquals(256, settings.getMaxBytesForLevelBase());
</file context>

Suggested change

	assertFalse(config.hasPath("storage.dbSettings.blocksize"));
	// (remove the assertFalse on storage.dbSettings.blocksize; the key was never defined)

[bladehan1]

Addressed in a3bab81b05. The storage.dbSettings.blocksize entry is now retained in both config.conf and reference.conf to avoid an unnecessary configuration compatibility change. The configuration test verifies that the shipped value still resolves to 64 KiB, while the native Options test separately verifies that it is not applied to the RocksDB table factory.