[zeromq-dev] HWM behaviour & blocking

[Michel Pelletier]

On Thu, May 10, 2012 at 9:56 AM, Pieter Hintjens <ph at imatix.com> wrote:
> On Thu, May 10, 2012 at 11:14 AM, Steffen Mueller
> <zeromq at steffen-mueller.net> wrote:
>
>
> This is most definitely "exotic" routing, and should be relatively
> easy to roll your own, but do first study the routing and reliability
> examples in the Guide in detail, because most likely as you do, your
> view of the problem will change quite profoundly.

This viewpoint change is something I think a lot of people who use 0mq
come to have.  In almost every step in learning to use this library I
have approached a problem with a solution in mind, and come away with
something different and better.  My personal problem is that like most
developers I have a huge ego, and when confronted with a distributed
engineering problems say to myself "Oh, I got this, I'm an expert,
this is trivial, all I need is X, Y, and Z" but then I come to realize
that I don't know how to solve the problem, I'm not an expert in
distributed computing (few of us are) I don't "got" it, and that's
when I go read the guide again.

I have had a hard time myself convincing some of my local colleagues
that 0mq is the exactly perfect tool for the job it does, not
necessarily the job they have in mind.  They want a perfect world
where an asynchronous system satisfies their synchronous desires.
They want to control, and be able to know, the state and location of
every message and connected peer at any one time.  As if that were
possible!  These are the types that tend to set HWM to 1.  It's hard
to convince them that this is the wrong approach and that the right
approach is to have peers communicate their states and message acks to
each other and that you have to deal with the cases where things fall
down.

It's a tough social and documentation problem and I'm not sure how to
go about fixing it.  But for now, I'm happy to have 0mq as my "secret
weapon".

-Michel