[rabbitmq-discuss] Routing key questions/suggestions

Christian Legnitto clegnitto at mozilla.com
Tue Nov 30 17:43:49 GMT 2010

I have a couple of quick questions/suggestions about routing keys. I guess this is more AMQP-specific, but this list is as good as any to discuss ;-)

1. Why use "." as the routing token separator? Can we make it configurable on the broker? Can we support sending a magic X-AMQP-ROUTING-SEPERATOR or something header with the message so it can be anything and vary by message?
	* It seems like an odd choice to use a character that will show up in data a lot
	* All publishers need to sanitize and all consumers need to translate back
		* Consumers could always use "#", but then they could potentially match items they aren't expecting
		* If consumers use "*" and the data has a period, they may not match when they expect


I'm listening to commit messages from GitHub. My binding is github.push.*.mycoolproject, which means I want to listen to all push messages by anyone for a project named mycoolproject. If someone's github username has a period in it though, I won't see the messages (github.push.john.smith.mycoolproject). If I bound with github.push.#.mycoolproject I would see the previous message, but I might also get messages for other projects with GitHub users that have mycoolproject in their username (github.push.this.is.mycoolproject.user.project2). I know this isn't the best example, but I'm sick and my head is a bit murky ha.

2. Are there are future plans to publish a message with multiple routing keys?
	* I know I can publish the same message multiple times with different routing keys, seems inefficient
	* I may want to surface the message data in various useful ways into the routing key


For bugzilla messages, when someone changes a bug I send a bug.changed.[field] message. Many tools want to pivot on specific users though. It'd be nice to publish them also as bzuser at example.com.changed.bug so those tools don't have to listen to all changes and group by user themselves, which seems very inefficient.

If these should be taken up by the AMQP list/working group let me know and I'll try to bring them up in the correct place.


More information about the rabbitmq-discuss mailing list