[zeromq-dev] Strange pub/sub behaviour on Windows

[Pieter Hintjens]

This is a known issue; see https://zeromq.jira.com/browse/LIBZMQ-270.

The problem is that until you do some blocking work on the SUB thread,
it cannot send its subscriptions upstream, so the PUB socket will not
send it anything. When the SUB does the connect, it sends its
subscriptions immediately. This worked on 2.x because there was no
upstreaming.

The solution would be to manage subscriptions in the stream engine
instead of the socket; non-trivial. There are suggested workarounds in
the issue.

On Fri, Dec 6, 2013 at 12:01 PM, Gary Verhaegen
<gary.verhaegen at huawei.com> wrote:
> Hi all,
>
> We are seeing unexpected results from 0MQ pub/sub sockets on Windows. As a foreword, I have never worked with any other kind of sockets before, so hopefully there is no confusion about how they "should" work; I will, however, try to be as explicit as possible as to what I'm expecting.
>
> We are using 0MQ through the jzmq library. We are using jzmq 2.2.2 and libzmq 3.2.4 on Windows 7 inside a remote virtual machine.
>
> I have isolated the surprising behavior to the following (java) code:
>
> --
>
> import org.zeromq.ZMQ;
> import org.zeromq.ZMQ.Context;
> import org.zeromq.ZMQ.Socket;
>
>
> public class Main {
>
>     private static void sleep(int t) {
>         try {
>             Thread.sleep(t);
>         } catch (InterruptedException e) {
>         }
>     }
>
>     public static void main(String args[]) {
>         Context context = ZMQ.context(2);
>         Socket pub = context.socket(ZMQ.PUB);
>         pub.setSndHWM(60_000);
>         pub.connect("tcp://127.0.0.1:4001");
>         Socket sub = context.socket(ZMQ.SUB);
>         sub.setRcvHWM(20_000);
>         sub.bind("tcp://*:4001");
>         sub.subscribe("".getBytes());
>         sub.setReceiveTimeOut(100);
>         sleep(1000);
>         int i = 100_000;
>         while (i > 0) {
>             pub.send("1".getBytes(), 0);
>             i--;
>         }
>         pub.close();
>
>         sleep(1000);
>
>         int k = 0;
>         while (sub.recv() != null) {
>             k++;
>         }
>         sub.close();
>
>         System.out.println("---");
>         System.out.println(k);
>         System.out.println("---");
>
>         context.term();
>     }
> }
>
> --
>
>
> Compiling and running the above code on my machine will print:
>
> ---
> 0
> ---
>
> So there is apparently no message going through. This is one of the surprising behavior: no message seems to go through a pub/sub socket pair if the publisher connects. This holds if we reverse the socket creations (i.e. if the subscriber binds before the publisher connects). If the publisher binds and the subscriber connects, in both possible orderings, the code prints:
>
> ---
> 60000
> ---
>
> The second surprising behavior concerns the high water marks. I have seen nothing in the documentation that suggests the behavior we are seeing, although I must admit I did not read all of it. Here's what we observe while fiddling with the above code (with the publisher binding) :
>
> * The sub socket hwm seems to have no effect whatsoever.
> * For the hwm of the pub socket to have any effect, it must be set before the socket binds.
>
> I'm pretty sure the bind/connect asymmetry is not the expected behavior. I'm much less definitive about the high water marks, but I thought I'd also mention it.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev