Open Stack

On Monday, January 28, 2013 at 12:49 PM, Ray Pekowski wrote:
> On Sat, Jan 26, 2013 at 12:32 AM, Ray Pekowski <pekowski at gmail.com (mailto:pekowski at gmail.com)> wrote:
> > On Fri, Jan 25, 2013 at 3:07 PM, Russell Bryant <rbryant at redhat.com (mailto: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. 
> 


Ray,

No problem. You're now one of the few that has actually read through and analyzed the code. For that, I'm very grateful.

The following is a lengthy digression, but for reference, explains my plans for a similar patch for impl_zmq:

I found it interesting that you submitted this patch for review because my intention has been to do similar to what you're doing with AMQP, but for ZeroMQ, to have this reply queue configured per-process. In this case, we'll need a process identifier (i.e. your reply-q) and what is presently processed as a msg_id. However, with impl_zmq, we don't use the msg_id to identify the reply topic, instead the return topic is embedded in the arguments to the '-reply' method. The reply method basically says to run a curried method and cast the return value back in an actor-style manor.

Anyway, my plan is to keep the msg_id as it is, as an identifier created by the caller, but change the return-topic sent in the '-reply' message to include the process identifier. Older clients will understand that, because they're just replying to a different queue.  Then, the (new) ZmqProxy receives the message and does what it needs to, to decode the new topic. I suppose, I'm lucky in that this code was already making a distinction between message-id and topic.

Regards,
Eric Windisch