Skip to content

[ISSUE #8262] [Enhancement] Add tests and harden UtilAll.isItTimeToDo #10409

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ChaoXoX wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

[ISSUE #8262] [Enhancement] Add tests and harden UtilAll.isItTimeToDo #10409

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1333802
[ISSUE #8262] Harden UtilAll.isItTimeToDo and add tests
ChaoXoX May 30, 2026
7341436
Fix outdated versions, typos, and misspelled filenames in docs
ChaoXoX Jun 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 19 additions & 3 deletions common/src/main/java/org/apache/rocketmq/common/UtilAll.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,13 +117,29 @@ public static long computeElapsedTimeMilliseconds(final long beginTime) {
}

public static boolean isItTimeToDo(final String when) {
if (StringUtils.isBlank(when)) {
return false;
}

String[] whiles = when.split(";");
if (whiles.length > 0) {
Calendar now = Calendar.getInstance();
int nowHour = now.get(Calendar.HOUR_OF_DAY);
for (String w : whiles) {
int nowHour = Integer.parseInt(w);
if (nowHour == now.get(Calendar.HOUR_OF_DAY)) {
return true;
if (StringUtils.isBlank(w)) {
continue;
}
String trimmed = w.trim();
try {
int hour = Integer.parseInt(trimmed);
if (hour < 0 || hour > 23) {
continue;
}
if (hour == nowHour) {
return true;
}
} catch (NumberFormatException ignored) {

@RongtongJin RongtongJin May 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we avoid silently ignoring invalid when tokens here, or at least log a warning when a token cannot be parsed or is outside the 0-23 range? This helper is used by scheduled maintenance paths such as commitlog cleanup and topic queue mapping cleanup. If deleteWhen or a similar schedule is misconfigured, returning false forever would silently disable the task and make the operator miss the configuration problem. The previous behavior failed loudly; changing that to silent ignore seems risky without some visibility.

@RongtongJin RongtongJin Jun 18, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still consider this blocking. Silently accepting an invalid schedule can hide a bad deleteWhen-style configuration and leave scheduled maintenance disabled without any clear signal. Please keep configuration mistakes observable, either by preserving fail-fast behavior or by logging/validating invalid tokens explicitly.

// Ignore invalid hour tokens to avoid breaking scheduled tasks.
}
}
}
Expand Down
16 changes: 16 additions & 0 deletions common/src/test/java/org/apache/rocketmq/common/UtilAllTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@
import java.net.UnknownHostException;
import java.nio.ByteBuffer;
import java.util.Arrays;
import java.util.Calendar;
import java.util.Collections;
import java.util.List;
import java.util.Properties;
Expand All @@ -34,6 +35,7 @@
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.within;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;

public class UtilAllTest {
Expand Down Expand Up @@ -151,6 +153,20 @@ public void testSplit() {
assertEquals(Collections.EMPTY_LIST, UtilAll.split("", comma));
}

@Test
public void testIsItTimeToDo() {
int currentHour = Calendar.getInstance().get(Calendar.HOUR_OF_DAY);
assertTrue(UtilAll.isItTimeToDo(String.valueOf(currentHour)));
assertTrue(UtilAll.isItTimeToDo("foo; " + currentHour + " ; 25"));
assertTrue(UtilAll.isItTimeToDo(" " + currentHour + " "));

assertFalse(UtilAll.isItTimeToDo(null));

@RongtongJin RongtongJin May 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test depends on the hour read here matching the hour read inside UtilAll.isItTimeToDo. It can theoretically become flaky if the test crosses an hour boundary between the two calls. Could we make the positive case independent of wall-clock timing, for example by passing all valid hours (0;1;...;23) and asserting it returns true, while keeping the invalid-token cases separate?

@RongtongJin RongtongJin Jun 18, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still worth fixing before merge. This can be made deterministic by passing all valid hours (0;1;...;23) for the positive case, and by adding a valid-but-non-current hour negative case.

assertFalse(UtilAll.isItTimeToDo(""));
assertFalse(UtilAll.isItTimeToDo(" ; "));
assertFalse(UtilAll.isItTimeToDo("not_a_number"));
assertFalse(UtilAll.isItTimeToDo("99"));
}

static class DemoConfig {
private int demoWidth = 0;
private int demoLength = 0;
Expand Down
4 changes: 2 additions & 2 deletions docs/cn/Configuration_TLS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -83,13 +83,13 @@ tls.client.trustCertPath=/opt/certFiles/ca.pem

### 3.1 编辑runserver.sh，在JAVA_OPT中增加以下内容：
```shell
JAVA_OPT="${JAVA_OPT} -Dtls.server.mode=enforcing -Dtls.config.file=/opt/rocketmq-4.9.3/conf/tls.properties"
JAVA_OPT="${JAVA_OPT} -Dtls.server.mode=enforcing -Dtls.config.file=/opt/rocketmq-5.5.0/conf/tls.properties"
```

### 3.2 编辑runbroker.sh，在JAVA_OPT中增加以下内容：

```shell
JAVA_OPT="${JAVA_OPT} -Dorg.apache.rocketmq.remoting.ssl.mode=enforcing -Dtls.config.file=/opt/rocketmq-4.9.3/conf/tls.properties -Dtls.enable=true"
JAVA_OPT="${JAVA_OPT} -Dorg.apache.rocketmq.remoting.ssl.mode=enforcing -Dtls.config.file=/opt/rocketmq-5.5.0/conf/tls.properties -Dtls.enable=true"
```

# 4 客户端连接
Expand Down
4 changes: 2 additions & 2 deletions docs/cn/Example_Simple_cn.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,12 +9,12 @@ maven:
<dependency>
<groupId>org.apache.rocketmq</groupId>
<artifactId>rocketmq-client</artifactId>
<version>4.3.0</version>
<version>5.5.0</version>
</dependency>
```
gradle:
``` java
compile 'org.apache.rocketmq:rocketmq-client:4.3.0'
compile 'org.apache.rocketmq:rocketmq-client:5.5.0'
```
### 2 发送消息
##### 2.1 使用Producer发送同步消息
Expand Down
4 changes: 2 additions & 2 deletions docs/cn/RocketMQ_Example.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,12 +54,12 @@
<dependency>
<groupId>org.apache.rocketmq</groupId>
<artifactId>rocketmq-client</artifactId>
<version>4.9.1</version>
<version>5.5.0</version>
</dependency>
```
`gradle`
```
compile 'org.apache.rocketmq:rocketmq-client:4.3.0'
compile 'org.apache.rocketmq:rocketmq-client:5.5.0'
```
### 1.2 消息发送

Expand Down
4 changes: 2 additions & 2 deletions docs/en/Configuration_TLS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -78,14 +78,14 @@ The value of "tls.config.file" needs to be replaced by the file path created in
### 3.1 Edit runserver.sh
Add following content in JAVA_OPT:
```shell
JAVA_OPT="${JAVA_OPT} -Dtls.server.mode=enforcing -Dtls.config.file=/opt/rocketmq-4.9.3/conf/tls.properties"
JAVA_OPT="${JAVA_OPT} -Dtls.server.mode=enforcing -Dtls.config.file=/opt/rocketmq-5.5.0/conf/tls.properties"
```

### 3.2 Edit runbroker.sh
Add following content in JAVA_OPT:

```shell
JAVA_OPT="${JAVA_OPT} -Dorg.apache.rocketmq.remoting.ssl.mode=enforcing -Dtls.config.file=/opt/rocketmq-4.9.3/conf/tls.properties -Dtls.enable=true"
JAVA_OPT="${JAVA_OPT} -Dorg.apache.rocketmq.remoting.ssl.mode=enforcing -Dtls.config.file=/opt/rocketmq-5.5.0/conf/tls.properties -Dtls.enable=true"
```

# 4 Client connection
Expand Down
2 changes: 1 addition & 1 deletion docs/en/Design_LoadBlancing.md → docs/en/Design_LoadBalancing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
Load balancing in RocketMQ is accomplished on Client side. Specifically, it can be divided into load balancing at Producer side when sending messages and load balancing at Consumer side when subscribing messages.

### Producer Load Balancing
When the Producer sends a message, it will first find the specified TopicPublishInfo according to Topic. After getting the routing information of TopicPublishInfo, the RocketMQ client will select a queue (MessageQueue) from the messageQueue List in TopicPublishInfo to send the message by default.Specific fault-tolerant strategies are defined in the MQFaultStrategy class.
When the Producer sends a message, it will first find the specified TopicPublishInfo according to Topic. After getting the routing information of TopicPublishInfo, the RocketMQ client will select a queue (MessageQueue) from the messageQueue List in TopicPublishInfo to send the message by default. Specific fault-tolerant strategies are defined in the MQFaultStrategy class.
Here is a sendLatencyFaultEnable switch variable, which, if turned on, filters out the Broker agents that are not available on the basis of randomly gradually increasing modular arithmetic selection. The so-called "latencyFault Tolerance" refers to a certain period of time to avoid previous failures. For example, if the latency of the last request exceeds 550 Lms, it will evade 30000 Lms; if it exceeds 1000L, it will evade 60000L; if it is closed, it will choose a queue (MessageQueue) to send messages by randomly gradually increasing modular arithmetic, and the latencyFault Tolerance mechanism is the key to achieve high availability of message sending.

### Consumer Load Balancing
Expand Down
2 changes: 1 addition & 1 deletion docs/en/Design_Trancation.md → docs/en/Design_Transaction.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Transaction Message
## 1 Transaction Message
Apache RocketMQ supports distributed transaction message from version 4.3.0. RocketMQ implements transaction message by using the protocol of 2PC(two-phase commit), in addition adding a compensation logic to handle timeout-case or failure-case of commit-phase, as shown below.
Apache RocketMQ supports distributed transaction message from version 4.3.0. RocketMQ implements transaction message by using the protocol of 2PC(two-phase commit), in addition to adding a compensation logic to handle timeout-case or failure-case of commit-phase, as shown below.

![](../cn/image/rocketmq_design_10.png)

Expand Down
4 changes: 2 additions & 2 deletions docs/en/Example_Simple.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,12 +9,12 @@ maven:
<dependency>
<groupId>org.apache.rocketmq</groupId>
<artifactId>rocketmq-client</artifactId>
<version>4.3.0</version>
<version>5.5.0</version>

@RongtongJin RongtongJin Jun 18, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These documentation cleanups are unrelated to the UtilAll.isItTimeToDo behavior change and overlap with docs-only PR scope. Please split or drop the doc changes from this PR so the behavioral change can be reviewed independently.

</dependency>
```
gradle:
``` java
compile 'org.apache.rocketmq:rocketmq-client:4.3.0'
compile 'org.apache.rocketmq:rocketmq-client:5.5.0'
```
### 2 Send Messages
##### 2.1 Use Producer to Send Synchronous Messages
Expand Down
2 changes: 1 addition & 1 deletion docs/en/Operations_Trace.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@

## 2 Support for Message Trace Cluster Deployment

### 2.1 Broker Configuration Fille
### 2.1 Broker Configuration File

The properties profile content of the Broker side enabled message trace feature is pasted here:

Expand Down
0 docs/en/Troubleshoopting.md → docs/en/Troubleshooting.md
View file
Open in desktop
File renamed without changes.
2 changes: 1 addition & 1 deletion docs/en/design.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@


### 5 Transactional Message
Apache RocketMQ supports distributed transactional message from version 4.3.0. RocketMQ implements transactional message by using the protocol of 2PC(two-phase commit), in addition adding a compensation logic to handle timeout-case or failure-case of commit-phase, as shown below.
Apache RocketMQ supports distributed transactional message from version 4.3.0. RocketMQ implements transactional message by using the protocol of 2PC(two-phase commit), in addition to adding a compensation logic to handle timeout-case or failure-case of commit-phase, as shown below.

![](../cn/image/rocketmq_design_10.png)

Expand Down
Loading