-
Notifications
You must be signed in to change notification settings - Fork 9
MLH-1239 Tags propagate isolate #5379
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
| } else { | ||
| LOG.info("TasksFetcher: No task to queue"); | ||
| if (submittedCount > 0) { | ||
| LOG.info("TasksFetcher: Submitted {} tasks to the queue", submittedCount); |
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.
Bug: Task Submission and Latch Decrement Mismatch
The CountDownLatch is initialized with the total task count, but submitAll skips null tasks or exits early without decrementing it. This prevents the latch from reaching zero, causing waitForTasksToComplete to hang. Also, the new task submission retry loop lacks a maximum retry limit, risking an infinite loop if memory stays high.
| Response.ResponseBuilder builder; | ||
|
|
||
| // Return 503 if processing tasks or high memory | ||
| if (isProcessingTasks || memoryUsage > 0.75) { |
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.
Bug: Inconsistent Memory Thresholds Across Components
The new /admin/ready endpoint's memory threshold for readiness is hardcoded to 0.75. This creates an inconsistency with the configurable AtlasConfiguration.TASK_MEMORY_THRESHOLD_PERCENT used by other components like TaskQueueWatcher, potentially causing different behavior between the readiness check and task processing.
| submitAll(tasks, latch); | ||
| LOG.info("Submitted {} tasks to the queue", tasks.size()); | ||
| waitForTasksToComplete(latch); | ||
| isProcessingTasks.set(true); |
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.
This logic just responsible for submittiing tasks to the queue.
IMO it should never tell whether isProcessingTasks, best please for this flag would be the TaskExecutor.run() method.
Also, generally we do check RequestContext.get().getCurrentTask(); to conclude whether any task is in progress or not, may be same can be used instead the flag but this way also fine
Change description
Type of change
Related issues
https://atlanhq.atlassian.net/browse/MLH-1239
Helm Config Changes for Running Tests (Staging PR)
Does this PR require Helm config changes for testing?
enpla9up36. (You can proceed with the PR.) ✅Checklists
Development
Security
Code review