[rabbitmq-discuss] versioned routing

[Aaron Westendorf]

Santi,

We have a similar requirement, and it seems you have most of the
pieces in place to implement a similar solution.

Topic exchanges will round robbin between consumers so no need to
worry there.  Seeing as you have the version already stored in your
session, you can continue to maintain both old and new sessions so
long as consumers and bindings remain in place for both.

So you have a hypervisor that can maintain consumers for all your
deployed versions.  In your case, LoginService might consume from the
queue "ls.1_0_0" which is bound to your publishing exchange with a
routing key of the same name.  Your new version would run alongside
using queue name and binding "ls.1_0_1".  If a user does not have a
session yet, then something in front of AMQP will have to determine
based on URL, host, whitelist, etc which routing key to use.

I would caution against using dotted version notation in your routing
key, mostly to keep sane as your routing scheme expands in complexity
and you have numerous bindings.

Hope that helps.

-Aaron


On Thu, Jul 29, 2010 at 1:38 PM, Santi Manninen <santikschzt at gmail.com> wrote:
> Hi,
>
> I've been trying to figure out a way to single out service versions
> for front end users.
> Here is the current, simplified scenario:
>
> - Web users with sessions issue requests to a front end server, which
> just routes their messages
> - Messages are routed to queues called 'LoginService' and 'PingService'
>
> I have a number of LoginService and PingService instances, each bound
> to the same queue, so messages are distributed with round-robin and I
> can add/remove them based on demand. Wonderful.
>
> PingService currently runs 1.0. Now, I'd like to add a completely new
> version of PingService, 1.0.1, with spiffy new features, and have
> 'selected users' (through Sessions given from LoginService) use the
> new version and try it out, so I can monitor and test that the new
> version of PingService works correctly before moving more, or all
> users into the new version, and deploying 1.0.1 onto more servers.
>
> We talked about doing this with |Blaze|| on the IRC channel (thanks!)
> but we didn't really come up with an elegant solution yet.
>
> - Bind the PingService queues with the version name in the queue name,
> and have the front end route messages to PingService, based on the
> version defined in the Session. Many problems with this. Old users
> with active sessions bound to the previous version (which was just
> built 15 minutes ago, perhaps!) will lose service once the new version
> is completely rolled out, and a failover from basicReturn in the
> client would have to be implemented.
> - Use topic exchanges for each version, eg. 1.0.1.topic, and a
> catch-all with *.topic. I think round-robin is lost here?
>
> That's the gist of it. Your help is appreciated. Thanks!
>
> Santi
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>



-- 
Aaron Westendorf
Senior Software Engineer
Agora Games
359 Broadway
Troy, NY 12180
Phone: 518.268.1000
aaron at agoragames.com
www.agoragames.com