<div class="gmail_quote">On Tue, Jan 29, 2013 at 5:32 PM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> "Grizzly would also, by default, be able to send and reply to Folsom, as well as receive replies from Folsom as long as compatibility mode is not disabled."<br>
<br>
</div>Yes, it can do both, but not at the same time. Without listening on two queues, the code does one-or-the-other, but not both. The code is either forwards OR backwards compatible. It would be much easier for migrations if it can be both.</blockquote>
<div><br>With my change and compatibility mode enabled, all requests are sent in the old message format and replies listened for on the old queue.  If the call is sent to Folsom, it will come back on the old queue.  If the call is sent to Grizzly(fast) or Havana, those versions will recognize the old message format and reply on the old queue.  So Grizzly won't have to do listen on both to be able to communicate in all the ways you say the dual queue listen approach can.<br>
<br>If Folsom calls Grizzly(compat), Grizzly(compat) will recognize the old format and respond on the old queue.  If Grizzly(fast) or Havana calls Grizzly(compat), Grizzly(compate) will recognize the new format and respond on the new queue.<br>
<br>What else is needed?  How is that any less functional than the dual queue approach?<br></div></div>