ZeroMq IRC Log

Tuesday September 13, 2011

[Time] Name	Message
[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: http://php.zero.mq/zmqsocket.recv.html
[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	http://pastebin.com/kRCbaS9T 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: http://pastebin.com/kRCbaS9T)
[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: https://zeromq.jira.com/browse/LIBZMQ-253
[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/ZMQ.java : Add correct checks for version number ...
[12:55] CIA-121	jzmq: 03Gonzalo Diethelm 07master * r6da1142 10/ (.gitignore src/Socket.cpp src/org/zeromq/ZMQ.java): Merge pull request #72 from jhawk28/master ...
[12:55] CIA-121	jzmq: 03Joshua Foster 07master * r15a0a86 10/ (.gitignore src/Socket.cpp src/org/zeromq/ZMQ.java): 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/Makefile.am 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: http://www.zeromq.org/topics: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"

ZeroMq Home

Tuesday September 13, 2011