Praveenkumar76 commented on issue #25660: URL: https://github.com/apache/pulsar/issues/25660#issuecomment-4646412483
> Summary: This issue is just a tip of the iceberg of improving testability and code quality in the Pulsar code base. We can first focus on the `java.time.Clock` research part. Would you like to perform that? You could also store the research results in https://gist.github.com/ as markdown with possible mermaid diagrams and reference that in a comment on this issue. (Gists can only hold text files. When updating the files in a gist, it's possible to checkout the gist as a git repository locally and push updates as git commits. ) Hi @lhotari ! I spent time digging into the codebase to perform the java.time.Clock research. I have documented the full findings and architectural proposal here: [gist link](https://gist.github.com/Praveenkumar76/bafd70c30710cf26951e8022f12929b8) The research highlighted exactly what you suspected: There are over 180 instances of Thread.sleep() in the broker test suite. Tests like PersistentMessageExpiryMonitorTest are currently forced to halt CI execution completely (e.g., sleeping for 2 real seconds) just to verify a 1-second TTL rule. Standardizing the clock will completely eliminate these blocking sleeps. Based on the Concurrency guidelines and your feedback regarding the boundaries of "units," I also updated my draft PR #25935. I reverted the changes to the deeply coupled classes (like Consumer) to avoid massive dependency chains. Instead, I scoped the PR strictly to 3 classes (MessageDeduplication, SchemaRegistryStats, PulsarStats) where the Clock can be cleanly provided via constructor injection, adhering to safe publication and strict unit isolation. Let me know if this research aligns with your vision, and if those 3 refactored files represent the correct architectural pattern for moving forward! -- 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]
