30 Nov 2013, 03:59
Generic-user-small

Kent Miller (2 posts)

I am on OS X 10.9 with node v0.10.22. On the examples in chapter 4, I am unable to get publisher.bind('tcp://*:5432', ... to work. It throws an error:

events.js:72
    throw er; // Unhandled 'error' event
          ^
TypeError: Socket is busy
    at Socket._ioevents (/Users/kpmiller/js/node_modules/zmq/lib/index.js:198:22)
    at Socket._flush (/Users/kpmiller/js/node_modules/zmq/lib/index.js:343:23)
    at processImmediate [as _immediateCallback] (timers.js:330:15)

publisher.bind('tcp://localhost:5432', ... works ok. It seems like a valid thing to use, but I am wondering why the code doesn’t work as is, or if this was a change in 10.9 or the node version that makes this not work.

I should add that the “*” was present in the zmq-watcher-pub.js, but the zmq-watcher-sub.js used “localhost”. This is apparent to me after I figured out what to look for. Maybe it is a typo or changed later in the process?

Thanks

30 Nov 2013, 19:52
Generic-user-small

Geoff Lanotte (1 post)

I had the same thing happen, and found this article that suggested bindSync instead of bind.

http://stackoverflow.com/questions/14322599/socket-is-busy-when-connecting-before-bind

That resolved the issue for me.

01 Dec 2013, 08:11
Generic-user-small

Raymond May, Jr. (6 posts)

bindSync fixed the issue for me as well

01 Dec 2013, 18:55
Me-dinner_pragsmall

Kirk Quesnelle (3 posts)

bindSync will just make it run for me without errors but it still doesn’t do anything..

for example it does not echo this to console

console.log(‘Listening for zmq subscribers…’);

hrmm….

01 Dec 2013, 22:50
Generic-user-small

Kent Miller (2 posts)

Kirk, I have the same problem. After I made the example run by replacing the “*” with the “localhost”, I do not get any messages to the subscriber. At some point I’m going to try rebooting my system to see if there are any resources stuck unreleased or something like that.

I was not expecting this stuff to be this sensitive and I’m really surprised to have to spend this amount of time trying to debug it.

02 Dec 2013, 09:31
Generic-user-small

Gugi Gustaman (1 post)

I have the exactly same problem with Kent.

Hope someone can solve this problem.

FYI, I use nodeJS on Debian Wheezy 7.1.0

$ node –version v0.10.21

$ npm –version 1.3.15

$ node –harmony -p -e ‘require(“zmq”)’ { ZMQ_CAN_DISCONNECT: 1, ZMQ_PUB: 1, ZMQ_SUB: 2, ZMQ_XPUB: 9, ZMQ_XSUB: 10, ZMQ_REQ: 3, ZMQ_XREQ: 5, ZMQ_REP: 4, ZMQ_XREP: 6, ZMQ_DEALER: 5, ZMQ_ROUTER: 6, ZMQ_PUSH: 8, ZMQ_PULL: 7, ZMQ_PAIR: 0, ZMQ_POLLIN: 1, ZMQ_POLLOUT: 2, ZMQ_POLLERR: 4, ZMQ_SNDMORE: 2, STATE_READY: 0, STATE_BUSY: 1, STATE_CLOSED: 2, zmqVersion: [Function], Context: [Function], Socket: [Function], version: ‘3.2.3’, types: { pub: 1, xpub: 9, sub: 2, xsub: 10, req: 3, xreq: 5, rep: 4, xrep: 6, push: 8, pull: 7, dealer: 5, router: 6, pair: 0 }, ZMQ_HWM: 1, ZMQ_SWAP: 3, ZMQ_AFFINITY: 4, ZMQ_IDENTITY: 5, ZMQ_SUBSCRIBE: 6, ZMQ_UNSUBSCRIBE: 7, ZMQ_RATE: 8, ZMQ_RECOVERY_IVL: 9, ZMQ_MCAST_LOOP: 10, ZMQ_SNDBUF: 11, ZMQ_RCVBUF: 12, ZMQ_RCVMORE: 13, ZMQ_FD: 14, ZMQ_EVENTS: 15, ZMQ_TYPE: 16, ZMQ_LINGER: 17, ZMQ_RECONNECT_IVL: 18, ZMQ_BACKLOG: 19, ZMQ_RECOVERY_IVL_MSEC: 20, ZMQ_RECONNECT_IVL_MAX: 21, ZMQ_MAXMSGSIZE: 22, ZMQ_SNDHWM: 23, ZMQ_RCVHWM: 24, ZMQ_MULTICAST_HOPS: 25, ZMQ_RCVTIMEO: 27, ZMQ_SNDTIMEO: 28, ZMQ_IPV4ONLY: 31, ZMQ_LAST_ENDPOINT: 32, ZMQ_ROUTER_MANDATORY: 33, ZMQ_TCP_KEEPALIVE: 34, ZMQ_TCP_KEEPALIVE_CNT: 35, ZMQ_TCP_KEEPALIVE_IDLE: 36, ZMQ_TCP_KEEPALIVE_INTVL: 37, ZMQ_TCP_ACCEPT_FILTER: 38, ZMQ_DELAY_ATTACH_ON_CONNECT: 39, ZMQ_XPUB_VERBOSE: 40, ZMQ_ROUTER_RAW: 41, ZMQ_IPV6: 42, options: { _fd: 14, _ioevents: 15, _receiveMore: 13, _subscribe: 6, _unsubscribe: 7, affinity: 4, backlog: 19, hwm: 1, identity: 5, linger: 17, mcast_loop: 10, rate: 8, rcvbuf: 12, last_endpoint: 32, reconnect_ivl: 18, recovery_ivl: 9, sndbuf: 11, swap: 3 }, createSocket: [Function], socket: [Function] }

03 Dec 2013, 05:08
Avatar_pragsmall

Jim R. Wilson (59 posts)

Hi all,

Thanks for taking the time to report this issue! I’m really sorry that it’s giving you all so much trouble :/

There’s a subtle difference between binding * and binding localhost. When you bind *, you’re telling the OS that you want to listen on any IP that the machine responds to. This makes the service accessible to the outside world. When you bind to localhost, only other local service will be able to bind to it (127.0.0.1). For the examples in the book, this is fine.

So the * was intentional of the publisher (the binding endpoint). On the other hand, the subscriber has to be specific about the machine it wants to connect() to. This is why it says localhost.

I don’t recall running into this problem when writing the examples for the book, but I have had this kind of trouble using the zmq module in the past.

I recommend not using the bindSync() option. It’s antithetical to Node’s asynchronous nature, and as you can see it doesn’t exactly help.

Here’s a slightly cleaned up version of something I’ve used in the past to retry binding if it fails:

// attempt to bind to the specified endpoint;
// this could either fail synchronously by throwing an exception,
// or asynchronously as an argument to the callback.
let attemptBind = function(){
  try {
    publisher.bind(endpoint, function(err) {
      if (err) {
        console.log('WARNING: publisher.bind(' + endpoint + ') failed, will retry in a bit. ' + err.message);
        setTimeout(attemptBind, 1000);
      } else {
        console.log('INFO: publisher.bind(' + endpoint + ') succeeded');
      }
    });
  } catch (err) {
    console.log('WARN: publisher.bind(' + endpoint + ') failed, will retry immediately. ' + err.message);
    process.nextTick(attemptBind);
  }
};
// make first attempt to bind this endpoint
attemptBind();

In my experience, you have to capture both the immediate failures (thrown exceptions) and delayed failures (Errors passed to the callback).

On the up side, using Promises here would probably help. With a Promise chain, both the thrown exception and the callback error would trigger the rejection of the promise. Then your fail clause could return a new Promise which retried the bind after some interval, continuing the chain.

If you haven’t worked with Promises yet, don’t worry, they’re explained in Chapter 6.

21 Dec 2013, 18:13
Generic-user-small

Lance Ulmer (4 posts)

This issue was biting me for a long time. Nothing I did was working. I decided to install the specific version of zmq and the node module used in the book, which did the trick.

Using homebrew, I:

$ brew uninstall zmq
$ cd /usr/local
$ brew versions zmq
4.0.3    git checkout 8b24dd2 Library/Formula/zeromq.rb
4.0.2    git checkout 57c9388 Library/Formula/zeromq.rb
4.0.1    git checkout 55e901e Library/Formula/zeromq.rb
3.2.4    git checkout c356bf7 Library/Formula/zeromq.rb
3.2.3    git checkout fda0d27 Library/Formula/zeromq.rb
...
$ git checkout fda0d27 Library/Formula/zeromq.rb
$ brew install zmq

I also put homebrew back to it’s newest commit:

$ git reset --hard HEAD

Then, back in my project directory, I:

$ npm uninstall zmq
$ npm install zmq@2.4.0

The code ran for me on OSX 10.9.1 with no modifications afterwards. The messages delivered as expected.

22 Dec 2013, 21:34
Jon_pragsmall

Jon Trainer (2 posts)

Lance’s solution of installing zmq@2.4.0 fixed the problem for me.

23 Dec 2013, 15:16
Avatar_pragsmall

Jim R. Wilson (59 posts)

Thanks Lance, this is very helpful!

01 Jan 2014, 18:13
Generic-user-small

Cris Lawrence (8 posts)

I also went with Lance’s solution (Mac 10.8.5) and it does work…sort of. Sometimes the subscriber script spews out the following message and quits:

node –harmony zmq-watcher-sub.js Invalid argument (stream_engine.cpp:526) Abort trap: 6

If I am persistent, the script starts put it always seems to miss the first touch of target.txt. All subsequent touches are recorded…just not the first. The same appears to apply if sub is up and I bring pub up…the first message is dropped.

  • Cris
04 Jan 2014, 22:55
Generic-user-small

Lance Ulmer (4 posts)

Glad this is working for some of you!

Cris, I’m not sure if this will help, but I think that the harmony flag is supposed to have two dashes “–harmony” instead of the one in your error message.

Edit: I see that it’s the forum taking out the dash now. My apologies.

04 Jan 2014, 23:36
Generic-user-small

Alex Dennis (1 post)

Lance’s solution worked for me as well on OX 10.9

16 Jan 2014, 17:50
Generic-user-small

Chet Harrison (7 posts)

I figured if bind was locking the port it could use some code to release it on exit. (I am totally flying by the seat of my pants here but …) Add this to the end of the publisher

publisher.on('SIGINT', function() {
	publisher.close();
})

Appears to do the trick. Lucky me.

02 Feb 2014, 20:41
Generic-user-small

Tom Jendrzejek (1 post)

Also on OS X 10.9.1, and wanted to get this working properly on the current version of zmq.

Turns out that on publisher.bind() an error was being passed (Error: Operation not supported by device) and subsequently ignored… as stated at the beginning, always handle errors!

Found this SO answer that gives a great explanation of the underlying issue. Changing localhost in zmq-watcher-pub.js to 127.0.0.1 got everything functioning.

  You must be logged in to comment