Open Stack

>  
> I'm glad to hear there is a good chance that I can get this approved in a single release and with a documented config option.
>  
> The other contention point is how the RPC msg_id sent in the message data is used. The (somewhat) short explanation is that if the new implementation continues to use it as a unique identifier for the message and the fast option is enabled, a NEW->OLD RPC call will get executed on the server side, the response will be sent to a queue that will be immediately deleted (auto-delete), the RPC call will timeout on the caller side and no meaningful log entry will be produced.  
This is fairly moot if this feature is tied to the new messaging envelope, however. Sending from NEW->OLD simply won't work if the envelope is enabled. (Note, Russell has put some effort into making the envelope cross-version compatible, but I have some concerns about that tied to my previous email regarding the envelope format as it stands today)

Assuming there is no new envelope… We've discussed it already, but I'm still unclear why the old queue cannot be, for the duration of a single release, ALSO be consumed by the caller?  

The OLD system sends the message somewhere and the NEW system knows where it is being sent to, it is just refusing to pick it up. That is, besides the impact on performance, why not ALWAYS use the new method while retaining the ability of the old pattern to continue functioning if this is a choice? Given a no-backwards-compat configuration flag, or an upgrade to H, this consumer could be disabled for a performance benefit.  Basically, support both and deprecate the old.

Regards,
Eric Windisch