[zeromq-dev] Connection refused error exclusively in Dockerized app

Dmitri Toubelis dmitri.toubelis at alkeron.com
Mon Dec 29 19:34:04 CET 2014

> I have a dockerized ZMQ instance where I am trying to develop an app.
> I have duplicate source both inside the docker instance and at the
> host level. I can compile both inside and out with duplicate
> compiler output and both compile.

> The problem is, there has to be some difference between the docker
> ubuntu instance and the host, because when I run the docker ubuntu
> instance, I get an error at runtime with my unit tests:

> terminate called after throwing an instance of 'zmq::error_t'
> what(): Connection refused

> But the unit tests run to completion on the host.
> I've debugged it, and put print statements, and I know for certain
> that the docker instance is failing at a socket connect call.

> sock = new zmq::socket_t(ctxt, ZMQ_SUB);

> sock->connect("inproc://something"); //<-- FAILS HERE!

> Currently I have some confusion as to why it works this way in the
> host, because I have a subscriber connecting to an inproc instance
> that doesn't have anything bound at yet, but the missing message
> problem solver in the ZMQ guide says start subscribers first and
> then the publisher. In any case, it works very well on the host.
First of all are you sure the socket was bound BEFORE you connect to it? When you start your server and client in separate threads (which I presume you do) you need to make sure that socket is bound before your client thread starts. 

I had the similar issue myself and I ended up writing a separate server_start() function for the server using common mutex/condition to synchronize socket creation (create mutex/condition, start the server thread thread, wait on the condition and in the server thread I bind the socket, signal on the condition). This way it is guaranteed that when server_start() function exits the socket is bound and ready to roll. Of course, you can use any thread synchronization technique, mutex/condition is just an example. 

Hope this helps. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141229/b3c0a13f/attachment.htm>

More information about the zeromq-dev mailing list