Solution: migrate to MPLv2, as explained here http://zeromq.org/area:licensing

• [x] @trevorbernard
• [x] @miniway
• [x] @markif
• [x] @fernandezpablo85
• [x] @sjohnr
• [x] @davipt
• [x] @ealgell
• [x] @HeinrichHartmann
• [x] @capacman
• [x] @crocket
• [x] @ipechorin
• [x] @nicholassm
• [x] @msteinhoff
• [x] @markrileybot
• [x] @sbanacho
• [x] @kevinkreiser
• [x] @ifesdjeen
• [x] @hintjens
• [x] @vsg
• [x] @cbusbey
• [ ] @imleon
• [x] @kcarlson
• [ ] @kedzie
• [ ] @cossin
• [x] @devinrsmith
• [x] @pavelbucek
• [x] @yebenes
• [x] @zh217
• [x] @arashthearcher
• [x] @gsnewmark
• [x] @baboune

Could you kindly reply

I hereby agree to publish my contributions to JeroMQ under the MPLv2 license

?

If you have any objection to relicensing your contributions, let us know the reasons. Thanks!

Hello,

We are using ZMQ for our server (reactphp/zmq) and our client (zeromq/jeromq). We run multiple instances of the server and each server has several clients connecting to it. We use several other sockets but we are facing an issue with the TCP communication between the PUB socket on the server and the SUB ones on the clients. The issue is very odd as it is not easy to replicate but from time to time the client stops receiving messages from the server. This happens on all of our server instances and their clients once every 2-3 months but we have a new server instance that replicates this issue in around 20 - 30 minutes. Our servers are "identical" and this points us to a network difference.

We made a simple app that just opens several threads with SUB sockets and listen on the same topic. They all fail eventually but we observed that not all of them fail at the same time. Also, restarting a client solves the issue so we think that the issue is most likely with the client. The server logs indicate that the send is called on the PUB socket and the listening thread is still running on the client calling recvStr on the SUB socket once every several seconds. This points us to a ZMQ issue but we don't know it for sure.

In any case, right now we are looking into the jeromq implementation but we are wondering if anyone else experienced something like this and maybe has some pointers.

Thank you.

Hi Guys,

We have a very strange and critical problem that I need your help! The scenario is that we send a message in client application and for some reason, it didn't arrive to the server application.

• We use version 0.4.3
• In the client application, we use DEALER socket (TCP)
• In the server application, we have a ROUTER socket and Reactor thread that catches the incoming events.
• In the client application we have one Zcontext and each thread that sends a message from the client creates a shadow socket, creates the DEALER socket, send the message to the server and waits 5 sec for ACK message from the server.

Part of the client code: ZMsg msg = createMessage() ; msg.send(socket); socket.setReceiveTimeOut(5000); response = socket.recvStr(); In case that we didn't get answer from the server, we assume that there is a network / load issues on the server. BUT in our case! we don't see the message in the server side at all!

We have some traffic captures and I need your help in order to understand the problem. In a good scenario, we see that the client push data to server: C->S [SYN] S->C [SYN, ACK] C->S [ACK] C->S [PSH, ACK] S->C [ACK] S-C [PSH, ACK] C->S [ACK] C->S [PSH, ACK ... In a bad scenario, which we don't see traffic in the server and not getting ACK message in the client: C->S [SYN] S->C [SYN, ACK] C->S [ACK] S-C [PSH, ACK] C->S [ACK] C->S [RST, ACK] The reset from the client is after the timeout of 5 min.. that we didn't get ACK response. Then, we close the socket in the client with linger 0

Can you please help? What can be the reason that the messages don't arrive to the server ?

Thanks! Kobi.

These last weeks, bugs impacting major features were fixed.

The big thing for me is that these ultra important major features were absolutely never tested: downgrading capabilities, socket reconnection, Android compatibility. I take the responsibilities of my mistakes, and I would like to go forward on that matter and be constructive about it.

I propose to enforce testing scenarii so no commit will provoke a regression of that level.

• Downgrading capabilities: We can always introduce some option to force protocol version usage, that will allow to test protocol compatibilities within Jeromq. Not the best, but still a step forward. I would prefer environments set with different versions of libzmq, so testing can connect and exchange messages with them.

• Socket reconnection: I have currently no idea how we can test that at end-to-end level. Any suggestion would be welcome.

• Android compatibility Right now the code is compatible with Android API level 10. The thing is that JDKs are not fully implemented depending on the versions (some classes, some methods are missing depending on this level). Is it possible to setup Travis so we can at least run a compilation of the project on Android environment (distribution of devices is here)?

Hi - The code seems like it can spin in the reaper thread:

"reaper-1" prio=10 tid=0x00002aaab8c1d800 nid=0x18f3 runnable [0x00000000497e1000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.NativeThread.current(Native Method) at sun.nio.ch.SourceChannelImpl.read(SourceChannelImpl.java:166)

• locked <0x00000000c3a0c3f8> (a java.lang.Object) at zmq.Signaler.recv(Signaler.java:160) at zmq.Mailbox.recv(Mailbox.java:107) at zmq.SocketBase.process_commands(SocketBase.java:799) at zmq.SocketBase.in_event(SocketBase.java:907) at zmq.Poller.run(Poller.java:231) at java.lang.Thread.run(Thread.java:722)

We have found it goto 100% CPU. Seems like the channel is non blocking and it runs in a tight loop and therefore spins.

Has anyone else seen this?

I ran into a situation today where Poller#poll was blocked for a long time even though a timeout value of 1 second had been passed to poll. I attached a debugger and captured the state displayed in the attached screenshot. As you can see waitMillis has a value of just over an hour even though timeout is set to 1000.

This can happen because poll uses currentTimeMillis values to measure elapsed time without taking into account that the system clock may be changed in the meantime.

To avoid this I've updated poll to use nanoTime instead. This way elapsed time is measured correctly regardless of system time changes.

We have a router which is using jeromq 0.3.5. It hasn't any business logic and only take charge of message routing(receive a message from upstream system(uss) and send it to downstream system(dss)). All our other business systems(clients) connect to the router(server) by using PUSH-PULL mode. The problem happens randomly as follows:

1. router can't receive message from uss
2. dss can't receive message from router All the problems can be fixed by restarting uss、dss and router.But we don't figure it out so far.

p.s.

1. We haven't used heartbeat in uss、dss and router
2. Our OS is CentOS release 6.5
3. SO_KEEPALIVE OPTION net.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75

I'm using a PUB/SUB scheme to transport some data on an Android device and have it set up to use IPC. When bind is called it takes 10 seconds to complete the call every time. If I change it to use TCP, it binds immediately. I'd prefer using IPC, but the penalty seems highly unacceptable.

I am having this issue after some hours of good working:

zmq.ZError$IOException: java.io.IOException: Too many open files at zmq.Signaler.make_fdpair(Signaler.java:87) at zmq.Signaler.(Signaler.java:48) at zmq.Mailbox.(Mailbox.java:55) at zmq.Ctx.(Ctx.java:127) at zmq.ZMQ.zmq_ctx_new(ZMQ.java:225) at zmq.ZMQ.zmq_init(ZMQ.java:258) at org.jeromq.ZMQ$Context.(ZMQ.java:173) at org.jeromq.ZMQ.context(ZMQ.java:155) at ... (my files ) at java.lang.Thread.run(Thread.java:744) Caused by: java.io.IOException: Too many open files at sun.nio.ch.IOUtil.makePipe(Native Method) at sun.nio.ch.PipeImpl.(PipeImpl.java:42) at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:50) at java.nio.channels.Pipe.open(Pipe.java:150) at zmq.Signaler.make_fdpair(Signaler.java:85) ... 11 more]]

I am running this java server in Glassfish. I don't know if it is my fault or I should ask to system admin to check glassfish instance.

My ZMQ code:

            ZMQ.Context context = ZMQ.context(1);
    ZMQ.Socket sender = context.socket(ZMQ.PUSH);
    sender.connect("tcp://127.0.0.1:8083");
    sender.send(device, ZMQ.SNDMORE);
    sender.send("obs", ZMQ.SNDMORE);
    sender.send("["+message+"]", 0);
    sender.close();
        context.term(); 

I have this code inside a class created in a background thread. Each time I get a post to the server, I call new thread and create an instance of this class.

I did a build from the latest master snapshot on Github, and ran into this error when receiving data on the REP socket.

I/art: Rejecting re-init on previously-failed class java.lang.Class<zmq.io.StreamEngine$ProducePongMessage>
    Rejecting re-init on previously-failed class java.lang.Class<zmq.io.StreamEngine$ProducePongMessage>
I/art: Rejecting re-init on previously-failed class java.lang.Class<zmq.io.-$$Lambda$StreamEngine$W0Gv5o5INYywwEmQ5W1uv6x5Tgw>
E/AndroidRuntime: FATAL EXCEPTION: iothread-2
    Process: com.ravn.havoc, PID: 21413
    java.lang.NoClassDefFoundError: zmq.io.-$$Lambda$StreamEngine$W0Gv5o5INYywwEmQ5W1uv6x5Tgw
        at zmq.io.StreamEngine.<init>(StreamEngine.java:865)
        at zmq.io.net.tcp.TcpConnecter.connectEvent(TcpConnecter.java:149)
        at zmq.io.IOObject.connectEvent(IOObject.java:99)
        at zmq.poll.Poller.run(Poller.java:267)
        at java.lang.Thread.run(Thread.java:818)

The stack references these lines in StreamEngine.java:

    private final Function<Msg, Boolean> processIdentity = this::processIdentityMsg;
    private final Supplier<Msg>          nextIdentity    = this::identityMsg;

Its not clear to me why this is throwing the error...

