Saturday September 3, 2011

[Time] NameMessage
[00:23] count So, I'm using a zmq.QUEUE in python
[00:23] count And everything is fantastic and full of wonderfullness
[00:23] count except when all of my REP sockets quit
[00:23] count the queue stalls
[00:24] count (when they join back up, it's still stuck waiting for a recieve from one that died without talking)
[00:24] count the REQ does:
[00:24] count socket.send("blah")
[00:24] count msg = socket.recv()
[00:24] count (in a loop)
[00:25] count How do I handle the disconnected clients properly?
[00:25] count ie: that socket.recv() for that particular message is gone now
[00:25] count I catch termination of the interpreter in the REP socket, and issue a socket.close/context.term
[00:25] count but that doesn't seem to help
[00:26] count Is there a way to 'flush' the REP ?
[03:33] count hello?
[03:33] jsimmons hi
[03:36] count hm, nevermind, I thinkn I need to reverse my req/rep
[03:39] count YAYA that fixed it
[03:39] count I was htinking about things backwards
[03:39] count 0mq hurts my brain
[04:33] count anybody got a minute to help with a wierd problem with a matched pair of req/rep sockets?
[04:33] count I'm losing the very last message
[04:33] count er, the response for the very last message
[04:38] count nm, figured that out !
[05:33] sustrik jefferai: which manpage is that?
[05:41] CIA-32 libzmq: 03Martin Sustrik 07master * r9fb9fea 10/ (src/tcp_connecter.cpp src/xrep.cpp): Improve error reporting in a minor way ...
[07:03] CIA-32 libzmq: 03Pieter Hintjens 07master * r4138aca 10/ (6 files): Fixed doc to clarify how label parts work ...
[08:20] CIA-32 libzmq: 03Martin Sustrik 07master * r193fa1c 10/ src/tcp_address.cpp : Accept square brackets around IPv6 address ...
[12:09] mikko sustrik: there?
[12:10] sustrik mikko: hi
[12:10] mikko
[12:10] mikko can you test that when you got time?
[12:10] mikko it's the poller selection
[12:10] sustrik sure
[12:10] mikko you can do --with-poller=something to force polling system
[12:10] mikko or let it detect automatically
[12:11] sustrik ok, i'll test it with select, poll and epoll
[12:11] mikko i wonder if the --with-poller=xyz should also check if that polling system actually works
[12:11] mikko currently it just sets -DZMQ_FORCE_XYZ
[12:12] mikko and assumes that user knows what they are doing
[12:12] mikko so on linux --with-poller=kqueue will result to build time error
[12:14] sustrik that's ok, i would say
[12:15] sustrik it does exactly what the user asked for
[12:19] mikko seems to work ok on linux and mac
[12:20] mikko kqueue detected on mac and epoll on linux
[12:23] sustrik nice
[12:39] sustrik mikko: the test programs are actually run or just compiled?
[12:40] mikko linked
[12:45] sustrik ok
[12:58] sustrik mikko: looks like it's working ok
[12:58] sustrik can you send it as a signed-off patch to the mailing list?
[17:47] jefferai sustrik: it's the zmq-ipc page at
[21:03] mikko pieterh: here?
[21:03] mikko have you broken 2-1 and 2-2 windows builds lately?
[21:04] mikko ip.cpp: In function 'int zmq::resolve_local_path(sockaddr_storage*, socklen_t*, const char*)':
[21:04] mikko ip.cpp:353:13: error: 'EPROTONOSUPPORT' was not declared in this scope
[21:49] ahbritto When using SUB and setting a filter, what is it filtering on?
[21:51] ahbritto Never mind. :)
[21:52] mikko ahbritto: it's effectively a prefix match
[21:52] ahbritto mikko: Thanks, I refound the section on message envelopes.
[21:55] ahbritto If I want to have multiple things publishing and multiple things subscribing, I must have a stable device in the middle?
[22:02] mikko ahbritto: that would be the best way
[22:02] mikko you can also have all subscribers connect to all publishers
[22:02] mikko or use pgm
[22:03] mikko but usually device is the least painful way
[22:03] ahbritto The doc is a little unclear. I assume multiple publishers can't bind to the same address?
[22:04] mikko no, they can't
[22:04] ahbritto Thank you. :)