Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
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) {
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.

// 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
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));
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?

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
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
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
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
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
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
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
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 Send Messages
##### 2.1 Use Producer to Send Synchronous Messages
Expand Down
2 changes: 1 addition & 1 deletion docs/en/Operations_Trace.md
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
File renamed without changes.
2 changes: 1 addition & 1 deletion docs/en/design.md
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