f1amingo opened a new issue, #10387:
URL: https://github.com/apache/rocketmq/issues/10387
## Description
The `ClientEventSet` inner class in `LiteEventDispatcher` currently uses a
**fixed-capacity** `LinkedBlockingQueue` whose capacity is determined at
construction time:
```java
events = new
LinkedBlockingQueue<>(LiteMetadataUtil.getMaxClientEventCount(group,
brokerController));
```
This means the `maxClientEventCount` configuration **cannot be changed at
runtime** — a broker restart is required for any adjustment to take effect.
Additionally, `isLowWaterMark()` relies on `remainingCapacity()`:
```java
return (double) used / (used + events.remainingCapacity()) < LOW_WATER_MARK;
```
Since the queue capacity is fixed, `remainingCapacity()` reflects the static
bound rather than the intended dynamic limit, which can lead to incorrect
watermark calculations.
## Proposed Change
Replace the fixed-capacity queue with a logically **unbounded**
`LinkedBlockingQueue` and enforce the capacity limit dynamically via a
**soft-cap** check in `offer()`:
```java
events = new LinkedBlockingQueue<>(Integer.MAX_VALUE);
```
```java
public boolean offer(String event) {
if (events.size() >= getMaxCapacity()) {
return false;
}
// ...
}
```
Update `isLowWaterMark()` to use the dynamically resolved `maxCapacity`
directly:
```java
public boolean isLowWaterMark() {
int used = events.size();
int maxCapacity = getMaxCapacity();
return maxCapacity <= 0 || (double) used / maxCapacity < LOW_WATER_MARK;
}
```
## Benefits
- **Runtime config hot-reload**: `maxClientEventCount` can be adjusted
without broker restart
- **Correct watermark calculation**: Uses the current dynamic limit instead
of the static queue capacity
- **Backward compatible**: The soft-cap behavior is functionally equivalent
to the previous fixed-cap approach
## Affected Module
- `broker` — `LiteEventDispatcher.ClientEventSet`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
