[prev in list] [next in list] [prev in thread] [next in thread]
List: zeromq-dev
Subject: Re: [zeromq-dev] Connection refused error exclusively in Dockerized app
From: Kenneth Adam Miller <kennethadammiller () gmail ! com>
Date: 2014-12-29 22:44:48
Message-ID: CAK7rcp9f0RA1Xtw7HW7ofpcDFG69ct_3bH8F8m2J_kwWTfueHg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Dec 29, 2014 at 1:34 PM, Dmitri Toubelis <
dmitri.toubelis@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@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, \
2014 at 1:34 PM, Dmitri Toubelis <span dir="ltr"><<a \
href="mailto:dmitri.toubelis@alkeron.com" \
target="_blank">dmitri.toubelis@alkeron.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div \
style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><div><div \
class="h5"><blockquote \
style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255); \
margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">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.<div \
dir="ltr"><div><br></div><div>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:</div><div><br></div><div><div>terminate called after throwing an instance of \
'zmq::error_t'</div><div> what(): Connection \
refused</div></div><div><br></div><div>But the unit tests run to completion on the \
host.</div><div>I've debugged it, and put print statements, and I know for \
certain that the docker instance is failing at a socket connect \
call.</div><div><br></div><div><div>sock = new zmq::socket_t(ctxt, \
ZMQ_SUB);</div><div><br></div><div>sock->connect("inproc://something"); \
//<-- FAILS HERE!</div></div><div><br></div><div>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.</div></div></blockquote></div></div></div></div></blockquote><div>Somehow, your \
message got moved to my spam folder...</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div \
style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">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.<br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>int main(void) {</div><div>zmq::context_t \
ctxt{1};</div><div>zmq::socket_t *sock = new zmq::socket_t{ctxt, \
ZMQ_SUB};</div><div>sock.connect("inproc://doesnotexist");</div><div>int \
i=0;</div><div>std::cin >> i;</div><div> }</div><div><br></div><div>This, on \
my host, will run to cin and wait for the user patiently, and *not* throw an error. \
Docker blows up.</div><div><br></div><div>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.</div><div><br></div><div><div> _xpub = new \
zmq::socket_t(_context, ZMQ_XPUB);</div><div> \
_xpub->bind("inproc://killpub");</div><div> _xsub = new \
zmq::socket_t(_context, ZMQ_XSUB);</div><div> \
_xsub->bind("inproc://killsub");</div><div> zmq::proxy(_xsub, _xpub, \
NULL);</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div \
style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)"><br>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.<br><br>Hope this helps.<br><blockquote \
style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255); \
margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal \
;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div \
dir="ltr"><div></div></div> \
</blockquote></div></div><br>_______________________________________________<br> \
zeromq-dev mailing list<br> <a \
href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br> <a \
href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" \
target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br> \
<br></blockquote></div><br></div></div>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic