Duansg commented on PR #3860: URL: https://github.com/apache/hertzbeat/pull/3860#issuecomment-3550511820
> 1. I support changing `rpop` to `brpop` because it prevents CPU spin, but when `brpop` returns `null` after hitting a timeout due to its blocking nature, does the external fallback algorithm need to continue blocking for an even longer time? Can we just directly enter the next round of `brpop` or set a longer blocking time for `brpop`? > 2. My understanding is that the fallback strategy is intended for when `brpop` encounters an exception (e.g., a network connection failure). In such cases, we can attempt to reconnect. If the reconnection fails, we block and attempt to reconnect again, and only after reaching the retry limit do we terminate the consumer thread. I have indeed considered this aspect. Currently, for processing logic like `Kafka`/`Redis`, both normal unresponsive data and exceptions return `Null`. Initially, I thought unified handling would suffice, but this does indeed delay entry into the next iteration when the queue is empty. I believe we should now distinguish between unknown exceptions and normal empty queues, implementing backoff strategies only when unknown exceptions occur. -- 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]
