<div class="gmail_quote">On Tue, Jan 29, 2013 at 11:54 AM, 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">
</div>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)<br>
</blockquote><div><br>This change is not tied to the new messaging envelope.  At one point, I thought the change might make use of the envelope, but the envelope won't fully be supported until after Grizzly and my thoughts on using it are a little controversial anyway as well as require a change to it.  As is, I'm pretty sure the envelope would either allow the downlevel RPC or not.  I want something that allows the RPC if in compatibility mode and fail the RPC if not.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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?<br>
<br>
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.<br>
</blockquote><div><br>We have discussed this and I'm not communicating it well.  I wonder if you are mixing up the queues for receiving the call with the queues for receiving the response to the call.  Let me try this notation:<br>
<br>All these will work and will not require any more than one queue for the response, which in all but one case is the old style queue:<br><ul><li>NEW(compat)->NEW(compat)</li><li>OLD->NEW(compat)</li><li>NEW(compat)->OLD</li>
<li>NEW(fast)->NEW(compat) : Note in this case, the compat mode code recognizes the new information in the message and response appropriately (in the new way)</li><li>NEW(compat)->NEW(fast)</li></ul><br>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.<br>
<ul><li>NEW(fast)->OLD</li></ul><br>Ray<br></div></div>