[Bug] RocksDB table option setters are ineffective in 4.8.2.1

[bladehan1]

Bug Description

In GreatVoyage-v4.8.2.1, RocksDbSettings.getOptionsByDbName() passes a newly created BlockBasedTableConfig to Options.setTableFormatConfig() before applying the table-level setters.

setTableFormatConfig() creates and attaches the native RocksDB table factory immediately. The subsequent setters only modify the Java BlockBasedTableConfig object and do not update the native table factory that was already created.

Affected code:

java-tron/common/src/main/java/org/tron/common/setting/RocksDbSettings.java

Lines 214 to 220 in f8b05d4

	final BlockBasedTableConfig tableCfg;
	options.setTableFormatConfig(tableCfg = new BlockBasedTableConfig());
	tableCfg.setBlockSize(settings.getBlockSize());
	tableCfg.setBlockCache(RocksDbSettings.getCache());
	tableCfg.setCacheIndexAndFilterBlocks(true);
	tableCfg.setPinL0FilterAndIndexBlocksInCache(true);
	tableCfg.setFilter(new BloomFilter(10, false));

As a result, the configured block size, shared block cache, index/filter caching, L0 index/filter pinning, and Bloom filter are not reflected in native RocksDB. The Java configuration and startup logging therefore suggest behavior that the native database does not use.

Environment

Network

Mainnet

Software Versions

OS: Amazon Linux on AWS c6g.4xlarge (ARM64)
JVM: OpenJDK 17
Git Commit: f8b05d40abc949fa588ab64d8fd8fd82845ebeed
Version: 4.8.2.1
Code: 18825

Configuration

The replay used:

• A snapshot at block height 83,835,006
• A 500-block input
• A gp3 volume limited to 7,500 IOPS
• The shipped storage.dbSettings.blocksize = 64

The affected release uses RocksDB 9.7.4 on ARM64 and RocksDB 5.15.10 on x86_64.

Expected Behavior

RocksDB table settings exposed through java-tron configuration and applied by RocksDbSettings should be reflected in the native table factory and persisted OPTIONS-* configuration.

Alternatively, settings intentionally retained only for compatibility should be clearly documented as inactive and should not be applied through ineffective setters.

Actual Behavior

The table setters execute after native table-factory creation and do not affect the native OPTIONS-* configuration.

For the tested ARM64 build, the effective native table settings remain:

Native option	Effective value
block_size	4 KiB
Block cache	RocksDB 9.7.4 internal default, 32 MiB
cache_index_and_filter_blocks	false
pin_l0_filter_and_index_blocks_in_cache	false
filter_policy	nullptr
whole_key_filtering	true
block_restart_interval	16

The x86_64 build uses RocksDB 5.15.10, whose internal default block cache is 8 MiB.

In particular:

• The shipped 64 KiB blocksize does not change the native 4 KiB block_size.
• The shared 1 GiB cache is not attached.
• Index/filter caching and L0 pinning remain disabled.
• The configured 10-bit Bloom filter is not installed.

Changing only the call order is not a safe compatibility fix because it activates several previously inactive settings simultaneously.

In the fixed 500-block replay, the following multi-variable results were observed:

Configuration under test	Throughput	Change
Pre-change effective native settings	2.421 blocks/s	Baseline
Previously inactive settings activated, first run	1.969 blocks/s	-18.67%
Previously inactive settings activated, repeat run	1.680 blocks/s	-30.61%
Compatibility path restoring effective native settings	2.418 blocks/s	-0.12%

The direct-activation runs reached approximately 7,500 IOPS. Average DB Get latency increased from approximately 0.205 ms to 0.325 ms and 0.420 ms.

These are multi-variable results and must not be attributed to any single RocksDB option.

Frequency

• Always (100%)
• Frequently (>50%)
• Sometimes (10-50%)
• Rarely (<10%)

Steps to Reproduce

1. Use the RocksDbSettings.getOptionsByDbName() implementation from GreatVoyage-v4.8.2.1.
2. Open a fresh RocksDB database with the returned Options.
3. Inspect the generated OPTIONS-* file.
4. Compare the native table settings with the setters invoked after setTableFormatConfig().

The native configuration contains values such as:

block_size=4096
cache_index_and_filter_blocks=false
pin_l0_filter_and_index_blocks_in_cache=false
filter_policy=nullptr
whole_key_filtering=true
block_restart_interval=16

These values do not reflect the later Java table setters.

Logs and Error Messages

No exception is thrown. The failure is the mismatch between the Java configuration and the native RocksDB OPTIONS-* output.

Additional Context (Optional)

Possible Solution

Preserve the effective behavior used by existing nodes rather than moving setTableFormatConfig() after the setters:

• Retain blocksize in the configuration and Java API for compatibility, but document that it is not currently applied to native table options.
• Remove the ineffective table setter sequence without activating those settings.
• Retain existing effective Options-level settings.
• Verify the behavior using a fresh temporary database and its native OPTIONS-* file.
• Evaluate block size, Bloom filters, shared-cache capacity, index/filter caching, and L0 pinning independently before enabling a new table profile.

Acceptance criteria:

• blocksize and its existing API remain compatible and are documented as inactive.
• Ineffective table setters are removed without activating them through reordering.
• A fresh database retains the intended compatibility behavior: 4 KiB blocks, no Bloom filter, and no L0 index/filter pinning.
• Configuration tests, native Options tests, and Checkstyle pass.

[halibobo1205]

I agree with handling this in two stages:

1. Remove the ineffective setters now. This preserves the current effective behavior,
   while keeping the existing configuration/API documented as inactive.
2. Evaluate actually enabling these options separately. Some tests showed that
   enabling them together reduced throughput.

The common lesson from this issue and #6926 is that Java-side assignment does not prove
the final value is effective. Tests should use distinct non-default values and verify
the actual output boundary: native OPTIONS-*/metrics for JNI configuration, and the
generated protobuf fields for mappings. We should also consider static checks for
duplicate builder setters and configure JNI objects completely before installing them.