Open Stack

On Sat, Jan 26, 2013 at 12:32 AM, Ray Pekowski <pekowski at gmail.com> wrote:

> On Fri, Jan 25, 2013 at 3:07 PM, Russell Bryant <rbryant at redhat.com>wrote:
>
>> Unfortunately I think there's a fundamental problem with any sort of
>> solution that requires reissuing messages in a different format after a
>> failure.  The messaging isn't connection oriented between the sender and
>> receiver of a given message.  So, just because the last message failed
>> doesn't mean the next one will.  The version implemented at the other
>> end can change in between the original and re-sent message.
>>
>
> 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.
>
> 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.
>

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130128/453f3e6a/attachment.html>