-
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
Support message sessions in Azure Service Bus Scaler #1479
Comments
That's a good scenario to cover. Are you using a specific scaler or more in general? With Azure Service Bus you'd use sessions indeed, I'm just wondering how KEDA could know when to scale and when not? |
I'm using the |
Reasonable ask. So if there would be a |
Yeah that would be great. In this particular case I wouldn't be interested in scaling based on the number of messages at all, only the number of sessions. Because of how the .net client manages concurrency I cannot imagine ever needing to scale based on both queue length and session count at the same time. I think its as simple as - if its a session enabled queue i want to scale based on sessions, otherwise queue count. |
Makes sense, thanks for bringing this up! |
Hi everyone, just to chime in, we also have a similar use case for sessions. Some context on how we use them: We utilize the sessions to break up workloads per tenant and help facilitate "fast lanes". It's set up in such a way that some tenants could have more sessions than others, etc. If KEDA could scale based on sessions, it would definitely simplify and make more reliable our scaling strategy. |
Somewhat connected to this issue.... When downscaling, are receiver instances that are locked taken into account? E.g. are these instances kept alive until the session has completed and the lock has been removed? |
No because KEDA is not aware of what instances are doing. It just tells Kubernetes to scale from x to y, and the scheduler will kill the required amount of pods. |
That would be really nice to have, since long running sessions could theoretically span days / months ... Any way you could work around this? |
The only way to achieve this is to change the application that's running so that when a shutdown is initiated it gracefully abandons the session for somebody else to continue later on. |
Thanks. That is the strategy I am following atm indeed. Was hoping I could remove some code :) |
WDYT @ahmelsayed? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
We have a similar use case. It would be great to have a working solution on this. |
Are you willing to contribute this? |
Oh no need to @raorugan |
@tomkerkhove Will this be implemented soon ? |
It's looking for a contributor so if you are interested, let me know. |
We are also interested in this capability. I am not sure we have the skills/bandwidth to contribute unfortunately. |
We also have an interest in this capability. |
We're also interested in this feature. |
@tomkerkhove Is this feature even possible to implement currently? I think that the Service Bus SDK for go doesn't provide option to get count of active sessions. There's option in C# and Java SDK (GetMessageSessions on SB client) but I don't see this in GO. |
We have not looked in to it yet given nobody has proposed to implement it yet. If this is a known limitation, then it would be nice if you could file an issue with them! |
@tomkerkhove I can take a look at the change and see if I can move it forward |
@petemessina / @tomkerkhove - I would be interested in helping as well |
That would be wonderful! @petemessina / @aionic who wants to pick this up? |
I can pick it up |
Any movement on this feature? |
Following here, we use sessions to guarantee FIFO so queue based scaling as is is indeed not useful, would love to have this! |
@tomkerkhove - I found a ticket from last year where .NET SDK team discussed on Service Bus sessions. It seems that this feature needs to have not only SDK for GO support but also the Service Bus API: Azure/azure-sdk-for-net#20569 (comment) For scaling scenarios this feature on service bus API is kind of crucial. Do you think you could influence Service Bus team to bring this on their roadmap and provide such data? |
Hello, For those who are still waiting for the native support and want to try something different - I have started an open-source project with external scaler that leverages AMQP command to get count of sessions: https://github.com/miqm/session-scaler. Feel free to try it out. I will gradually try to improve it i.e. add workload identity support. All feedback (even the negative, as long as is constructive ) is appreciated! |
Use-Case
I have a large workload that is bound to a single session id. As a session can only be processed from a single listener (because it locks the session) scaling according to the number of messages in the queue is not... useful.
I've just added 620 messages to a queue all with the same session id and keda has scaled up the service to whopping 16 instances. But unfortunately 15 instances are doing nothing and 1 is working hard.
I'm not sure if you can interrogate the number of active sessions but if you can then...
Specification
The text was updated successfully, but these errors were encountered: