ZeroMq IRC Log

Tuesday December 7, 2010

[Time] Name	Message
[08:08] the_hulk	hi, for C API's on server side, i do not have to fork? it seems to be taken care of?
[08:08] Steve-o	fork to do what?
[08:12] the_hulk	fork to handle multiple clients, as we do with normal sockets fds
[08:12] Steve-o	and thread pooling, etc, ok
[08:14] Steve-o	It's covered pretty well in the guide, http://zguide.zeromq.org/chapter:all
[08:19] the_hulk	ohk
[10:10] CIA-20	zeromq2: 03Martin Lucina 07master * r9bb5323 10/ doc/zmq_socket.txt :
[10:10] CIA-20	zeromq2: Clarify zmq_send() operation for ZMQ_PUB sockets
[10:10] CIA-20	zeromq2: Signed-off-by: Martin Lucina <mato@kotelna.sk> - http://bit.ly/eNDyqm
[10:16] CIA-20	zeromq2: 03Mikko Koppanen 07master * raed2eea 10/ (acinclude.m4 configure.in):
[10:16] CIA-20	zeromq2: Fix visibility on rhel4
[10:16] CIA-20	zeromq2: Signed-off-by: Mikko Koppanen <mkoppanen@php.net> - http://bit.ly/hue9Av
[10:16] CIA-20	zeromq2: 03Mikko Koppanen 07master * ra335315 10/ acinclude.m4 :
[10:16] CIA-20	zeromq2: Fix werror flag store/restore
[10:16] CIA-20	zeromq2: Signed-off-by: Mikko Koppanen <mkoppanen@php.net> - http://bit.ly/idiJwf
[10:16] CIA-20	zeromq2: 03Mikko Koppanen 07master * r1d81d2f 10/ configure.in :
[10:16] CIA-20	zeromq2: tar doesn't accept -C flag on solaris while extracting
[10:16] CIA-20	zeromq2: Signed-off-by: Mikko Koppanen <mkoppanen@php.net> - http://bit.ly/hrR0E7
[12:04] ptrb	just to confirm -- no problem making multiple connect() calls on a single ZMQ_SUB socket, right?
[12:34] drbobbeaty	ptrb: correct. You can have multiple connect() calls to one ZMQ_SUB socket.
[12:35] drbobbeaty	In order to "tear down" the socket, you have to drop/close the socket. Meaning, you can't disconnect() just one of the connections - you have to take them all down.
[12:38] Steve-o	unbind/disconnect was discussed previously: http://thread.gmane.org/gmane.network.zeromq.devel/4369
[12:47] ptrb	cool. thanks.
[14:43] sustrik	drbobbeaty: hi
[14:43] drbobbeaty	sustrik: hi... I sent in the patch to the ML.
[14:44] sustrik	yes, just got it
[14:44] sustrik	a minor point
[14:44] sustrik	subscribe to the mailing list
[14:44] sustrik	otherwise the messages are blocked
[14:44] sustrik	and i have to approve them by hand
[14:45] sustrik	if you don't want to get the traffic, you can switch that off
[14:45] sustrik	but still be member of the list
[14:45] drbobbeaty	Funny thing, I am subscribed, and I still keep getting blocked. Pieter talked to me about that, and we walked through it together. Very puzzling.
[14:45] sustrik	hm, let me see
[14:45] drbobbeaty	Please do... I'd love to not bother you guys.
[14:46] sustrik	hm, i don't see you in the members list
[14:46] sustrik	any idea what email address you have used to subscribe?
[14:46] drbobbeaty	drbob@TheManFromSPUD.com
[14:47] drbobbeaty	That's what I use to "maintain" the ML on it's web site.
[14:47] sustrik	aha
[14:47] sustrik	but the emails you send are from a different address
[14:47] drbobbeaty	OH! Duh.
[14:47] sustrik	comcast
[14:47] drbobbeaty	That's it... outgoing != incoming. I'll change that.
[14:47] sustrik	great
[14:47] drbobbeaty	Thanks for the pointer.
[14:48] sustrik	i'll have a look at your patch shortly
[14:48] drbobbeaty	I hope it's clean and easy. And adheres to the buidelines.
[14:51] sustrik	one thing i am not sure of: is it possible that someone would want recovery ivl of zero?
[14:51] sustrik	unreliable multicast...
[14:51] sustrik	i am not even sure it's possible with OpenPGM
[14:51] sustrik	if so, the default should be -1 rather than 0
[14:52] sustrik	let me ask steven
[15:17] toni	hi there. I am using a REQ socket doing socket.recv(zmq.NOBLOCK), but I am getting a "ZMQError: Resource temporarily unavailable" (using the python binding). As I saw in the docs for recv and zmq.NONBLOCK, there is this little sentence:"If there are no messages available on the specified socket, the zmq_recv() function shall fail with errno set to EAGAIN." I dont really understand. So the NOBLOCK option raises an error in case no messag
[15:20] cremes	toni_: you see that "resource unavailable" message when your REQ socket is not connected to any REP (or XREP) sockets
[15:20] cremes	make sure you have a z-endpoint
[15:21] cremes	with an active socket attached to it
[15:21] toni	cremes: but it should as it all works fine since I dont specify the NOBLOCk option @ recv()
[15:22] toni	maybe its not connected yet?
[15:28] Guthur	Should the timeout work with subscriber nodes?
[15:28] Guthur	with polling
[15:29] Guthur	It works fine if I set -1, but seems to not pickup messages when a timeout value is set
[15:31] toni	cremes: okay, very strange.... the error disapears when I dont do zmq.NOBLOCK in s.recv(). When I specify the option, the error is raised. But why? The socket should be connected, as the error is not raised when no block is not specified
[15:43] cremes	toni_: interesting... it's funny but i only ever do noblock send/recv so i don't understand what is happening in the blocking scenario
[15:44] cremes	are you certain that the other socket has connected?
[15:44] toni	cremes: yes I am really certain. But I found the solution describes here https://github.com/zeromq/pyzmq/issues/36#issue/36
[15:47] cremes	toni_: hmmm, ok
[16:23] mikko	mato: looks like solaris10 is still not happy
[16:24] mato	mikko: it used to be, has your visibility change broken something?
[16:24] mikko	mato: http://build.valokuva.org/job/ZeroMQ2-core-master-SunStudio-solaris10/21/console
[16:24] mikko	when building --with-pgm
[16:25] mato	mikko: ah, ok, i'll look at it later, in the middle of dissecting the linux network stack with sustrik right now
[16:25] mikko	tries to include <sys/epoll.h>
[16:26] mato	i guess openpgm in zmq has not been ported to solaris properly then
[16:28] mikko	will look into it tonight
[17:27] mikko	pfffff
[18:04] toni	I am using the python binding, having a REQ socket connected to a XREP socket. When I try to send from the REQ socket I get "zmq.core.error.ZMQError: Operation cannot be accomplished in current state". Any ideas?
[18:06] cremes	toni_: yes, req/rep sockets enforce a strict 1 send / 1 recv model; trying to do 2 sends or 2 recvs in a row generates a state machine error
[18:06] cremes	look at the docs for req/rep
[18:12] drbobbeaty	sustrik: my patch has a problem with it... I need to send you an additional change for using sequence numbers with OpenPGM. My mistake. Sorry.
[18:12] toni	cremes: Thanks, thats the code snippet: https://gist.github.com/732161 the "aaaa". See the link for the traceback
[18:13] drbobbeaty	sustrik: maybe it's not a problem... I'll send the details to the mailing list and you can decide.
[18:13] cremes	toni_: your problem is at line 40
[18:14] cremes	you need a recv in that block
[18:14] cremes	again, read the docs on req/rep
[18:14] cremes	you must do alternating send/recv with each one
[18:14] cremes	you cannot just send with either socket; there must always be a matching recv
[18:14] cremes	the pattern is request/reply, not request/request/request/request/reply
[18:14] cremes	:)
[18:19] toni	cremes: thanks
[18:20] cremes	toni_: you are welcome... be sure to check out the guide on the web site; it covers that topic
[18:21] cremes	andrewvc: planning to do another ffi-rzmq and zmqmachine release after 2.1 is out of beta
[18:21] andrewvc	nice!
[18:21] cremes	if you have anything you'd like to be in there, that's our deadline ;)
[18:22] toni	cremes: I already read it, I also constructed the very last example in python. I just had some truble with the NOBLOCK option and tried to debug from scretch. Maybe its enough for today, after 10 hours of coding :-)
[18:22] andrewvc	well, I was hoping to hack on it sometime soon, but I'm moving this weekend
[18:22] andrewvc	I've had about zero free time the last couple weeks
[18:22] andrewvc	unfortunately
[18:22] cremes	toni_: np; we'll be here in channel next time you need help... take a break
[18:22] cremes	andrewvc: yeah, real life is constantly getting in the way!
[18:23] andrewvc	lol, so true
[18:23] andrewvc	i'm actually going to la.rb hack night tonight, was hoping to get a little EM work there
[18:23] cremes	cool... see if you can't recruit a few more 0mq hackers
[18:24] andrewvc	hehe, I'm trying it's so fun to play with.
[18:24] andrewvc	evanphx is usually there btw, I know you worked pretty closely with him on some ffi bugs right?
[18:25] cremes	andrewvc: yeah, i did; the api drift between the rbx ffi support and the ffi gem caused him a lot of grief
[18:25] cremes	he was pretty upset about many of the additions
[18:25] andrewvc	hehe, yeah we had a similar conversation
[18:25] cremes	i use 0mq with rbx daily; it's the best way to profile and debug my code these days
[18:26] andrewvc	agreed, best stack trace for issues
[18:26] cremes	yep, that too
[18:26] cremes	it's quickly becoming my ruby of choice
[18:26] andrewvc	I've wanted to test my employers code on rbx, but hpricot's sitting in the way
[18:26] cremes	as soon as it gets windows support i'll use it there too
[18:26] cremes	C extension issues?
[18:27] andrewvc	yep, and I think it's one that no one's planning on fixing
[18:27] cremes	direct RHASH access or something nutty?
[18:28] andrewvc	oh, well look what google turned up https://github.com/rubinius/hpricot
[18:28] andrewvc	someone did fix it lol
[18:29] cremes	ha!
[18:29] cremes	no more excuses, andrewvc !
[18:29] andrewvc	hehe
[18:29] andrewvc	nope, well, one more, engineyard doesn't officially support rbx, but that's a minor hurdle
[18:29] cremes	really? well, that's got to change sometime soon
[18:29] cremes	it's all ey guys working on it!
[18:29] andrewvc	yeah, weird eh?
[18:30] cremes	oh, i know why... they are having trouble creating an ebuild recipe for it under gentoo
[18:30] andrewvc	the default choices are only 1.8.7, REE and 1.8.6
[18:30] cremes	i saw whyaines chatting about it with evan recently
[18:30] cremes	no jruby even?
[18:30] andrewvc	no
[18:30] cremes	now i'm shocked
[18:30] andrewvc	but the reality of EY is that everyone uses chef and customizes everything
[18:31] andrewvc	EY is more a starting point than a destination
[18:31] cremes	hmmmmm
[18:31] andrewvc	not like heroku at all, we have so many changes to the stack
[19:11] raspi	where i could find config examples for zmq_(queue\|forwarder\|streamer). manual gives only TBA.
[19:50] mikko	raspi: i think in the code at the moment
[19:50] mikko	raspi: i don't think there are written examples anywhere
[19:51] raspi	ok :)
[19:51] mikko	if you look at devices/zmq_queue/ in the source
[19:51] mikko	the schema should be fairly easy to deduct from the code
[20:58] toni	I have a REQ client connected to 2 XREP server. When one server dies, the socket.recv() on the client blocks for ever. The other server is still available, but doesnt get any requests. How can I prevent this starvation?
[20:59] toni	I also tried to use a nonblocking XREQ socket on the client and ran in the same issue
[21:04] mikko	it blocks even if you pass ZMQ_NOBLOCK?
[21:06] toni	I thought the XREQ socket would be nonblocking?
[21:07] mikko	it has unrestricted send/receive pattern but it's no non-blocking by default as far as i know
[21:07] mikko	have you tried passing ZMQ_NOBLOCK to recv and checking for EAGAIN ?
[21:09] mikko	you can also look at zmq_poll
[21:09] toni	mikko yes I did. I found the snippet at the pyzmq issues
[21:11] toni	mikko: thanks, I think I found my bug
[21:12] mikko	np