[rabbitmq-discuss] versioned routing

Fri Jul 30 00:08:27 BST 2010

Aaron

On Thu, Jul 29, 2010 at 8:23 PM, Aaron Westendorf <aaron at agoragames.com> wrote:
> 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

Don't you mean *queues* will round robin?

Exchanges provide pubsub, ie. delivery to all subscribers that satisfy
the routing rule.

alexis

> 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>