[ISSUE #10651] Upgrade DLedger to 0.3.3-SNAPSHOT

[leizhiyuan]

Which Issue(s) This PR Fixes

• Fixes [Enhancement] Upgrade DLedger to 0.3.3-SNAPSHOT #10651

Brief Description

This PR upgrades the DLedger dependency to 0.3.3-SNAPSHOT and adapts RocketMQ to the related API changes:

• Update DLedger future imports to io.openmessaging.storage.dledger.common.
• Replace setEnableBatchPush with setEnableBatchAppend.
• Read the committed index from MemberState after DLedgerStore#getCommittedIndex() was removed.
• Adapt the DLedger controller state machine to the new ApplyEntryIterator API.
• Derive the committed position from the committed DLedger entry after DLedgerMmapFileStore#getCommittedPos() was removed.
• Remove the obsolete fastjson1 dependency and switch the remaining compatibility test usage to fastjson2.

How Did You Test This Change?

• mvn -DskipTests -Dspotbugs.skip=true compile
• mvn -DskipTests -Dspotbugs.skip=true test-compile
• git diff --check

[leizhiyuan]

I will change the version number after Dledger releases the version.

[RockteMQ-AI]

Review by github-manager-bot

Summary

Upgrades DLedger dependency from 0.3.2 to 0.3.3-SNAPSHOT and adapts RocketMQ to the resulting API changes (package reorganization, method renames, removed APIs). Also removes the fastjson v1 dependency in favor of fastjson2.

Findings

• [Warning] remoting/src/test/java/.../RemotingSerializableCompatTest.java — The checkCompatible method was originally designed to verify cross-version serialization: serialize with fastjson v1, deserialize with fastjson v2. After this change, both serialization and deserialization use fastjson2, so the test no longer validates fastjson v1 → v2 backward compatibility. If backward compatibility with data previously serialized by fastjson v1 is still a concern, consider using pre-serialized JSON string fixtures instead of relying on the fastjson v1 library at runtime.

• [Warning] store/src/main/java/.../DLedgerCommitLog.java — The new getCommittedPos() method catches Throwable, which is overly broad. Consider catching Exception instead to avoid masking JVM-level errors (e.g., OutOfMemoryError). Additionally, this method performs a DLedgerStore lookup on every call and is invoked from multiple paths (getMaxOffset, truncate, getData). If getCommittedIndex() is cheap but the subsequent entry fetch is not, consider documenting the performance characteristics or caching the committed position.

• [Info] pom.xml — The DLedger version is set to 0.3.3-SNAPSHOT. Ensure this SNAPSHOT is published to a reliable Maven repository and that the PR is not merged until DLedger 0.3.3 is officially released (or the SNAPSHOT is stable).

• [Info] controller/src/main/java/.../DLedgerControllerStateMachine.java — The migration from CommittedEntryIterator to ApplyEntryIterator looks correct. The ApplyEntry.getEntry() call properly retrieves the underlying DLedgerEntry.

Suggestions

1. Consider adding a brief comment on getCommittedPos() explaining why it was introduced (upstream API removal) to help future maintainers understand the indirection.
2. The fastjson v1 removal is clean. If this is the last usage of fastjson v1 in the project, consider also removing the fastjson.version property from the parent POM if it exists.

---

Automated review by github-manager-bot

[RockteMQ-AI]

Review by github-manager-bot

Summary

Upgrades DLedger from 0.3.2 to 0.3.3-SNAPSHOT, adapting to API changes in the DLedger library. Also removes the legacy fastjson v1 dependency (replaced by fastjson2), and changes how committed position is calculated.

Findings

• [Warning] pom.xml:125 — Using 0.3.3-SNAPSHOT for a production dependency is risky. SNAPSHOT versions are mutable and not suitable for release branches. Ensure this is tracked to be updated to a release version before the next RocketMQ release.
• [Warning] DLedgerCommitLog.java:159-175 — The new getCommittedPos() method derives committed position from committedIndex → entry lookup → pos + size. This is more indirect than the previous dLedgerFileStore.getCommittedPos(). The catch-all Throwable and returning -1 on failure is safe, but consider:
  1. What happens if committedIndex is valid but the entry has been truncated/compacted? The get() would return null and -1 is returned, which could affect offset calculations.
  2. Performance: this now does an entry lookup on every getMaxOffset() and truncate() call. If these are hot paths, consider caching.
• [Info] DLedgerRoleChangeHandler.java:83 — getCommittedIndex() moved from DLedgerStore to MemberState. Consistent with the DLedger API refactoring.
• [Info] DLedgerControllerStateMachine.java:55-58 — CommittedEntryIterator → ApplyEntryIterator with ApplyEntry.getEntry() wrapper. Clean adaptation.
• [Info] DLedgerCommitLog.java:101 — setEnableBatchPush → setEnableBatchAppend. API rename in DLedger.
• [Info] fastjson v1 removal from common/pom.xml and migration of @JSONField annotation to fastjson2 in the compat test. Good cleanup.

Suggestions

1. Track the SNAPSHOT → release version upgrade
2. Consider adding a brief comment on getCommittedPos() explaining why the indirect lookup is needed (API change in DLedger 0.3.3)

Verdict

Necessary dependency upgrade with correct API adaptations. The SNAPSHOT version and the new getCommittedPos() implementation are the main concerns.

---

Automated review by github-manager-bot