I am writing a library that communicates with the ZeroMQ server of OpenNMT. This code works using 0.3.6, but hangs on the receiving using any 0.4.x branch.

    public OpenNMTZeroMQClient(String host, int port) {
        this.context = ZMQ.context(2);
        this.socket = context.socket(ZMQ.REQ);
        String hostAddress = "tcp://" + host + ":" + port;
        LOG.info("Connecting to '{}'", hostAddress);
        socket.connect(hostAddress);
    }


    public void translate(String text) {
        String js = new JSONArray()
                .put(new JSONObject()
                        .put("src", text))
                .toString();
        LOG.info("Sending '{}'...", js);
        boolean wasSent = socket.send(js.getBytes(ZMQ.CHARSET), 0);
        if(wasSent) {
            LOG.info("Sent!");
        }
        LOG.info("Receiving...");
        String reply = socket.recvStr();
        LOG.info("Received: '{}'", reply);
    }

    public void close() {
        if(this.socket != null) {
            this.socket.close();
        }
        if(this.context != null) {
            this.context.term();
        }
    }

It doesn't actually fail, but it just hangs on the recv() call. The server didn't receive anything, so the problem is probably that the send never happened.

EDIT: code formatting

Consider this code:

try (ZContext zContext = new ZContext(); ZMQ.Socket client = zContext.createSocket(SocketType.REQ)) {
            client.setLinger(0);
            client.setSendTimeOut(0);
            client.setReceiveTimeOut(0);

            client.setImmediate(false);

            client.connect("tcp://" + host + ":" + port);

The connect call blocks the thread for ever if host is for example 223232 and port 22323 (something that doesn't make sense). For my application the host and port rely on user input so that is a problem. Can that be somehow avoided from happening?

My system has a broker with two sockets, one xPub and one xSub. When I try to subscribe the xSub socket to all topics I get an IllegalArgumentException with the error message Unknown Option 6. It looks like that the subscription command is internally mapped to the number 6. But there is no switch case option that handles the number 6.

ZMQ.Socket xSubSocket = context.createSocket(SocketType.XSUB);
xSubSocket.bind(X_SUB_ADDRESS);
xSubSocket.subscribe(""); // subscribe to all

Exception in thread "main" java.lang.IllegalArgumentException: Unknown Option 6
	at zmq.Options.setSocketOpt(Options.java:547)
	at zmq.SocketBase.setSocketOpt(SocketBase.java:234)
	at org.zeromq.ZMQ$Socket.setSocketOpt(ZMQ.java:910)
	at org.zeromq.ZMQ$Socket.subscribe(ZMQ.java:2113)

What's the recommended way to handle this?

Pub socket and Sub socket lose connection at the same time, but SUB will reconnect, pub does not reconnect, Sub socket can receive messages, but others cannot receive the messages my Pub socket send.

			ZContext context = new ZContext();

			ZMQ.Socket publisher = this.context.createSocket(SocketType.PUB);

			publisher.setTCPKeepAlive(1);
			publisher.setTCPKeepAliveIdle(20);
			publisher.setTCPKeepAliveInterval(10);
			publisher.setHeartbeatIvl(2*1000);
			publisher.setHeartbeatTimeout(5*1000);
			publisher.setHeartbeatTtl(10*1000);
			publisher.setReconnectIVLMax(2000);
			publisher.setReconnectIVL(3*1000);
			publisher.setReconnectIVLMax(10*1000);

			publisher.connect(this.pubURL);

We have one publisher and two subscriber applications utilizing ZeroMQ's Pub-Sub pattern without implementing any heartbeat mechanism.

One application is running on (10.159.251.23) that publishes messages on port 6666: publisher.publisherSocket = zContext.createSocket(SocketType.PUB); publisher.publisherSocket.bind("tcp://*:6666");

And on the same host (10.159.251.23) another application is running that subscribes to this port 6666: subscriberSocket = zContext.createSocket(SocketType.SUB); subscriberSocket.subscribe("API-PROXY.INITIATOR.RES"); subscriberSocket.connect("10.159.251.23:6666");

Additionally, there's a different host (10.159.251.22) running the same subscriber application that subscribes to this publisher application on host 10.159.251.23:6666

The subscriber application on both hosts has been running since last 7 days. However on running netstat -an we see that the receive queue of the subscriber application running on (10.159.251.23) is full: [kaushx@mslt4wct8080 ~]$ netstat -an | grep 6666 tcp6 0 0 :::6666 :::* LISTEN tcp6 0 0 10.159.251.23:52440 10.159.251.22:6666 ESTABLISHED tcp6 0 2588034 10.159.251.23:6666 10.159.251.23:50172 ESTABLISHED tcp6 4196046 0 10.159.251.23:50172 10.159.251.23:6666 ESTABLISHED tcp6 0 0 10.159.251.23:44368 10.159.251.22:6666 ESTABLISHED tcp6 0 0 10.159.251.23:6666 10.159.251.22:45164 ESTABLISHED tcp6 0 0 10.159.251.23:44148 10.159.251.22:6666 ESTABLISHED tcp6 0 0 10.159.251.23:6666 10.159.251.22:45166 ESTABLISHED

This issue keeps occurring every few weeks which get resolved only on re-starting the subscriber application. Do you have any ideas what might be going wrong? Is there any way to clear the receive queue on reaching some threshold? We're using jeromq-0.5.1