ZeroMq IRC Log

Tuesday April 5, 2011

[Time] Name	Message
[03:36] realz	lol turns out 0mq also uses netstrings for messages :D
[05:24] sustrik	michaelgreene_: hi
[05:24] sustrik	if you are seeing socket beeing blocked when it should not be
[05:24] sustrik	strip down the test case to its minimal version
[05:24] sustrik	and report it either on the mailing list or in bug tracker
[05:24] sustrik	you can try to debug it yourself using gdb as well
[05:24] sustrik	as for {r=26,w=27}, that's a socket pair, the fds
[06:39] mikko	pieterh: 2-1 and 2-2 broken on win atm
[09:11] sustrik	Guthur: btw, the NovaSparks you've mentioned
[09:12] Guthur	sustrik__: yep
[09:12] sustrik	the author of common lisp 0mq bindings is working for them
[09:12] Guthur	ah, yes he did ask if I knew him
[09:12] Guthur	he was actually quite interested in 0MQ
[09:13] pouete	Hi all !
[09:13] sustrik	morning
[09:13] Guthur	I unfortunately had to rush off at the time and didn't get a proper chance to talk to him
[09:13] Guthur	I need to improve my networking skills
[09:13] sustrik	yes, i met him once as he lives quite close to here
[09:14] sustrik	i think they are either using or considering 0mq use
[09:15] Guthur	They are considering it afaia
[09:16] Guthur	they offer a number of interconnect strategies
[09:17] Guthur	it's cool tech, I hope they are successful
[09:18] Guthur	Programming hardware with with CommonLisp is pretty neat, by the looks of VHDL i can see the motivation as well
[09:18] sustrik	:)
[09:18] Guthur	it's also very easy to make DSLs with CL which then helps at the customer end of the abstraction, win win
[09:44] Guthur	sustrik__: What in your opinion is the biggest win of having zeromq in the kernel?
[09:56] jsimmons	more people developing it :D
[09:57] sustrik	:)
[09:57] sustrik	well, it logically belongs there
[09:57] sustrik	doing it in user space means spending half of the development effort
[09:58] sustrik	trying to find workarounds around not being in the kernel
[09:58] sustrik	and from business perspective, getting into mainline linux kernel means immense deployment base
[10:07] Guthur	so more logistical wins as opposed to any performance benefits
[10:10] sustrik	kind of
[10:10] sustrik	and obviosuly, saner API is a big win
[10:10] sustrik	for example, 0mq socket would a file descriptor
[10:10] sustrik	no need for zmq_init and zmq_term
[10:10] sustrik	and no associated waiting on zmq_term to send pending messages
[10:10] sustrik	etc.
[10:23] pouete	I have a question : ihave ubuntu 10.10 using the Ã¸MQ library, i am doing this : http://pastebin.com/gLEx8yAN and, when i am importing from python ( import zmq) i get this error : http://pastebin.com/pUsimgPv . could it be a version missmatch ?
[10:23] pouete	and how can i solve this problem ?
[10:31] Guthur	pouete: personally, I think for sanity sake it is better to download the source for 0MQ directly, compile and install
[10:31] Guthur	YMMV though
[10:31] sustrik	looks like some old 2.0.x version
[10:32] pouete	sustrik__: indeed, the test suite tell me that i have ZMQ version detected: 2.0.6
[10:32] pouete	so, have to uninstall it first i suppose
[10:32] sustrik	getsockopt was introduced in 2.0.7 iirc
[10:36] pouete	A! seems better, aptitude didnt purged all the files
[10:37] pouete	sorry : i didnt asked aptitude to purge all files :)
[10:43] pouete	ERROR: test messages from memoryview (only valid for python >= 2.7) < i have this error and python == 2.6.6, do i have to considere this as a real error (install python => 2.7) or a minor feature i dont need (keep my python version )?
[11:41] private_meta	hmm... dammit, need to rewrite the majordomo protocol for me alredy
[11:41] private_meta	*already
[11:42] Guthur	private_meta: you need to add to the spec?
[11:42] private_meta	no
[11:42] private_meta	well
[11:43] private_meta	I need client-to-broker heartbeats
[11:43] private_meta	that ain't possible in the current design
[11:43] private_meta	not like that
[11:46] Guthur	private_meta: not sure why you need that
[11:47] private_meta	I just need it
[11:47] Guthur	a client is strictly synchronous, so you could feasibly just timeout on any request
[11:47] Guthur	no need for heartbeat
[11:47] private_meta	no, it's async for me
[11:47] Guthur	well then you have already left the spec
[11:48] Guthur	you could maybe have the client as a worker as well
[11:48] Guthur	or some such
[11:49] private_meta	in a way that would be a nice idea
[11:49] private_meta	that way I'd just have to implement worker-to-worker comm
[11:50] Guthur	as long as the workers, brokers and clients full fill their contract per the spec I think you can get away with any connection pattern
[11:51] private_meta	Well, I'd still have to change the spec in the way that the Client address would be the service name
[11:53] private_meta	but that would be a less major change in the protocol
[11:53] private_meta	hmm... it'd still change the implementation to some extent, gotta look into that
[11:54] Guthur	afaics there is nothing in the spec that says a client can not use an explicit address
[11:55] Guthur	though you would not fullful the "Clients SHOULD use a REQ socket "
[11:55] Guthur	unless you use two sockets
[11:55] Guthur	at the client/worker end
[11:56] Guthur	actually the only way you could full fill the two connection contracts is by using two sockets
[11:56] Guthur	imo
[12:55] ASY	ZMQ sockets are connected in nature, which basically means that you can not do any type of auto-discovery on the network. I use UDP broadcasts to identify nodes on the network. I have to continue using UDP and then use ZMQ only when UDP broadcaster has located something. Am I correct about all of this?
[12:56] guido_g	pub/sub over (e)pgm would do
[12:58] ASY	ok, I have to look at PGM then. Thanks.
[13:35] jmslagle	Morning peeps :)
[13:35] jmslagle	Is the on the wire protocol documented anywhere?
[13:36] jmslagle	Ooh I found it
[15:32] drbobbeaty	sustrik: you around? I have an issue that popped up with ZMQ 2.1.4 and I wanted to see if you had any ideas on it.
[15:34] drbobbeaty	If anyone can help, the problem is detailed here: https://gist.github.com/903836 and it's basically, that in encoder_t::message_ready() the function zmq_msg_size() is called and it seg faults.
[15:34] drbobbeaty	I wonder if you have any ideas...
[15:36] guido_g	bad logic, getting the size of a closed message
[15:38] drbobbeaty	So is there anything I can do short of patching the zmq_msg_size() method and then submitting that?
[15:39] guido_g	what?
[15:39] guido_g	when you're closing the message it's gone
[15:40] drbobbeaty	My code makes a zmq::message_t, and sends it out the socket. I'm assuming (maybe incorrectly) that the send() method copies the provided message so that it's available for sending when the socket gets around to it.
[15:40] drbobbeaty	So I'm not purposefully closing it (in C++).
[15:40] guido_g	you're simply plain wrong
[15:41] drbobbeaty	I'm sorry.
[15:42] drbobbeaty	Let me double-check the Guide, but I'm pretty sure I'm using code right out of there for this...
[15:42] guido_g	the code in the paste is wrong, no matter where it came from
[15:43] drbobbeaty	You mean the code in the gist I posted?
[15:43] guido_g	what else?
[15:43] guido_g	i can't see your code from here
[15:43] drbobbeaty	Sorry for being dense here, but I just want to make sure.
[15:43] drbobbeaty	The code in the gist is from the 2.1.4 tarball.
[15:44] drbobbeaty	If it's wrong, then it's in that tarball that it's wrong.
[15:44] guido_g	might be
[15:45] drbobbeaty	If it's a new bug, then I'd be glad to patch the zmq_msg_size() to check the msg->context for NULL before the size check.
[15:45] drbobbeaty	Or is there another error you see?
[15:46] guido_g	the message is closed unconditionally and then the size is requested
[15:46] guido_g	looks like a bigger issue
[15:47] guido_g	but i'm not well versed in the core
[15:47] drbobbeaty	I see - in the encoder... the message is destroyed, and then possibly init-ed again.
[15:48] Seta00	yeah but line 68 is only reached when the message is closed
[15:48] guido_g	which sounds wrong
[15:48] drbobbeaty	I'll send it to the mailing list and see see what Sustrik thinks... it does seem a little odd.
[15:48] guido_g	ack
[15:49] Seta00	but I agree zmq_msg_size should assert the context
[15:49] guido_g	the code doesn't make sense
[15:49] Seta00	I know
[15:49] guido_g	at least w/o digging deeper
[15:50] Seta00	but still, segfaulting on a fairly common case like that is Bad.
[15:50] guido_g	why is the message closed and accessed again afterwards?
[15:51] drbobbeaty	I'm trying to put it all in a nice email to the list. All good points...
[15:52] guido_g	good idea
[15:54] ianbarber	pretty sure it doesn't copy when sending, else the zero copy method would be dubious.
[15:57] Seta00	yes, I remember having problems deleting the message right after sending it
[15:57] guido_g	you shouldn't do that, see send man page
[16:27] mikko	pieterh: MSVC issues with 2-1 and 2-2
[16:27] mikko	builds: libzmq2-1_MSVC-win7 and libzmq2-2_MSVC-win7
[18:13] so_solid_moo	hrm, has anyone seen this error before: usr/include/zmq.h:246:16: note: expected âstruct zmq_pollitem_t â but argument is of type âstruct zmq_pollitem_t â
[18:13] so_solid_moo	:S
[18:28] mikko	so_solid_moo: looks odd
[18:28] so_solid_moo	yeah :(
[21:04] geck	so, I've been playing with the perl bindings and the 100-basic.t unit test is giving an erro about the default ZMQ_RATE value not being 100
[21:04] geck	upon further checking, the value is actually 40000
[21:04] geck	is this a case of a the test not being updated, or an indication of a more serious problem?
[21:05] geck	steps to reproduce: `cpan ZeroMQ` after installing 2.1.14
[21:06] guido_g	the value has been changed lately
[21:07] geck	file issue on github? or is that handled via rt.cpan.org?
[21:07] stutter	if i have a push server set up, and 2 pull clients connected to it...is there any way to build my app so that i can start a 3rd pull client and immediately alleviate load from the existing pull clients? (take over messages that have been sent on the push server, but not processed on the pull clients yet)
[21:08] guido_g	stutter: this is the default behaviour
[21:08] guido_g	the push will start sending messages to the 3rd client as soon it has connected itself
[21:08] stutter	yeah, just wondering if i could tweak it to start doing work immediatley
[21:09] stutter	new messages only, nothing in the queue gets re-routed
[21:09] guido_g	true