ZeroMq IRC Log

Wednesday September 22, 2010

[Time] Name	Message
[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	http://api.zeromq.org/zmq_socket.html
[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 http://github.com/chuckremes/zmqmachine
[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	libuuid.so.1 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. - http://bit.ly/a6fxhX
[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