Tuesday July 27, 2010

[Time] NameMessage
[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 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