Mark, thanks for the input...<br><br><div class="gmail_quote">On Tue, Jan 29, 2013 at 9:14 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In this case, there is a (performance) benefit to using the new feature<br>
so it probably does make sense to have an off-by-default feature which<br>
we'd enable by default for the H release.<br>
<br>
The config option should be documented though :)<br></blockquote><div><br>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.<br><br>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.  There is an alternative that makes msg_id the name of the response queue with the advantage that a log entry can be generated on the caller side stating the called failed due to calling a downlevel service.  This case is a user error.  The user enabled the fast option while downlevel services are present.<br>
<br>I now favor the approach of leaving msg_id as the unique identifier of the message, but just want to be clear of the consequences.  I will wait a while to see if anyone cares and then resubmit the patch for code review and hope we have reached a consensus.<br>
<br>Ray<br></div></div>