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

[Kenneth Adam Miller]

On Mon, Dec 29, 2014 at 1:34 PM, Dmitri Toubelis <
dmitri.toubelis at alkeron.com> wrote:

> 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.
>
> Somehow, your message got moved to my spam folder...


> 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.
>

See that's the weird part. I was just pointing that out about the guide-it
gives an example where subscribers use connect, but the missing message
guide says start all subscribers first and then the publisher. So I did. It
 works on my host--and I *know* that the connect call completes because
I've tested it with an absolutely minimal program on my host.

int main(void) {
zmq::context_t ctxt{1};
zmq::socket_t *sock = new zmq::socket_t{ctxt, ZMQ_SUB};
sock.connect("inproc://doesnotexist");
int i=0;
std::cin >> i;
 }

This, on my host, will run to cin and wait for the user patiently, and
*not* throw an error. Docker blows up.

I resolved to change the architecture so that an XPUB/XSUB starts up
process startup with the context singleton container, and the just connect
the publishers and subscribers. Problem is, now it's blowing up with Socket
operation on non-socket.

  _xpub = new zmq::socket_t(_context, ZMQ_XPUB);
  _xpub->bind("inproc://killpub");
  _xsub = new zmq::socket_t(_context, ZMQ_XSUB);
  _xsub->bind("inproc://killsub");
  zmq::proxy(_xsub, _xpub, NULL);


> 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.
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141229/83b7a7b9/attachment.htm>