Tuesday December 7, 2010

[Time] NameMessage
[08:08] the_hulk hi, for C API's on server side, i do not have to fork? it seems to be taken care of?
[08:08] Steve-o fork to do what?
[08:12] the_hulk fork to handle multiple clients, as we do with normal sockets fds
[08:12] Steve-o and thread pooling, etc, ok
[08:14] Steve-o It's covered pretty well in the guide,
[08:19] the_hulk ohk
[10:10] CIA-20 zeromq2: 03Martin Lucina 07master * r9bb5323 10/ doc/zmq_socket.txt :
[10:10] CIA-20 zeromq2: Clarify zmq_send() operation for ZMQ_PUB sockets
[10:10] CIA-20 zeromq2: Signed-off-by: Martin Lucina <> -
[10:16] CIA-20 zeromq2: 03Mikko Koppanen 07master * raed2eea 10/ (acinclude.m4
[10:16] CIA-20 zeromq2: Fix visibility on rhel4
[10:16] CIA-20 zeromq2: Signed-off-by: Mikko Koppanen <> -
[10:16] CIA-20 zeromq2: 03Mikko Koppanen 07master * ra335315 10/ acinclude.m4 :
[10:16] CIA-20 zeromq2: Fix werror flag store/restore
[10:16] CIA-20 zeromq2: Signed-off-by: Mikko Koppanen <> -
[10:16] CIA-20 zeromq2: 03Mikko Koppanen 07master * r1d81d2f 10/ :
[10:16] CIA-20 zeromq2: tar doesn't accept -C flag on solaris while extracting
[10:16] CIA-20 zeromq2: Signed-off-by: Mikko Koppanen <> -
[12:04] ptrb just to confirm -- no problem making multiple connect() calls on a single ZMQ_SUB socket, right?
[12:34] drbobbeaty ptrb: correct. You can have multiple connect() calls to one ZMQ_SUB socket.
[12:35] drbobbeaty In order to "tear down" the socket, you have to drop/close the socket. Meaning, you can't disconnect() just one of the connections - you have to take them all down.
[12:38] Steve-o unbind/disconnect was discussed previously:
[12:47] ptrb cool. thanks.
[14:43] sustrik drbobbeaty: hi
[14:43] drbobbeaty sustrik: hi... I sent in the patch to the ML.
[14:44] sustrik yes, just got it
[14:44] sustrik a minor point
[14:44] sustrik subscribe to the mailing list
[14:44] sustrik otherwise the messages are blocked
[14:44] sustrik and i have to approve them by hand
[14:45] sustrik if you don't want to get the traffic, you can switch that off
[14:45] sustrik but still be member of the list
[14:45] drbobbeaty Funny thing, I am subscribed, and I still keep getting blocked. Pieter talked to me about that, and we walked through it together. Very puzzling.
[14:45] sustrik hm, let me see
[14:45] drbobbeaty Please do... I'd love to not bother you guys.
[14:46] sustrik hm, i don't see you in the members list
[14:46] sustrik any idea what email address you have used to subscribe?
[14:46] drbobbeaty
[14:47] drbobbeaty That's what I use to "maintain" the ML on it's web site.
[14:47] sustrik aha
[14:47] sustrik but the emails you send are from a different address
[14:47] drbobbeaty OH! Duh.
[14:47] sustrik comcast
[14:47] drbobbeaty That's it... outgoing != incoming. I'll change that.
[14:47] sustrik great
[14:47] drbobbeaty Thanks for the pointer.
[14:48] sustrik i'll have a look at your patch shortly
[14:48] drbobbeaty I hope it's clean and easy. And adheres to the buidelines.
[14:51] sustrik one thing i am not sure of: is it possible that someone would want recovery ivl of zero?
[14:51] sustrik unreliable multicast...
[14:51] sustrik i am not even sure it's possible with OpenPGM
[14:51] sustrik if so, the default should be -1 rather than 0
[14:52] sustrik let me ask steven
[15:17] toni hi there. I am using a REQ socket doing socket.recv(zmq.NOBLOCK), but I am getting a "ZMQError: Resource temporarily unavailable" (using the python binding). As I saw in the docs for recv and zmq.NONBLOCK, there is this little sentence:"If there are no messages available on the specified socket, the zmq_recv() function shall fail with errno set to EAGAIN." I dont really understand. So the NOBLOCK option raises an error in case no messag
[15:20] cremes toni_: you see that "resource unavailable" message when your REQ socket is *not* connected to any REP (or XREP) sockets
[15:20] cremes make sure you have a z-endpoint
[15:21] cremes with an active socket attached to it
[15:21] toni cremes: but it should as it all works fine since I dont specify the NOBLOCk option @ recv()
[15:22] toni maybe its not connected yet?
[15:28] Guthur Should the timeout work with subscriber nodes?
[15:28] Guthur with polling
[15:29] Guthur It works fine if I set -1, but seems to not pickup messages when a timeout value is set
[15:31] toni cremes: okay, very strange.... the error disapears when I dont do zmq.NOBLOCK in s.recv(). When I specify the option, the error is raised. But why? The socket should be connected, as the error is not raised when no block is not specified
[15:43] cremes toni_: interesting... it's funny but i *only* ever do noblock send/recv so i don't understand what is happening in the blocking scenario
[15:44] cremes are you *certain* that the other socket has connected?
[15:44] toni cremes: yes I am really certain. But I found the solution describes here
[15:47] cremes toni_: hmmm, ok
[16:23] mikko mato: looks like solaris10 is still not happy
[16:24] mato mikko: it used to be, has your visibility change broken something?
[16:24] mikko mato:
[16:24] mikko when building --with-pgm
[16:25] mato mikko: ah, ok, i'll look at it later, in the middle of dissecting the linux network stack with sustrik right now
[16:25] mikko tries to include <sys/epoll.h>
[16:26] mato i guess openpgm in zmq has not been ported to solaris properly then
[16:28] mikko will look into it tonight
[17:27] mikko pfffff
[18:04] toni I am using the python binding, having a REQ socket connected to a XREP socket. When I try to send from the REQ socket I get "zmq.core.error.ZMQError: Operation cannot be accomplished in current state". Any ideas?
[18:06] cremes toni_: yes, req/rep sockets enforce a strict 1 send / 1 recv model; trying to do 2 sends or 2 recvs in a row generates a state machine error
[18:06] cremes look at the docs for req/rep
[18:12] drbobbeaty sustrik: my patch has a problem with it... I need to send you an additional change for using sequence numbers with OpenPGM. My mistake. Sorry.
[18:12] toni cremes: Thanks, thats the code snippet: the "aaaa". See the link for the traceback
[18:13] drbobbeaty sustrik: maybe it's not a problem... I'll send the details to the mailing list and you can decide.
[18:13] cremes toni_: your problem is at line 40
[18:14] cremes you need a recv in that block
[18:14] cremes again, read the docs on req/rep
[18:14] cremes you must do alternating send/recv with each one
[18:14] cremes you *cannot* just send with either socket; there must always be a matching recv
[18:14] cremes the pattern is request/reply, not request/request/request/request/reply
[18:14] cremes :)
[18:19] toni cremes: thanks
[18:20] cremes toni_: you are welcome... be sure to check out the guide on the web site; it covers that topic
[18:21] cremes andrewvc: planning to do another ffi-rzmq and zmqmachine release after 2.1 is out of beta
[18:21] andrewvc nice!
[18:21] cremes if you have anything you'd like to be in there, that's our deadline ;)
[18:22] toni cremes: I already read it, I also constructed the very last example in python. I just had some truble with the NOBLOCK option and tried to debug from scretch. Maybe its enough for today, after 10 hours of coding :-)
[18:22] andrewvc well, I was hoping to hack on it sometime soon, but I'm moving this weekend
[18:22] andrewvc I've had about zero free time the last couple weeks
[18:22] andrewvc unfortunately
[18:22] cremes toni_: np; we'll be here in channel next time you need help... take a break
[18:22] cremes andrewvc: yeah, real life is constantly getting in the way!
[18:23] andrewvc lol, so true
[18:23] andrewvc i'm actually going to la.rb hack night tonight, was hoping to get a little EM work there
[18:23] cremes cool... see if you can't recruit a few more 0mq hackers
[18:24] andrewvc hehe, I'm trying it's so fun to play with.
[18:24] andrewvc evanphx is usually there btw, I know you worked pretty closely with him on some ffi bugs right?
[18:25] cremes andrewvc: yeah, i did; the api drift between the rbx ffi support and the ffi gem caused him a lot of grief
[18:25] cremes he was pretty upset about *many* of the additions
[18:25] andrewvc hehe, yeah we had a similar conversation
[18:25] cremes i use 0mq with rbx daily; it's the best way to profile and debug my code these days
[18:26] andrewvc agreed, best stack trace for issues
[18:26] cremes yep, that too
[18:26] cremes it's quickly becoming my ruby of choice
[18:26] andrewvc I've wanted to test my employers code on rbx, but hpricot's sitting in the way
[18:26] cremes as soon as it gets windows support i'll use it there too
[18:26] cremes C extension issues?
[18:27] andrewvc yep, and I think it's one that no one's planning on fixing
[18:27] cremes direct RHASH access or something nutty?
[18:28] andrewvc oh, well look what google turned up
[18:28] andrewvc someone did fix it lol
[18:29] cremes ha!
[18:29] cremes no more excuses, andrewvc !
[18:29] andrewvc hehe
[18:29] andrewvc nope, well, one more, engineyard doesn't officially support rbx, but that's a minor hurdle
[18:29] cremes really? well, that's got to change sometime soon
[18:29] cremes it's all ey guys working on it!
[18:29] andrewvc yeah, weird eh?
[18:30] cremes oh, i know why... they are having trouble creating an ebuild recipe for it under gentoo
[18:30] andrewvc the default choices are only 1.8.7, REE and 1.8.6
[18:30] cremes i saw whyaines chatting about it with evan recently
[18:30] cremes no jruby even?
[18:30] andrewvc no
[18:30] cremes now i'm shocked
[18:30] andrewvc but the reality of EY is that everyone uses chef and customizes everything
[18:31] andrewvc EY is more a starting point than a destination
[18:31] cremes hmmmmm
[18:31] andrewvc not like heroku at all, we have so many changes to the stack
[19:11] raspi where i could find config examples for zmq_(queue|forwarder|streamer). manual gives only TBA.
[19:50] mikko raspi: i think in the code at the moment
[19:50] mikko raspi: i don't think there are written examples anywhere
[19:51] raspi ok :)
[19:51] mikko if you look at devices/zmq_queue/ in the source
[19:51] mikko the schema should be fairly easy to deduct from the code
[20:58] toni I have a REQ client connected to 2 XREP server. When one server dies, the socket.recv() on the client blocks for ever. The other server is still available, but doesnt get any requests. How can I prevent this starvation?
[20:59] toni I also tried to use a nonblocking XREQ socket on the client and ran in the same issue
[21:04] mikko it blocks even if you pass ZMQ_NOBLOCK?
[21:06] toni I thought the XREQ socket would be nonblocking?
[21:07] mikko it has unrestricted send/receive pattern but it's no non-blocking by default as far as i know
[21:07] mikko have you tried passing ZMQ_NOBLOCK to recv and checking for EAGAIN ?
[21:09] mikko you can also look at zmq_poll
[21:09] toni mikko yes I did. I found the snippet at the pyzmq issues
[21:11] toni mikko: thanks, I think I found my bug
[21:12] mikko np