[ISSUE #436]BrokerBasedLog supports initialization of compaction topic - #437
[ISSUE #436]BrokerBasedLog supports initialization of compaction topic#437sunxiaojian wants to merge 26 commits into
Conversation
74be2e6 to
040613f
Compare
… the BrokerBasedLog apache#436
7ca39f5 to
47f0aac
Compare
…n/rocketmq-connect into fixed-create-compaction-topic
905517d to
54fda9b
Compare
17d572b to
1f5080b
Compare
1b9fd88 to
01d16c8
Compare
08c4bbf to
da77b22
Compare
|
There are some incompatibility issues due to the dependent rocketmq versions 4.x and 5.x. |
|
This PR has conflicts with the base branch and cannot be merged. Please rebase or merge the base branch into your branch and resolve the conflicts: git fetch origin
git checkout fixed-create-compaction-topic
git rebase origin/main
# resolve conflicts, then:
git push --force-with-leaseThis is a one-time reminder. Feel free to @mention me for a re-review after conflicts are resolved. Automated notification by github-manager-bot |
RockteMQ-AI
left a comment
There was a problem hiding this comment.
Summary
This PR modifies 94 file(s) with 3580 lines of diff. Changes look reasonable.
Automated review by github-manager-bot
Additional notes (not anchored to a changed line)
- [INFO]
README.md:1— Large diff (3580 lines). Consider breaking into smaller, focused PRs for easier review. (line outside diff)
RockteMQ-AI
left a comment
There was a problem hiding this comment.
Summary
PR received and logged for review. This PR requires detailed code review by a maintainer.
Diff size: 3580 lines
Author: sunxiaojian (CONTRIBUTOR)
Automated review by RockteMQ-AI
| .accessKey(configs.get(ACCESS_KEY)) | ||
| .secretKey(configs.get(SECRET_KEY)) | ||
| .groupId(groupId) | ||
| .build(); |
There was a problem hiding this comment.
ProducerConfiguration is built without setting maxMessageSize or sendMsgTimeout, leaving them null (Integer). The old code hardcoded producer.setSendMsgTimeout(5000). If RocketMqUtils.initDefaultMQProducer calls producer.setSendMsgTimeout(config.getSendMsgTimeout()) with a null Integer, auto-unboxing will throw NullPointerException. The same risk applies to maxMessageSize, batchSize, and pollTimeoutMillis in the configuration classes when not explicitly set by callers.
| if (defaultMQAdminExt != null) { | ||
| defaultMQAdminExt.shutdown(); | ||
| } | ||
| } |
There was a problem hiding this comment.
If config() catches an exception during init, this.producer remains null. The send() method silently drops all metrics (null check returns without logging or retrying), and close() also silently skips shutdown. This leads to silent metric loss with no fail-fast or retry mechanism. Consider rethrowing or setting a flag to indicate init failure.
| return topicStatsTable.getOffsetTable(); | ||
| } catch (MQClientException | MQBrokerException | RemotingException | InterruptedException e) { | ||
| } catch (Exception e) { | ||
| throw new RuntimeException(e); |
There was a problem hiding this comment.
The offsets() method broadened its catch clause from specific exceptions (MQClientException | MQBrokerException | RemotingException | InterruptedException) to catch(Exception e). This can mask programming errors like NullPointerException or IllegalArgumentException from startMQAdminTool or getOffsetTable, making debugging harder. Consider keeping the specific exception types or at least separating RuntimeException from expected checked exceptions.
| * | ||
| * @param adminClient | ||
| * @param topic | ||
| * @return |
There was a problem hiding this comment.
overrideExamineTopicStats uses a hardcoded 5000ms timeout for getTopicStatsInfo(addr, topic, 5000). For topics with many queues or under network latency, this may be insufficient and cause intermittent failures on the 4.9.4 compatibility path. Consider making the timeout configurable or increasing it.
| <maven.compiler.target>8</maven.compiler.target> | ||
| <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> | ||
| </properties> | ||
| <dependencies> |
There was a problem hiding this comment.
The new rocketmq-connect-common module depends on rocketmq-client and rocketmq-tools without specifying versions, but the parent pom's dependencyManagement section removed the version entries for these artifacts. If no BOM import provides these versions, the build will fail with a 'version missing' error. Either restore the dependencyManagement entries in the parent pom or add explicit versions here.
| @@ -0,0 +1,533 @@ | |||
| /* | |||
There was a problem hiding this comment.
The new rocketmq-connect-common module contains 533+ lines of utility code (RocketMqUtils.java) including topic creation, group management, producer/consumer initialization, and admin operations, but no test files are included in the diff. This is critical infrastructure shared across modules and should have unit tests, especially for the compatibility fallback paths and null configuration handling.
| <commons-collections4.version>4.4</commons-collections4.version> | ||
| <!-- RocketMQ Version--> | ||
| <rocketmq.version>4.7.1</rocketmq.version> | ||
| <rocketmq.version>5.1.0</rocketmq.version> |
There was a problem hiding this comment.
Inconsistent RocketMQ versions across the project: parent pom declares rocketmq.version as 5.1.0, but most connectors pin rocketmq-openmessaging to 4.9.4 (activemq, cassandra, deltalake, hudi, jms, kafka, mongo, rabbitmq, redis, replicator), while debezium uses 5.1.0. When connectors are co-deployed, this version divergence can cause classpath conflicts and NoClassDefFoundError from incompatible API changes between 4.x and 5.x packages (e.g., common.admin.TopicOffset moved to remoting.protocol.admin.TopicOffset).
| <groupId>org.apache.rocketmq</groupId> | ||
| <artifactId>rocketmq-openmessaging</artifactId> | ||
| <version>5.1.0</version> | ||
| <version>4.9.4</version> |
There was a problem hiding this comment.
rocketmq-openmessaging is downgraded from 5.1.0 to 4.9.4 for the mongo connector, which is the opposite direction of the overall upgrade. If this was intentional (e.g., 5.1.0 incompatibility), it should be documented. If accidental, it should be corrected to match the intended target version.
| @Builder(builderMethodName = "consumerBuilder") | ||
| public ConsumerConfiguration(String namesrvAddr, String groupId, boolean aclEnable, String accessKey, | ||
| String secretKey, | ||
| Integer batchSize, Long pollTimeoutMillis) { |
There was a problem hiding this comment.
ConsumerConfiguration and ProducerConfiguration use Lombok @builder with inheritance. The parent class RocketMqBaseConfiguration also has @builder, generating a package-private all-args constructor. This works because all classes share the same package, but it is fragile — if any subclass moves to a different package in the future, super() calls will fail at compile time. Consider adding an explicit protected constructor in the base class.
RockteMQ-AI
left a comment
There was a problem hiding this comment.
Summary
Re-review of PR #437 after new commits. This is a significant upgrade PR that:
- Upgrades RocketMQ version from 4.x to 5.1.0 across all connectors
- Adds compatibility layer for both 4.9.4 and 5.x versions
- Updates imports from
org.apache.rocketmq.common.*toorg.apache.rocketmq.remoting.protocol.* - Adds compaction topic support in
BrokerBasedLog
Review notes:
- The version upgrade is necessary for staying current with RocketMQ releases
- The compatibility layer (
examineTopicStatswrapper) is a good approach for supporting both versions - Import changes are mechanical and consistent across modules
Concerns:
- This is a large PR (94 files) — consider splitting into smaller, focused PRs for easier review
- No test coverage visible for the new compatibility layer
- The
catch (Exception e)inoffsets()method is too broad — consider catching specific exceptions
Suggestions
- Add unit tests for the
examineTopicStats()compatibility wrapper - Consider splitting the version upgrade into separate PRs per connector module
- Narrow the exception handling in
RocketMqAdminUtil.offsets()
Automated review by github-manager-bot
1.Upgrade the rocketmq client version to 5.1.0
2.BrokerBasedLog supports initialization of compaction topic
3. Extend rocketmq-connect-common module