[zeromq-dev] HWM behaviour & blocking

[Paul Colomiets]

Hi Justin,

On Thu, Jun 28, 2012 at 8:50 AM, Justin Karneges <justin at affinix.com> wrote:
> On Thursday, May 10, 2012 01:53:48 PM Pieter Hintjens wrote:
>> On Thu, May 10, 2012 at 3:44 PM, Paul Colomiets <paul at colomiets.name> wrote:
>> > Can you be more specific, why setting HWM to 1 is a bad thing? Do you
>> > mean, that it smells bad to set HWM to 1 for reliability? Or do you
>> > think that setting it will have other consequences? (low performance?)
>>
>> it's bad because you're trying to force a synchronous model on an
>> asynchronous system, and doing it at the wrong level. If you really
>> want synchronization you MUST get some upstream data from the
>> receiver. Just throttling the sender cannot work reliably.
>
> I'm about to set HWM to 1 and I recalled a thread about this so I've looked it
> up. Totally agree about what's been said so far. The reason I want to do this
> is because I need a way for an event-driven application to determine if data
> has been written to the underlying kernel. This is useful in case the
> application wants to close the socket immediately after writing data. In a
> traditional blocking application, this is easy: just call zmq_close() and
> it'll unblock when done. However, in an event-driven application, the only way
> I can think of imitating this functionality is by setting HWM to 1 and waiting
> until ZMQ_EVENTS indicates writability, then calling zmq_close().
>

Why you need zmq_close in the asynchronous application in the first
place? Is your application very connection hungry? We never close
zeromq sockets even on fairly low traffic connections, and it works
nice.

-- 
Paul