Tuesday June 1, 2010

[Time] NameMessage
[04:51] jugg s.bind("tcp://localhost:15555"); fails with "no such device" However, s.bind("tcp://"); works fine, as does s.bind("tcp://lo:15555");
[04:51] jugg whereas s.connect("tcp://localhost:15555"); and s.connect("tcp://"); both work fine, but s.connect("tcp://lo:15555"); fails with "Invalid argument".
[04:53] jugg any combination of the successful bind/connect allow messages to flow just fine. (eg. bind - lo, connect - localhost)
[04:54] jugg any idea why binding 'localhost' fails, and connecting 'lo' fails?
[07:38] sustrik jugg: you can bind only to local NIC
[07:38] sustrik "localhost" is a hostname not NIC name
[07:38] sustrik use "lo"
[07:38] sustrik "eth0" and alike
[07:39] sustrik (on linux)
[07:53] jugg sustrik: it must also accept local ip addresses. And since the zmq layer already can resolve hostnames, it would be a convience to have it do so here as well.
[07:55] sustrik the problem is that there's no hint to distinguish between nic names and hostnames
[07:57] jugg a simple if fail then try scheme could be used
[07:58] sustrik yup, we've thought of that
[07:58] sustrik presumably, resolve nic name first, hostname if it fails
[07:59] sustrik obviously, it would mean that nic name can then overshadow a remote host
[07:59] jugg yes, although I might think to have a hardcoded check for 'localhost' first.
[08:00] sustrik it's up to OS to resolve names, 0mq should not mess with that imho
[08:02] jugg certainly. I was saying that if the device is 'localhost' then just skip nic name lookup (being that localhost is quite the common case).
[08:03] sustrik my point was that "localhost" is just a name a should thus be resolved by OS
[08:08] jugg anyway, I assume that trying to connect to a nic name is nonsensical, which is why s.connect("tcp://lo:15555") fails? It certainly is an odd error message however "invalid arguement", now that I've played with it "invalid argument" is the error message for any bogus hostname. Not very helpful.
[08:18] jugg all of this mucking around is because I got off track while trying to debug odd observed behavior with zmq resulting from the socket type and transport combination. eg pub/sub works fine with tcp:, but often fails with ipc:
[08:19] jugg I haven't isolated it yet, so I can't give a useful bug report (if any).
[08:27] sustrik interesting
[08:27] sustrik the code is same for tcp and ipc
[08:27] sustrik can you at least say what kind of error are you seeing?
[08:38] jugg well, it could still yet be very much user error, but it appeared that subscriptions were not taking affect, and in several instances, I would get an error about the ipc: address having some problem (the exact error messages are out of my scrollback). Yet, those error message seemed to go away if I changed the socket type. And when using tcp: I've never seen either of those issues.
[08:49] sustrik ok, i see
[08:49] sustrik if it ever happens again please do report the problem
[09:39] jugg hmm, I thought publications got into the bit bucket if the endpont doesn't exist. This is the case if the publisher is the one that binds the socket, but if it is the subscriber that binds the socket, then the publisher queues up all of its messages. Is this expected? And if so, why the change in behavior depending on which socket type binds/connects?
[09:53] sustrik PUB/SUB messaging pattern is like a radio tranmission; if you are not listining to the broadcast you won't be able to catch up later on
[11:39] jugg yes, so why is the publisher queuing up the messages?
[11:46] sustrik jugg: the queueing is built in so that messages are not dropped all the time because of random traffic peaks
[11:46] sustrik if you set HWM socket option on your publisher
[11:46] sustrik you'll limit the size of the queue
[11:46] sustrik once the max number of messages in the queue is reached, publisher will start dropping them
[11:47] jugg yes, so why does this queuing only occur if the publisher connects? It doesn't occur if the publisher binds.
[11:48] sustrik when you bind, there's no queue created at that moment
[11:48] sustrik you don't know how many peers will connect in the future
[11:48] sustrik and thus you cannot create appropriate number of queues
[11:49] sustrik when you connect you need only one queue, so it's created immediately
[11:49] sustrik the code can be changed so that 'connect' queue is created only when connecting to the peer succeeds
[11:50] sustrik but i am not sure what advantage we would get from that
[11:50] jugg consistency?
[11:50] sustrik sure
[11:50] jugg otherwise this needs documented.
[11:50] sustrik well, the documentation is "messages can be dropped"
[11:50] sustrik when exactly they are dropped is implemetation detail
[11:51] jugg eh
[13:41] jugg in a pub/sub configuration, it would appear that the only way to have multiple subscribers is if the pub socket is the one that binds the endpoint. In the case where a subscriber binds the endpoint, and the publisher connects, then other subscribers that connect do not receive publications. I'd expect that either all connecting subscribers receive the publications, or that it is not possible for other subscribers to successfully connect.
[13:43] sustrik jugg: sorry, i've missed the point
[13:43] sustrik can you say it in more simple way
[13:43] sustrik ?
[13:44] jugg a subscriber binds an endpoint
[13:44] jugg a publisher connects to the endpoint
[13:44] jugg everything is happy
[13:44] jugg more subscribers connect to the endpoint
[13:44] jugg these subscribers do not receive publications
[13:45] sustrik subscribers connect to the subscriber endpoint?
[13:45] jugg yes
[13:45] sustrik SUB socket is not compatible with another SUB socket
[13:45] sustrik see zmq_socket(3)
[13:45] sustrik SUB must speak to PUB and vice versa
[13:46] sustrik what are you trying to do?
[13:46] jugg which is why I'd expect the subsequent connects to fail.
[13:47] sustrik yes, they should
[13:47] sustrik but the connect is async
[13:47] sustrik so the error should be delivered asynchronously
[13:47] sustrik we need an error queue for that
[13:47] sustrik TODO
[13:47] jugg I see
[13:55] jugg So if the subscriber binds the endpoint, it is essentially stating that this is a private subscription, multiple publishers can publish to this private subscription. Multiple subscribe message filters may be used by the subscriber if desired.
[13:56] jugg If a publisher binds an endpoint, then many subscribers may connect to this endpoint. But a subscriber can only receive messages from a single publisher in this case.
[13:56] sustrik i would say it's symmetric
[13:56] sustrik consider you can connect the same socket multiple times
[13:56] sustrik so, for example:
[13:56] sustrik pub.bind (A)
[13:57] sustrik sub1.connect (A)
[13:57] sustrik sub2.connect (A)
[13:57] sustrik is equivalent to:
[13:57] sustrik sub1.bind (A)
[13:57] sustrik sub2.bind (B)
[13:57] sustrik pub.connect (A)
[13:57] sustrik pub.connect (B)
[13:58] sustrik resulting connection diagram looks the same in both cases
[14:00] jugg clear enough, thanks.
[14:02] sustrik you are welcome
[15:56] jugg quoting "we designed a minimalist wire protocol which can be described in a couple of paragraphs" Are those paragraphs available?
[18:58] cremes is it expected behavior that zmq_term() has an assertion failure unless all sockets in the context are closed first?
[18:59] cremes this is against 2.0.6 release
[19:44] mato cremes: no, that would be a bug
[19:44] mato cremes: however, that code has changed on master, so i suggest you re-test there
[19:44] cremes all right... i'll test on master in a bit
[19:50] CIA-17 zeromq2: 03Martin Lucina 07master * r74a03df 10/ (AUTHORS foreign/xmlParser/xmlParser.cpp): Merge branch 'master' of -
[20:20] mato cremes: since you asked about zmq_term()... I'm updating the docs for 2.0.7.
[20:20] mato cremes: could you comment if the following is clear: ?
[20:20] mato The zmq_term() function terminates the 0MQ context context.
[20:20] mato If there are no longer any sockets open within context at the time zmq_term() is
[20:20] mato called then context shall be shut down and all associated resources shall be
[20:20] cremes ok; i'm compiling master now so i can see if i am still getting on behavior
[20:20] mato released immediately.
[20:20] mato Otherwise, the following applies:
[20:20] mato · The zmq_term() function shall return immediately.
[20:20] mato · Any blocking operations currently in progress on sockets open within context
[20:20] mato shall return immediately with an error code of ETERM.
[20:20] mato · With the exception of zmq_close(), any further operations on sockets open
[20:20] mato within context shall fail with an error code of ETERM.
[20:20] mato · The actual shutdown of context, and release of any associated resources,
[20:20] mato shall be delayed until the last socket within it is closed with zmq_close().
[20:21] mato cremes: thx, but read the above, since that's the behaviour on master
[20:21] mato cremes: is my description clear enough?
[20:21] cremes it makes perfect sense; it is very clear
[20:21] mato great, thanks
[20:23] CIA-17 zeromq2: 03Martin Lucina 07master * r8ba1d3c 10/ (6 files): Documentation: zmq_term() and ETERM for 2.0.7 -
[20:23] CIA-17 zeromq2: 03Martin Lucina 07master * r9d00d30 10/ doc/zmq_init.txt : Documentation: zmq_init() API changes for 2.0.7 -
[20:28] versificateur hello everyone!
[20:28] versificateur i'm back to ask for some help aagin.. :)
[20:30] versificateur i've some difficulties to run (compile) the c++ server code i wrote based on zmq blog examples
[20:31] versificateur I got the following error: Package libzmq was not found in the pkg-config search path.
[20:32] cremes versificateur: please pastie the whole error including the command you used
[20:34] versificateur g++ `pkg-config --libs --cflags libzmq` -o server server.cpp Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable
[20:35] versificateur oops
[20:35] versificateur g++ `pkg-config --libs --cflags libzmq` -o server server.cpp
[20:35] versificateur Package libzmq was not found in the pkg-config search path.
[20:35] versificateur Perhaps you should add the directory containing `libzmq.pc'
[20:35] versificateur to the PKG_CONFIG_PATH environment variable
[20:37] versificateur but I try locate and found the required at pkg-config
[20:37] versificateur locate libzmq.pc
[20:41] sbeaulois hi
[20:42] sbeaulois i tried to compile zmq on RHEL but i have some errors when i tried ./configure configure: error: cannot link with -luuid, install uuid-dev
[20:42] sbeaulois i cann't fin uuid-dev for RHEL
[20:43] mato sbeaulois: I think it's called uuid-devel on RH
[20:43] sbeaulois i have install uuid-devel but i have the same error
[20:46] mato sbeaulois: which version of RHEL?
[20:47] sbeaulois i use RHEL 5
[20:48] mato don't know, sorry, I don't have that here... you need to install whichever package provides libuuid.a
[20:49] sbeaulois fine
[20:49] versificateur i resolve my problem by exporting the PKG_CONFIG_PATH
[20:49] versificateur it compile fine
[20:50] versificateur but when i run the binarie i have this error
[20:50] versificateur ./server: error while loading shared libraries: cannot open shared object file: No such file or directory
[20:51] versificateur it's similar to what an old issue i met with python bindings installation
[20:51] versificateur is anyone experienced this before??
[20:52] mato versificateur: you need to run ldconfig as root
[20:52] cremes versificateur: your compile line is wrong; don't use "libzmq" just use "zmq"
[20:52] cremes or what mato said :)
[20:53] versificateur mato: before or after compile??
[20:54] mato versificateur: only once, after doing make install for zmq
[20:54] versificateur okay i'm trying
[20:56] versificateur cremes: i don't think the zmq.cp exist
[20:56] mato versificateur: no, it's libzmq.pc
[20:57] versificateur so my compile line was right??
[21:00] mato yes
[21:02] versificateur i retried after ldconfig but still have the same issue
[21:03] mato you did do a make install after building zeromq, yes?
[21:04] versificateur after running ./configure make make install?
[21:04] versificateur yes
[21:04] mato don't know, then your system doesn't have /usr/local/lib in it's /etc/ or equivalent
[21:06] versificateur yes i think so
[21:10] versificateur i'll try by adding a zmq-64.conf with /usr/local/lib
[21:10] versificateur to /etc/
[21:10] versificateur directory
[21:10] mato yup, don't forget to rerun ldconfig when you make any changes
[21:17] versificateur mato: thanks!!! it works
[21:18] versificateur running netstat -l shoow me the zeromq port listening
[21:18] versificateur now i can test my code...
[21:18] versificateur thanks again :)
[21:22] mato np
[21:25] sbeaulois hi
[21:25] sbeaulois i found solution of my problem
[21:26] sbeaulois libuuid-devel is within of e2fsprogs package
[22:04] sbeaulois ne help
[22:04] sbeaulois need help
[22:04] sbeaulois try to compil my java script but i have some error
[22:04] sbeaulois java.lang.UnsatisfiedLinkError: /usr/local/lib/
[22:05] sbeaulois not found
[22:05] sbeaulois java.lang.UnsatisfiedLinkError: /usr/local/lib/ cannot open shared object file: No such file or directory