-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[Refactor] optimize code structure about collector and job within Manager #3675
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the code structure of the Manager module, specifically focusing on collector operations and job scheduling. The primary goal is to improve code organization and create a clearer separation of responsibilities within the CollectorJobScheduler component.
- Split interfaces to separate collector operations from job operations
- Introduced
CollectorKeeperabstraction for collector selection strategies - Moved properties classes to a dedicated
propertiespackage - Consolidated duplicate methods and simplified the API surface
Reviewed Changes
Copilot reviewed 25 out of 25 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| CollectorJobScheduler.java | Refactored to implement split interfaces and use CollectorKeeper abstraction |
| JobOperation.java | New simplified interface replacing CollectJobScheduling |
| CollectorOperation.java | New interface for direct collector operations |
| CollectorOperationReceiver.java | New interface for receiving collector operations from remote collectors |
| ConsistentHashCollectorKeeper.java | Renamed and refactored from ConsistentHash, implements CollectorKeeper |
| CollectorKeeper.java | New interface abstraction for collector selection strategies |
| CollectorNode.java | Extracted from inner class to standalone POJO |
| JobCache.java | New utility class for job caching |
| properties/*.java | Moved property classes to dedicated package |
Comments suppressed due to low confidence (3)
hertzbeat-manager/src/main/java/org/apache/hertzbeat/manager/scheduler/ConsistentHashCollectorKeeper.java:302
- Potential null pointer exception: The addJob method can return null when no collector is found, but the code immediately uses collectorNode.getIdentity() without null checking.
Map.Entry<Integer, CollectorNode> ceilEntry = hashCircle.ceilingOrFirstEntry(dispatchHash);
hertzbeat-manager/src/main/java/org/apache/hertzbeat/manager/nativex/HertzbeatRuntimeHintsRegistrar.java:29
- Unused import: org.springframework.aot.hint.ExecutableMode is imported but not used after the registerConstructor method was removed.
import org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar;
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
hertzbeat-manager/src/main/java/org/apache/hertzbeat/manager/pojo/JobCache.java
Show resolved
Hide resolved
…ojo/JobCache.java Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Calvin <zhengqiwei@apache.org>
|
hi, this need more time or others to review and test , maybe in this weekend. |
Sure, looking forward to your suggestions |
What's changed?
After code iterations in these years, module
Managercontain more and more functions. Yet there isn't a clear code structure, such asorg.apache.hertzbeat.manager.scheduler.CollectorJobSchedulerholds all operations about Collector status notifications, selecting collector, dispatching jobs and so on.I think it is time to get refactored.
ConfigConstants.PkgConstant.PKGinstead of hardcode inManager.javapropertiesin moduleManager, used for those files that read yml properties onlyorg.apache.hertzbeat.manager.scheduler.CollectorJobScheduler#collectSyncJobDataandorg.apache.hertzbeat.manager.scheduler.CollectorJobScheduler#updateAsyncCollectJoborg.apache.hertzbeat.manager.scheduler.CollectJobScheduling->org.apache.hertzbeat.manager.scheduler.JobOperationorg.apache.hertzbeat.manager.scheduler.CollectorScheduling->org.apache.hertzbeat.manager.scheduler.CollectorOperationandorg.apache.hertzbeat.manager.scheduler.CollectorOperationReceiverCollectorKeeperto take responsibility of collector selections onlyAfter refactoring above, current code design of Manager will be like:


So far, we keep

org.apache.hertzbeat.manager.scheduler.CollectorJobScheduleras the only one implementation class in order to avoid overturning.What are the benefits?
org.apache.hertzbeat.manager.scheduler.CollectorScheduling-> Ensure the code hierarchy clearer to facilitate further code splitting.CollectorKeeper-> This is for collector selections only, which means we can support more select strategy by implementing this interface, such asRound Robinand so on.Checklist
Add or update API