-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
KEDA scaledjob with accurate strategy doesn't consider messages in flight when calculating Scale. #1323
Comments
@TsuyoshiUshio PTAL |
As we discussed on the closed PR, |
Thanks @TsuyoshiUshio , I am already using a longer polling Interval and exiting the job if queue is empty as a non-blocker. For our use-case, we want the scaling to be very responsive and not have any delay in the system due to the polling Interval. Will wait for your Update. |
Thank you for your feedback. I'm grad people using scaled job for many use cases! |
Signed-off-by: Thomas Lamure <[email protected]>
Signed-off-by: Thomas Lamure <[email protected]>
Signed-off-by: Thomas Lamure <[email protected]>
Signed-off-by: Thomas Lamure <[email protected]>
A clear and concise description of what the bug is.
When the strategy specified is accurate, It is expected that the Scaler's SDK can return queuelength not including messages that are being processed for queues like AWS-SQS etc. So that the scale depends solely on the queuelength. But in cases when there's a resource crunch in the cluster, the spawned pods might not get placed onto the nodes until the next polling iteration, which means they don't consume the messages from the queue either. During the next poll the scaler again spawns the new pods equal to the queuelength.
Expected Behavior
Eg:
Trigger : SQS
Available Messages : 100
Messages locked : 50
Pods Running : 50
Poll Duration : 60 seconds
Target Average Value = 1
At polling Iteration T1, 100 new pods are spawned. None of the pods were successfully scheduled. no messages were consumed.
At polling Iteration T2, 100 messages are still available in the queue. but no new pods are created as TotalPodsCurrentlyActive = messagesAvailable + messagesLocked.
Actual Behavior
At polling Iteration T2, 100 messages are still available in the queue. So 100 new pods are created again assuming the messages were received after the last polling Iteration.
Specifications
The text was updated successfully, but these errors were encountered: