You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My proposal is to add the support to specify a specific timeout to use for each trigger when you are using RabbitMQ Scaler.
It could be something like this:
triggers:
- type: rabbitmqmetadata:
host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication....httpTimeout: 10000
In cases where it's not defined, KEDA_HTTP_DEFAULT_TIMEOUT should be used
Use-Case
When you are using http protocol with regex, it could need more time than KEDA_HTTP_DEFAULT_TIMEOUT to get the response. It's possible to customize the timeout but only as a global customization. This could be enough in some cases but if you are using KEDA in several not related workloads, this could be a problem.
In our use case, our production RabbitMQ cluster has more than 1k queues, and it needs 5-10 in some cases to response with the queues which match the regex. If we want to use other scale, we would like to avoid having 15-30sec (arbitrary value) in other scalers which uses HTTP protocol
Anything else?
I can do it :)
The text was updated successfully, but these errors were encountered:
I don't know if AMQ client supports it, if it supports, the key can be timeout directly instead httpTimeout
I will take a look during the task if you agree :)
I have taken a look at this and in theory it's possible to set the timeout in amqp connection, but probably it's unnecessary because the default timeout using amqp is 30 seconds instead KEDA_HTTP_DEFAULT_TIMEOUT (3s as default).
It could be totally enough for amqp purposes.
I'm not sure if this option is useful in amqp scenarios 😪
WDYT?
Proposal
My proposal is to add the support to specify a specific timeout to use for each trigger when you are using RabbitMQ Scaler.
It could be something like this:
In cases where it's not defined,
KEDA_HTTP_DEFAULT_TIMEOUT
should be usedUse-Case
When you are using http protocol with regex, it could need more time than
KEDA_HTTP_DEFAULT_TIMEOUT
to get the response. It's possible to customize the timeout but only as a global customization. This could be enough in some cases but if you are using KEDA in several not related workloads, this could be a problem.In our use case, our production RabbitMQ cluster has more than 1k queues, and it needs 5-10 in some cases to response with the queues which match the regex. If we want to use other scale, we would like to avoid having 15-30sec (arbitrary value) in other scalers which uses HTTP protocol
Anything else?
I can do it :)
The text was updated successfully, but these errors were encountered: