Open Stack

On Tuesday, January 29, 2013 at 14:00 PM, Eric Windisch wrote:

> > 
> > This is the only case that will have the problem of loosing the RPC call reply. We cannot listen on two queues for the response since we want NEW(fast) to be fast.
> > NEW(fast)->OLD
> 
> Precisely my point. Why does it have to be fast? If the only reason to shun compatibility is performance, lets take the performance bite - by default. The configuration setting can then just be a toggle that breaks NEW(fast)->OLD and restores the performance gains.


I should clarify that the idea here is that *by default* we'd have the following compability:

1) Grizzly <=> Folsom
2) Grizzly <=> H (assuming H removes compatibility with Folsom)

Where Grizzly performance by default will be non-optimal, but H (or G with a no-compat option enabled) can forgo Folsom compatbility for the performance benefit.

Regards,
Eric Windisch