<div class="gmail_quote">On Fri, Jan 25, 2013 at 3:07 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Unfortunately I think there's a fundamental problem with any sort of<br>
solution that requires reissuing messages in a different format after a<br>
failure.  The messaging isn't connection oriented between the sender and<br>
receiver of a given message.  So, just because the last message failed<br>
doesn't mean the next one will.  The version implemented at the other<br>
end can change in between the original and re-sent message.<br></blockquote><div><br>I think your point is arguable, but my proposal won't work for another reason.  There is no fast way to detect a downlevel service in all cases.  I just looked at the ZMQ implementation and the new envelope causes the dispatched service thread to stack dump with no response sent.  The RPC has to time out, which isn't an acceptable way to handle a fallback retry.<br>
<br>I originally proposed this based upon what I know about the AMQP implementation, which would return a failure reply in the case of the 'method' key missing in the request. <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


> And (optionally) perhaps even make a change in the checking of the<br>
> envelope to look for unexpected content in that envelope. For example,<br>
> if we decide in the future to add an implementation version or whatever,<br>
> that a version that supported the envelope, but not the new content<br>
> would fail the RPC."<br>
<br>
That's how the envelope works now.  It includes a version number.<br>
Locally we maintain a version number for the latest version that is<br>
supported.  An incoming message lists the minimum version that must be<br>
implemented for the message to be successfully processed.  If that check<br>
fails, an exception will be raised  If it gets updated to include<br>
additional information, the version number will get bumped.<br></blockquote><div><br>This part of my proposal goes beyond the RPC version number and I think still has merit.  My proposal is not only to check for known keys in the envelope, but also to confirm that there are no unknown keys in the envelope.  And if an unknown key is found, fail the RPC.  That way some non-backward compatible change specific to amqp and not ZMQ could be identified as a new entry in the envelope, for example as an amqp version number.<br>
<br>Otherwise new non-backward compatible changes would need to go through two releases.  The first for the option to be recognized but disabled and a second for it to actually be enable, just as being done for the RPC envelope.  With my proposal, we can skip the recognizing release, since by definition an unknown entry in the envelope is recognized as a failure.<br>
<br>I'm not certain the exception that is raised today for version mismatch results in a failed RPC.  That might need to be enhanced for my proposal to work.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I think we should also try to avoid a new configuration option if at all<br>
possible.</blockquote><div><br>Agreed, but it may not be possible.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> We just won't be turning that<br>
on for the sender-side until post-Grizzly.
<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><br>I don't want to wait for post-Grizzly (or post H if it doesn't make it in Grizzly)<br>for this RPC performance improvement.  Recall that this improvement takes a<br>
cluster of 3 RabbitMQ servers with mirroring enabled from a maximum of 35<br>RPCs/sec to a maximum 800 RPCs/sec, a 23X improvement.<div class="yj6qo ajU"><div id=":1tn" class="ajR" tabindex="0"><img class="ajT" src="https://mail.google.com/mail/u/0/images/cleardot.gif"></div>
</div><br>