Wednesday September 22, 2010

[Time] NameMessage
[01:03] dermoth actually one of the issues that I was seeing is obvious... in a php worker I want to have a persistent socket that use req/rep (or the x equivalent if needed), but if the backend isn'T responding timely I just want to leave early and go on, but then when the next request comes in the socket is still expecting a reply... how can I work around this?
[01:03] dermoth i guess that'S a good one for the ML :)
[11:53] raz hm
[11:53] raz looking at the divide&conquer example i wonder
[11:54] raz how does zmq behave when a worker does *not* indicate it finished? (e.g. because it crashed)
[11:54] raz will the task be re-queued to a different worker?
[12:02] guido_g no, you have to do it yourself
[12:07] raz hm
[12:08] raz the taskvent example doesn't seem to inspect the return value at all
[12:08] raz would s_send return an error if no worker picks the message up?
[12:10] raz the zmq_send man-page does not mention such an error tho
[12:10] guido_g
[12:11] guido_g there should be a description what happens for the socket types if something goes wrong
[12:12] raz hmyea
[12:12] raz the ZMQ_PUSH section doesn't tell me what happens when a msg can not be delivered tho
[12:12] raz or rather.. i assumed there was some sort of acknowledgement going on
[12:12] guido_g nothing
[12:12] raz which is apparently on the case
[12:13] raz s/on/not/
[12:14] guido_g there is no guarantee for delivery in ømq
[12:15] raz hmm
[12:37] ajsie zeromq doesnt support persistence?
[13:15] guido_g it can store messages, but that's not what you know from broker based solutions
[13:32] keffo mm, nice.. code dated 3/11/78
[13:37] vanadium If I have one push sockets sending workloads to a number of threads with pull sockets, the work will be evenly distributed over all threads even if some of them take way longer per workload, right?
[13:37] vanadium It is just a round-robin thing and not actually communicating back who is ready for more work or anything?
[13:50] drbobbeaty vanadium: I've not used the PUSH/PULL sockets before, but I believe that you are correct in your assumption. You have a single socket (PUSH) that's bound to some URL, and a series of "worker threads" that each has a socket (PULL) that's connected to that same URL. Then, as the single "producer" socket sends out messages, they are picked up and worked on, in turn, by the worker threads.
[13:51] drbobbeaty As i understand it, there are several ways to handle the distribution - round-robin, least-recently-used, etc., but I'm not as familiar with those concepts or how to set them up.
[13:51] vanadium Thank you
[13:51] drbobbeaty no problem
[14:03] guido_g re
[14:13] raz has anyone used zmq with ruby eventmachine?
[14:13] raz does it blend?
[14:17] cremes raz: the 2.0.x branch doesn't blend well with EM; the 2.1.x branch *might*
[14:17] cremes in the meantime, check out
[14:18] raz well, i have an existing em app that i'd like to add zmq to
[14:18] raz zmqmachine looks like it's meant to be a replacement for em
[14:18] cremes right
[14:19] cremes you'd have to wire the 0mq sockets into the EM reactor loop
[14:19] cremes that isn't possible with any 0mq release right now
[14:19] raz hrm
[14:19] cremes the 2.1.x branch has a few new file descriptor elements exposed which will make it feasible to do so
[14:19] raz any dirty trick possible with a thread or so?
[14:19] cremes of course, but that's cheating :)
[14:19] raz hehe
[14:20] raz i don't need it super pretty or fast, but super reliable would be nice ;)
[14:21] raz sadly my eventmachine fu isn't all that advanced, not sure if i'd get the dispatching between eventmachine and a separate thread right
[14:21] cremes you would need to run the 0mq stuff in a thread separate from EM and any interaction would need to be scheduled via EM.schedule
[14:21] cremes 0mq -> EM would be via EM.schedule
[14:21] cremes EM -> 0mq could be handled straight up
[14:22] raz except when the 0mq call blocks (in the latter case)
[14:22] raz guess i should use a queue both ways
[14:22] cremes raz: you'd have to pass ZM_NOBLOCK to all send/recv calls
[14:22] raz hmm
[14:23] cremes you could maybe run zmqmachine and EM in parallel; all of that NO_BLOCK stuff is handled for you then
[14:23] raz sounds like that may be worth a shot
[14:23] cremes let us know how it turns out
[17:49] mankins hi--i've got an installation problem with 2.0.9 under linux. configure: error: cannot link with -luuid, install uuid-dev.
[17:49] mankins only I've already got uuid-devel installed (under fedora core 8 on ec2)
[17:50] mankins is at /lib ... not sure where to go next. Does this ring any bells?
[20:29] CIA-20 jzmq: 03Stefan Majer 07master * rf3aa751 10/ (jzmq.spec pom.xml): RPM Packaging and Mavenized, first step. -
[21:07] cremes i'm wondering if anyone has seen an assertion failure in 2.0.9
[21:07] cremes Assertion failed: !engine (session.cpp:287)
[21:07] cremes i'm hitting that a lot but i can't figure out why; i'm having a hard time reducing the code to a small example
[21:11] pieterh cremes: that's a reported issue afair
[21:12] pieterh it's caused by... /me vaguely recalls... identity crisis
[21:12] cremes ah... 2+ sockets with same identity...?
[21:12] pieterh yeah
[21:12] pieterh evil twin syndrome
[21:12] cremes cool, then i know where *my* bug is.... :)
[21:13] pieterh issue 30
[21:13] pieterh hey chuck, Chicago *rocks* :-)
[21:13] cremes i'm glad you had a good time... may i assume the trip was worthwhile from both a pleasure *and* business perspective?
[21:14] cremes heh
[21:15] pieterh 0mq + chicago = boom!
[21:15] cremes good boom or bad boom? ;)
[21:15] pieterh the good kind :-)
[21:15] cremes great... next time you come out bring the team
[21:16] cremes oops, gotta run; catch ya later!
[21:17] pieterh cyl
[21:21] mato pieterh: yo
[21:21] mato pieterh: just got back from dinner, etc with sustrik
[21:21] mato pieterh: linux-kongress starts tomorrow, martin is speaking around 5pm
[21:24] pieterh hey mato :-)
[21:24] pieterh how's nurnberg?
[21:24] mato nice
[21:24] mato good beer
[21:24] mato some kind of local beer fest is on
[21:24] pieterh in germany? lol...
[21:25] pieterh there's some kind of wine festival in bratislava next weekend
[21:25] pieterh hey, mato, random question about messages
[21:26] pieterh i vaguely recall El Sustrik saying that zmq_send nullifies the message it sends
[21:26] pieterh even insisting this should be clearly explained in the guide
[21:26] mato zmq_recv does
[21:26] mato send doesn't afaik
[21:26] pieterh ? recv nullifies the message?
[21:27] pieterh ah, before receiving, previous contents are discarded...
[21:28] pieterh mato: nah, it was send
[21:28] pieterh i found the line in the userguide:
[21:28] pieterh **Note than when you have passed a message to zmq_send[3], 0MQ will clear the message, i.e. set the data to empty. You cannot send the same message twice, and you cannot access the message data after sending it.**
[21:28] pieterh yet this is wrong
[21:29] pieterh could you bounce this off Sustrik?
[21:30] mato that's wrong
[21:30] mato of course you can send a message multiple times
[21:30] mato i do it all the time
[21:30] starkdg i thought zmq_msg_close() is what kills messages ?
[21:30] mato yes, precisely
[21:30] mato recv is special in that it destroys the content of the message being received into (if any)
[21:30] mato which makes sense
[21:30] mato send does not touch it
[21:30] pieterh mato: that all makes sense
[21:31] pieterh yet I wrote that after sustrik explicitly asked me to emphasize that
[21:31] pieterh maybe he meant recv not send...
[21:31] pieterh or i noted it wrong
[21:31] mato probably
[21:31] pieterh send is 100% safe?
[21:31] mato it's quite obviously wrong, i have lots of code that sends the same msg_t X times
[21:32] pieterh kurwa
[21:32] pieterh ok, thanks...
[21:32] mato :-)
[21:32] starkdg you can recieve and send the same message, right ? ive been doing that
[21:33] mato yes