Tuesday September 13, 2011

[Time] NameMessage
[00:57] mascool how can I pass ZMQ_NOBLOCK to the recv method in PHP ?
[00:58] mascool I tried $jobResponse = $statsResponse->recv(ZMQ_NOBLOCK);
[00:58] mascool where $statsResponse = new ZMQSocket( $context, ZMQ::SOCKET_PULL );
[00:58] mascool $statsResponse->connect( "tcp://localhost:6557" );
[00:59] mascool comes back saying ZMQ_NOBLOCK is not defined
[00:59] mascool which I understand why
[01:04] dcolish the constant for noblock is ZMQ::MODE_NOBLOCK
[01:05] mascool dcolish: thanks! that worked!
[01:05] mascool is there a place where I can find this info next time ?
[01:05] mascool I checked the documentation but couldn't find php specifics
[01:06] dcolish no prob, yeah the php binding docs have a good example for sending/receiving using NO_BLOCK:
[01:06] dcolish i'm not really a php hacker, but it looks straightforward enough
[01:06] mascool this is perfect, thanks again!
[01:07] dcolish you bet
[06:23] awainzin howdy
[06:24] awainzin thanks much for the zmq guide. going through it in python, was thinking it would be cool to link to the other zhelpers source (right now it says it's only required by C, but it's used in e.g. rtmama example)
[08:36] Sil4nc4 hi guys, a quick question, i use the request - reply broker message form, but when my worker dies after sending the request, the server replies but the message gets lost because the worker is not there, any suggestions?
[08:53] sustrik you have to timeout
[08:53] sustrik then you can either report error
[08:53] sustrik or resend the request
[09:30] Sil4nc4 ok thx sustrik
[10:02] Sil4nc4 The problem is when the worker stops and restarts the jobs don't get processed
[10:02] Sil4nc4 any suggestions
[10:03] sustrik timeout at the client, then either report the error to the user or resend the request
[10:07] poison hi sustrik, we don't quite get it: if we take out the broker and connect the worker to the queuer then when either one crashes and we start the scripts again they are able to continue, but with that broker in between it has a different behaviour so it seems
[10:08] sustrik what exactly happens?
[10:08] sustrik does it not reconnect?
[10:08] poison well the worker is designed to do 1000 runs and stops then
[10:09] poison so the queuer hangs, which is OK
[10:09] poison but when I start a new worker
[10:09] poison then the worker doesn't get the jobs
[10:09] poison it should say 'Received work: Do this job'
[10:09] poison but it doesn't
[10:10] sustrik how many requests do you send?
[10:10] poison it's a loop which never stops
[10:10] poison (it's on the pastebin:
[10:11] sustrik a the messages don't get to a worker after the dispatcher restart, right?
[10:16] Sil4nc4 indeed suste
[10:16] Sil4nc4 indeed sustrik
[10:17] sustrik then it's a bug
[10:17] sustrik please do create issue in the bug tracker
[10:17] sustrik and attach a minimal test case to the ticket
[10:17] sustrik also, mention the version of 0mq you are using
[10:18] Sil4nc4 oh the dispatcher is fine, only when restarting the working the working does not receive jobs
[10:18] Sil4nc4 sorry for the misread sustrik
[10:18] sustrik so you restart the worker
[10:18] Sil4nc4 /working/worker/
[10:18] sustrik and it doesn't get any messages afterwards
[10:19] Sil4nc4 nope
[10:19] Sil4nc4 which it should no? since after stuff is queued
[10:19] Sil4nc4 or does the dispatcher queue stuff for a certain worker
[10:19] Sil4nc4 id bound
[10:20] sustrik it should get the new messages
[10:20] sustrik if it doesn't, it's a bug
[10:20] sustrik report the problem using the bug tracker
[10:20] sustrik mention what's the expected behaviour and what are you seeing instead
[10:40] poison sustrik: we created a bug:
[10:41] sustrik thanks!
[10:42] Sil4nc4 weird stuff
[10:58] poison sustrik: I'll try to use the 3.0 release, you think this is something usefull that might be fixed?
[10:59] sustrik definetely
[10:59] sustrik if it's a bug it should be fixed
[11:00] sustrik btw bug report says the affected version is 2.1.9
[11:00] sustrik is it so?
[11:06] poison zmq
[11:06] poison ZMQ extension => enabled
[11:06] poison ZMQ extension version => @PACKAGE_VERSION@
[11:06] poison libzmq version => 2.1.9
[11:06] sustrik ah
[11:07] sustrik i misunderstood your question
[11:07] sustrik as for 3.0, the problem may have been fixed, but i am not sure
[11:08] Sil4nc4 but still, more people should have had this problem no? :) since it is kinda basic behavior
[11:10] sustrik yep
[11:10] sustrik i have to reproduce the problem and have a look what's going on
[11:19] Sil4nc4 thx, in the meanwhile i'll test latests 3.0
[11:48] poison damnz, we have issues with getting the php binding to work with the 3.0 beta
[11:56] sustrik the 3.0 branch seems to be merged into phpzmq
[11:56] sustrik mikko is the right person to ask
[11:59] poison ok sorry, it's my bad, I got it to work, but it seems that I experience the same issue there
[12:01] sustrik ok
[12:55] CIA-121 jzmq: 03Joshua Foster 07master * r3c8b652 10/ src/org/zeromq/ : Add correct checks for version number ...
[12:55] CIA-121 jzmq: 03Gonzalo Diethelm 07master * r6da1142 10/ (.gitignore src/Socket.cpp src/org/zeromq/ Merge pull request #72 from jhawk28/master ...
[12:55] CIA-121 jzmq: 03Joshua Foster 07master * r15a0a86 10/ (.gitignore src/Socket.cpp src/org/zeromq/ Add new 3.0.0 socket options ...
[13:49] mikko poison: i will look at the bug when i get home
[14:27] CIA-121 libzmq: 03Mikko Koppanen 07master * r8f8bfca 10/ (src/req.cpp tests/ tests/test_invalid_rep.cpp): Fixed issue with req assertions (issue 252) ...
[14:27] sustrik mikko: i've committed your patch to the master
[14:27] sustrik it's up to pieter to apply it to 2.x and 3.x
[14:29] pieterh_1 sustrik: hi...
[14:29] sustrik hi
[14:29] pieterh_1 I wasn't sure which patch to apply, there are two attached to the issue
[14:29] sustrik the newer one
[14:29] pieterh_1 presumably it's the second one but I was waiting for confirmation
[14:29] pieterh_1 ok
[14:29] sustrik you can apply just the fix (~3 lines)
[14:29] sustrik the rest is a test program
[14:30] sustrik which you may or may not include
[14:30] pieterh_1 ah... indeed, ok
[14:30] pieterh_1 I'll apply the full patch to 3.0
[14:30] sustrik thx!
[14:31] mikko pieterh_1: thanks pieter
[14:31] mikko two assertions nailed
[14:36] pieterh_1 mikko: nice... :)
[15:22] pieterh mikko: applied to 2.1 (partial), 2.2 (full) and 3.0 (back ported from libzmq) :-)
[15:33] nicolas is it possible to use two PUB sockets connect to the same endpoint ?
[15:34] nicolas like many to one instead of one to many ?
[15:40] cremes nicolas_: yes
[15:40] cremes if the SUB socket has called zmq_bind() on the socket, you can have multiple PUB
[15:41] cremes sockets connect to it
[15:45] mikko pieterh: nice!
[19:45] calvin Hi all, I was wondering if anyone has ever experienced an issue with reconnecting subscriber crashing the server in a pub/sub pattern
[19:46] calvin Specifically using a C++ server and a C# client
[20:20] pieterh calvin: hi... do you have a reproducible crash?
[20:20] calvin Not really, it seemingly happens maybe 1/4 or 1/5 times
[20:20] calvin More likely if the server had been running longer before I restarted the client
[20:21] pieterh can you get a backtrace?
[20:21] pieterh we would need to make a reproducible test case, in C
[20:22] pieterh you can already create a Jira issue, with the back trace, then we can work together to make a test case
[20:22] calvin alright, let me see if i can find one
[20:23] calvin it might take me up to 24 hours though
[20:27] cremes pieterh_: is there a wiki page detailing the purpose/roadmap for 4.0 like there is for 3.0?
[20:27] cremes this weekend i'm doing some work to add 3.0 support to the ruby ffi bindings, so i'd like
[20:27] cremes to stub in 4.x support too but i can't find any details on it
[20:29] cremes from the mailing list archives, it looks like 4.0 is different *only* in that it drops support for ZMQ_IDENTITY
[20:30] cremes confirmed? or are there other differences?
[20:44] pieterh cremes: sorry, was out
[20:44] pieterh there is no roadmap for 4.0 yet
[20:44] pieterh it's an excellent idea to put one together
[20:45] pieterh the other changes are: new ROUTER socket, no more DEALER socket
[20:46] cremes pieterh_: which one is sustrik actively working on? 3.0 or 4.0?
[20:47] pieterh 4.0
[20:47] pieterh as in, making proactive changes
[20:47] cremes ok
[20:48] pieterh I'd have preferred it was called 3.1 but he insisted, mainly to allow space for major changes
[20:48] cremes i'm rereading the ML discussion on 3.0/4.0... looks like 3.0 is meant to be a short-term place-holder
[20:48] pieterh in theory the WLP and API is the same as 3.0
[20:48] cremes and introduces 1) new wire protocol, 2) new api
[20:48] pieterh yup
[20:48] cremes great
[20:48] pieterh this is what I tried to cover in the planning:
[20:49] pieterh we are maybe being over-cautious in the rate of change
[20:49] pieterh to be seen
[20:50] cremes i'll have formal support for 3.0 and 4.0 in the ruby ffi bindings soon; hopefully that will help encourage
[20:51] cremes some broader adoption
[20:51] cremes thanks for answering my questions
[20:52] pieterh hmm, nice, I've also added 4.0 support to CZMQ (mainly in the get/setsockopts API)
[21:08] errordeveloper I'm really desperate to figure out the difference between what's under 'czmq' and 'libzmq' repos on github!!
[21:09] errordeveloper also zdevice is an odd one .. but I can see it's just something that takes a json file as a description, right ?
[21:30] ketralnis I'd like to have servers reporting logs via zmq to a central collector, but for fault tolerance I'd like to have more than one collector and withstand the loss of a collector without losing many messages (a few is okay but 100% is not)
[21:31] ketralnis If I just specify more than one receiver in the clients, it round-robins among the collectors, but when I lose one I drop 1/N messages until the collector returns
[21:31] ketralnis Is there an in-built fault tolerance feature that I'm missing?
[21:49] michelp ketralnis, what kind of sockets are you using? PUSH/PULL?
[21:50] michelp sounds like you might want to use PUB/SUB instead
[21:50] ketralnis michelp: yes
[21:50] ketralnis michelp: how does that help for fault tolerance?
[21:51] michelp you can have more than one subscriber that can act as a backup if another subscriber fails
[21:51] michelp PUSH's send() will also block if there are no recipients iirc
[21:52] michelp whereas PUB will never block
[21:53] michelp i'm not really following why you would want round robin behavior in a log collector, wouldn't you then need to merge the collected data afterwards?
[21:57] ketralnis I don't necessarily want round-robin, that's just the default behaviour of multiple receivers to a PUSH socket
[21:57] ketralnis I just want fault tolerance
[22:01] michelp i see what you're saying, when a collector goes away, you want the sender to skip over the missing receiver and send the message to the next collector in line
[22:04] michelp ketralnis, are you setting an identity on the receiver?
[22:05] michelp the guide says "If a receiver (SUB, PULL, REQ) side of a socket sets an identity, then the sending (PUB, PUSH, PULL) side will buffer messages when they aren't connected up to the HWM"