Scheduler pattern #76 #3135
Closed
Scheduler pattern #76 #3135
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
issue This PR Solves In microservices, logs are often collected using busy waiting loops, where the system constantly checks for new logs. This leads to several issues: Wasting Resources: The system keeps checking for new logs, using up CPU resources even when there are no logs to process. Increased Latency: Logs are delayed because the system is busy checking for new data rather than processing logs as they arrive. This PR solves these problems by switching to a more efficient event-driven log aggregation system. Instead of constantly checking for new logs, the system reacts only when new logs are available, reducing unnecessary CPU usage and improving scalability and performance.
The Scheduler design pattern provides a clean and structured solution to manage and execute tasks automatically. It involves: Scheduler: A component responsible for managing the execution of tasks, ensuring they run at the correct time or under the right conditions. Task: A unit of work that encapsulates the logic to be executed. Trigger/Condition: Defines when and how often a task should execute, whether it's based on time intervals (e.g., every minute) or events Execution Context: Ensures that tasks are executed in the right environment, managing resources, states, and concurrency. By using this pattern, tasks are managed centrally, execution timing is automated, and the system can handle various triggers and execution conditions efficiently, allowing developers to focus on defining what needs to be done instead of when and how to execute it.
Create schedule pattern
|
| jobs.add(job); | ||
| triggers.add(trigger); | ||
| } | ||
| public void start() { |
There was a problem hiding this comment.
actually we use spring boot and the framework itself provides centralized system and the dev just needs to use specific stereotype annotations to schedule job with configs
Repository owner
closed this by deleting the head repository
Jan 5, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In many applications, it is necessary to manage and execute tasks (or jobs) at specific intervals or under certain conditions. Examples include running periodic background tasks, sending scheduled notifications, or automating repetitive processes. However, managing these tasks manually can lead to several challenges:
Lack of Modularity: Without a well-structured design, the logic for task execution may become entangled with application logic, reducing code readability and maintainability.
Hardcoding of Triggers: Defining triggers inline or directly in the task logic makes it hard to reuse or update the triggers without modifying the entire task.
No Centralized Management: The absence of a centralized scheduler results in scattered execution logic, making debugging and scalability difficult.
Inflexibility: Hardcoded schedules or conditions prevent the easy addition or modification of tasks and triggers.
The goal was to design a scheduling pattern that decouples jobs from their execution triggers, promotes reusability, and centralizes the scheduling logic.