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
a consistent hash exchange with 20 queues bound to it
the same 20 queues bound to a dedicated retry exchange that uses the delayed message exchange
Would there be support behind adding an alternate handler config that allows binding to multiple queues and exchanges so that I can avoid duplicate handlers? This would also reduce the risk of forgetting to add a new handler for each additional queue added to a consistent hash exchange.
Support multiple configurations on the same handler to support use cases where users want to reuse
the same handler method across multiple queues. For example, this could be useful for a situation
where messages are partitioned across multiple queues by a consistent hash exchange.
fixgolevelup#624
Support multiple configurations on the same handler to support use cases where users want to reuse
the same handler method across multiple queues. For example, this could be useful for a situation
where messages are partitioned across multiple queues by a consistent hash exchange.
fixgolevelup#624
Support multiple configurations on the same handler to support use cases where users want to reuse
the same handler method across multiple queues. For example, this could be useful for a situation
where messages are partitioned across multiple queues by a consistent hash exchange.
fix#624
I have a unique use case where I'd like to have:
Would there be support behind adding an alternate handler config that allows binding to multiple queues and exchanges so that I can avoid duplicate handlers? This would also reduce the risk of forgetting to add a new handler for each additional queue added to a consistent hash exchange.
Something like this:
The text was updated successfully, but these errors were encountered: