ZeroMq IRC Log

Tuesday July 27, 2010

[Time] Name	Message
[03:53] grahamalot	Could someone tell me how to do the following: " zmq::device (ZMQ_QUEUE, clients, workers); " (C++) in python? I can't seem to find out how to create this "device".
[04:01] guido_g	good question
[04:01] guido_g	seems like a case where asking on the mailing list would be a good idea
[04:01] grahamalot	I think i might have figured it out zmq.bind should work, but i'm not 100 percent yet, thanks, i'll check with the mailing list.
[10:19] mikko	sustrik_: there?
[10:19] mikko	no, wait nevermind :)
[10:19] mikko	figured it out
[10:20] mikko	A socket of type ZMQ_UPSTREAM is used by a pipeline node to receive messages from upstream pipeline nodes.
[10:20] mikko	is that a bit confusing?
[10:25] sustrik	mikko: hi
[10:26] sustrik	mikko: just being discussed on the mailing list
[10:26] sustrik	"Why ZeroMQ" thread
[10:26] sustrik	feel free to express your opinion there
[13:18] lvh	Hey.
[13:18] lvh	Could anyone explain how a Device (eg a zmq_forwarder) is fundamentally different from a broker?
[13:18] lvh	Thanks.
[13:24] sustrik	lvh: it is not
[13:24] sustrik	it's a broker stripped to bare bones
[13:24] lvh	Oh, okay.
[13:24] lvh	Yay, I understood something :-)
[13:26] sustrik	:)
[13:27] lvh	sustrik: Oh by the way I tried to get back to you on the twisted support thing
[13:27] lvh	sustrik: Remember how you were talking about exposing an fd to integrate with other event loops better?
[13:27] lvh	At least that's what I remember
[13:27] lvh	basically, we want that, the other alternative is reimplementing everything in Python which I don't want to do
[13:27] lvh	(and you don't want to see happen either most likely)
[13:28] sjampoo	seriously, 57 messages about how to name a friggin socket and no end in sight.
[13:29] lvh	teehee
[13:29] sustrik	bikeshed syndrome
[13:30] sustrik	"Parkinson dramatizes his Law of Triviality with a committee's deliberations on a nuclear power plant, contrasting it to deliberation on a bicycle shed. A nuclear reactor is used because it is so vastly expensive and complicated that an average person cannot understand it, so they assume that those working on it understand it. Even those with strong opinions often withhold them for fear of being shown to be insufficiently informed. On the o
[13:30] sustrik	ther hand, everyone understands a bicycle shed (or thinks he or she does), so building one can result in endless discussions because everyone involved wants to add his or her touch and show that they have contributed. While discussing the bikeshed, debate emerges over whether the best choice of roofing is aluminium, asbestos, or galvanized iron, rather than whether the shed is a good idea or not."
[13:31] sjampoo	sustrik, yah I've heard about it :)
[13:31] sjampoo	You see it in meetings as well.
[13:31] sjampoo	Thats why it helps to overcomplicate things sometimes if you want them just to accept your point
[13:32] sustrik	ha
[13:32] sustrik	survive in corporate environment 101 :)
[13:32] sjampoo	haha
[13:34] drbobbeaty	Question: I've noticed that the zmq::socket_t has a connect() method but no disconnect() method. I can connect() to several URLs (addresses/ports) and all is great, but what if I want to disconnect from just one?
[13:34] sustrik	close the socket
[13:34] sustrik	same as with BSD sockets
[13:35] drbobbeaty	But that closes all of the connections... I had expected this as the reason, but just wanted to see if it were possible to close just one. Guess not. I'll get over it.
[13:36] sustrik	sorry, that's the case
[13:36] drbobbeaty	Good enough. Just wanted to check.
[14:32] lvh	sustrik: Have you seen http://dank.qemfd.net/dankwiki/index.php/Libtorque? It appears to be a generalization of zmq's io bits.
[14:35] sustrik	lvh: looking at it
[14:35] sustrik	what do you mean by "io bits"?
[14:37] lvh	sustrik: I would suppose that would be the stuff done in IO threads that isn't ZMQ Socket specific. It's not a perfect congruence, I'm sure.
[14:58] sustrik	ah, you meant using it in 0MQ?
[14:58] sustrik	the existing implementation is as low-level and as optimised as possible
[14:59] sustrik	using a foreign library can at best keep the performance at its current state, but presumably it would degrade it
[15:17] lvh	Fair point
[19:32] tupshin1	is there a good way to have multiple workers process requests but prevent the clients from blocking by sending message to a down (or overloaded) worker?
[19:32] tupshin1	right now I have two processes separately doing
[19:32] tupshin1	$server->bind("ipc:///tmp/foo1"); and
[19:32] tupshin1	$server->bind("ipc:///tmp/foo2");
[19:32] tupshin1	and clients all doing
[19:32] tupshin1	ZMQ.Socket s = ctx.socket(ZMQ.REQ);
[19:32] tupshin1	s.connect("ipc:///tmp/foo1");
[19:32] tupshin1	s.connect("ipc:///tmp/foo2");
[19:32] tupshin1	s.send (msg, 0);
[19:32] tupshin1	s.receive(0);
[19:39] sustrik	what's that good for?
[19:40] sustrik	two identical connections between two components
[19:41] tupshin1	three components. the two bind lines are from two different worker processes
[19:42] tupshin1	and it works to balance requests between those workers. but if a worker were to die, sending would block
[19:48] tupshin1	it looks like running zmq_queue might do what I want, but is not documented