harshita2626 commented on issue #3173: URL: https://github.com/apache/hertzbeat/issues/3173#issuecomment-2758444059
okay !good to know that.Thank you for sharing your insightful analysis > Hi [@harshita2626](https://github.com/harshita2626), > > Thank you for your reply. In my opinion, the root cause of this bug is that the method is not cohesive enough and the responsibility is not single enough. > > Consider the following code. `remove(timeout)` is called before `timeout.expire()`, which loses the atomicity of the task state judgment in `timeout.expire()`. In addition, `expireTimeouts(long)` includes handling of the cancel action, but the right thing to do is concentrate the cancel handling in `processCancelledTasks()`. > > ``` > void expireTimeouts(long deadline) { > HashedWheelTimeout timeout = head; > while (timeout != null) { > HashedWheelTimeout next = timeout.next; > if (timeout.remainingRounds <= 0) { > // The remove operation is performed and the `pendingTimeouts` is decreased before the task state is checked. > next = remove(timeout); > if (timeout.deadline <= deadline) { > timeout.expire(); > } else { > throw new IllegalStateException(String.format( > "timeout.deadline (%d) > deadline (%d)", timeout.deadline, deadline)); > } > } else if (timeout.isCancelled()) { > // The handling of cancel action is scattered in `processCancelledTasks()` and here. > next = remove(timeout); > } else { > timeout.remainingRounds--; > } > timeout = next; > } > } > ``` > > For this, I have fixed and created a pr [#3174](https://github.com/apache/hertzbeat/pull/3174) . -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
