mirror of
https://github.com/hibiken/asynq.git
synced 2026-04-25 23:15:51 +03:00
[GH-ISSUE #856] [FEATURE REQUEST] Support dynamic queue #1434
Labels
No labels
CLI
bug
designing
documentation
duplicate
enhancement
good first issue
good first issue
help wanted
idea
invalid
investigate
needs-more-info
performance
pr-welcome
pull-request
question
wontfix
work in progress
work in progress
work-around-available
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/asynq#1434
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @yangzhiw on GitHub (Apr 8, 2024).
Original GitHub issue: https://github.com/hibiken/asynq/issues/856
Originally assigned to: @hibiken on GitHub.
Is your feature request related to a problem? Please describe.
My usage scenario is that I want to put different businesses into different queues. Businesses change dynamically. When the program is running, it supports putting different data into different queues, and different queues support different threads. consumption.
@kamikazechaser commented on GitHub (Apr 8, 2024):
Related to #850, #852
@yangzhiw commented on GitHub (Apr 9, 2024):
Thank you. Another inquiry: Different queues use different coroutines to consume, and queue-level concurrency is supported; because looking at the source code now, it seems that there is only one processor to pull data.
@kamikazechaser commented on GitHub (Apr 9, 2024):
That is also being addressed in #849
@gsaraf commented on GitHub (Jan 16, 2025):
Hi! I'm looking at a similar requirement, and would be interested in extending this feature to make the queue update more "on-the-fly". So instead of shutting down the server and bringing it back up with the new configuraiton, we would update the required configurations where needed.
I don't think it is blocking the current implementation in #879. Would there be interest in an improvement on top?