I would like to federate queues, but I want the upstream queues to have different names than the federated queues. I know it is possible to configure this in the federation-upstream with the 'queue' property.
But... I want the federation-upstream to be used in a policy that applies to multiple queues (so multiple different queues will be federated). In this case, what happens if I set the 'queue' property on the federation-upstream?
What I'd really like to do is federate a queue and have the upstream be the same name with something appended at the end. For example, federate "myqueue" and have the upstream queue be called "myqueue.upstream". Is this possible without having to define a different federation-upstream and policy for every single federated queue?
While I could configure the upstreams using HTTP API, I don't think this would be very desirable. It might be good in a scenario where things are very well-defined and you only have a few federated queues, but this is not my case.
For each queue I would have to:
* define a new upstream with desired upstream queue name
* repeat above for each upstream broker
* define an upstream set containing the queue-specific upstreams I just created
* define a new policy applying the upstream set to the specific federated queue
So... on a broker that has 5 upstream brokers, each federated queue would require 5 new upstreams, 1 new upstream set, and 1 new policy. I might have hundreds of federated queues, so this could get rather unwieldy.
To complicate matters, if I ever wanted to add another upstream broker (and I might!), I would then need to detect all of the federated queues somehow, loop through them all creating new queue-specific upstreams, and modify all the upstream sets to add the new upstreams.
On the other hand, if an upstream had a property for applying a regular expression substitution pattern, that would be awesome. Then I could just define the upstream queue as something like "s/(.+)/\1.upstream", and that's it!
I guess this is a feature request then. ;-)
On Tue, Nov 19, 2013 at 5:30 PM, Michael Klishin <[hidden email]> wrote: