<div class="gmail_quote">On Sat, Jan 26, 2013 at 12:32 AM, Ray Pekowski <span dir="ltr"><<a href="mailto:pekowski@gmail.com" target="_blank">pekowski@gmail.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="gmail_quote"><div class="im">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></div><div class="im">
<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><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></div></div></blockquote><div><br>
I incorrectly defamed the ZMQ implementation.  Sorry Eric.  At least for RPC calls, a downlevel version (e.g Folsom) of the ZMQ implementation would return an RPC exception response if it were to receive a message that had the new RPC envelope.<br>
<br>I do still see a problem with my proposal to reissue the failing RPC without the envelope.  Due to the different ways in which the two implementations (AMQP and ZMQ) handle the RPC envelope in the a downlevel release (e.g. Folsom), it would not be practical to identify all the implementation specific ways a missing envelope might fail.<br>
<br>In short, continue to ignore this part of my proposal.  I would like to hear opinion about the second part of my proposal which is to additionally verify there are no foreign keys in the envelope and failing as a version mismatch if there are. <br>
</div></div>