I've just completed a project migrating our applications from ActiveMQ to RabbitMQ. The most challenging part was replicating the functionality of jms selectors. Here are some of the selection rules that we had:
key IN (value1, value2...)
key1 IN (value1...) AND key2 IN (value1...) AND....
I've implemented this using Headers exchanges with multiple bindings per queue. Theoretically, any sql based selector can be decomposed into a combination of key/value pairs where each combination corresponds to a binding. For example the following routing key:
key1=value1|key1=value2&key2=value1|key2=value2 would result in 4 bindings:
key1=value1&key2=value1, key1=value2....
I added support for these use cases in SpringAMQPConsumer (see the code here: https://github.com/art11s/camel-spring-amqp). Are you interested in adding this functionality to the project?
I've just completed a project migrating our applications from ActiveMQ to RabbitMQ. The most challenging part was replicating the functionality of jms selectors. Here are some of the selection rules that we had: key IN (value1, value2...) key1 IN (value1...) AND key2 IN (value1...) AND....
I've implemented this using Headers exchanges with multiple bindings per queue. Theoretically, any sql based selector can be decomposed into a combination of key/value pairs where each combination corresponds to a binding. For example the following routing key: key1=value1|key1=value2&key2=value1|key2=value2 would result in 4 bindings: key1=value1&key2=value1, key1=value2....
I added support for these use cases in SpringAMQPConsumer (see the code here: https://github.com/art11s/camel-spring-amqp). Are you interested in adding this functionality to the project?