Sunday March 20, 2011

[Time] NameMessage
[03:30] jsimmons is there any way to mitigate the performance loss of (i'm presuming to blame zeromq here) adding more endpoints to a zmq socket?
[03:31] jsimmons I presume it's the push/pull pair rather than the pub/sub pair
[03:35] jsimmons that's actually a bad way to put it, rephrasing. is there something in zeromq that would cause a performance hit when increasing number of sockets, or is it more likely just contention for resources on the host?
[04:37] bth hi
[04:37] bth
[04:38] bth im a hacker :P
[04:38] bth
[04:38] bth
[04:38] bth
[09:01] pieterh sustrik: ping
[09:04] pieterh I'd like to clarify in zmq_socket(3) that PAIR is intended only for inproc sockets
[09:11] sustrik pieterh: morning
[09:11] pieterh hi :-)
[09:11] sustrik sure, do so
[09:11] pieterh I'll send you a patch to the man page
[09:11] sustrik ok
[09:12] pieterh I think this lets us close the issues on PAIR as "out of scope"
[09:12] sustrik let me see
[09:15] sustrik i don't think restricting it to inproc solves the issues
[09:15] sustrik 4,19 and 26 can happen with inproc
[09:15] sustrik as for 3, it cannot be demostrated because inproc itself lacks reconnect
[09:15] pieterh let me check again
[09:17] pieterh ok, 4 and 26 are proper bugs
[09:18] pieterh 19 seems fine, it asserts if you misuse it, which is fair
[09:18] pieterh 3 is out of scope, over inproc
[09:18] sustrik it will resurface once auto-reconnect over inproc is implemented (issue 6)
[09:19] pieterh yes, but we have a good pattern for using inproc without reconnect
[09:19] sustrik ack
[09:19] pieterh as long as there are guidelines that keep people away from trouble, it's fine for me
[09:19] sustrik yep, but leave the issues open
[09:19] pieterh indeed
[09:19] sustrik they have to be fixed anyway
[09:19] pieterh ok
[09:19] pieterh did you get a chance to look at that pubsub issue?
[09:20] pieterh it seems to kind of completely break multipart pubsub
[09:20] sustrik yes, i've tried several fixes already
[09:20] sustrik i'll have it ready today
[09:20] pieterh lovely... !
[10:42] sustrik pieterh: here's the patch:
[10:42] sustrik
[10:42] sustrik can you check whether it works ok?
[10:42] pieterh a'ight! testing now...
[10:49] pieterh sustrik: confirmed working
[10:49] sustrik thanks
[10:49] pieterh will you send me the commit when it's done?
[10:51] sustrik working on it
[10:52] pieterh I think we're ready for a 2.1 stable
[10:53] sustrik ok
[10:53] CIA-22 zeromq2: 03Martin Sustrik 07master * r92c7c18 10/ (src/dist.cpp src/dist.hpp): (log message trimmed)
[10:53] CIA-22 zeromq2: Message atomicity problem solved in PUB socket
[10:53] CIA-22 zeromq2: When new peer connects to a PUB socket while it is in the middle
[10:53] CIA-22 zeromq2: of sending of multi-part messages, it gets just the remaining
[10:53] CIA-22 zeromq2: part of the message, i.e. message atomicity is broken.
[10:53] CIA-22 zeromq2: This patch drops the tail part of the message and starts sending
[10:53] CIA-22 zeromq2: to the peer only when new message is started.
[10:54] sustrik here you go
[13:42] Guthur I'm looking to build a device that will accept client requests and send data to specific clients, the two options I see is too either do some custom routing with XREQ/XREP, or to have the client PUSH requests and bind on a PULL socket to receive data.
[13:43] Guthur option 2 seems the cleanest in my mind, but it would surely involve maintaining a lot of open sockets to service all connected clients
[13:44] Guthur Is there an option 3 anyone can think of
[13:47] nmmm hi quick question i seems not finding the answer
[13:48] nmmm is there a way to make timeout on recv()
[13:48] nmmm supose i connect() socket 3-4 times
[13:48] nmmm and suppose then one of the servers die
[13:49] Guthur nmmm, you can poll with a timeout
[13:49] nmmm then recv() will wait forever
[13:49] Guthur or you could do a noblock recv in a loop and timeout yourself
[13:49] nmmm i see, but is pool only option?
[13:50] nmmm loop - yes I can too.
[13:50] nmmm but there is no internal timeout ?
[13:50] Guthur not on recv no
[13:50] nmmm question 2 (but i did not study it that much, so could be obvious)
[13:51] nmmm in poll, i can get responce from several nodes,
[13:51] nmmm is it my responsibility if I need my request to be executed only from one node ?
[13:52] Guthur nmm you can either just pass in one pollitem or you can choose to ignore the rest if you recv something on one socket
[13:52] Guthur with an if else
[13:52] Guthur 2 secs I'll show an example
[13:53] nmmm ok
[13:53] nmmm ignore - i can not do. let say the operation is very "intencive" or cost money.
[13:53] nmmm or send email
[13:54] Guthur sorry I may have miss-understood
[13:55] Guthur did you mean you may want to ignore one of the connected nodes
[13:55] nmmm let say we have system that sends emails
[13:55] nmmm and i have thousend to be send
[13:56] nmmm i can pass them to workes, but I want nobody to receive email twice
[13:56] Guthur oh right, you need a device in the middle that will load balance between all the workers
[13:56] nmmm this is good example on what i need to do. (actually will send SMS)
[13:56] Guthur this is covered very early in the guide
[13:56] Guthur have you seen it
[13:57] nmmm yes I will check the devices, thanks
[13:57] nmmm btw, great job
[13:58] Guthur the praise needs to go to others not me, hehe
[13:58] Guthur I only maintain the clrzmq2 binding (C#)
[13:58] nmmm i have some project , works OK on 2 GB server, but Im thinking about scalling
[13:59] Guthur a device like this may do
[13:59] Guthur scroll to the bottom of that section to see a nice diagram
[14:00] Guthur the guide is full of nice 0MQ recipes
[14:00] nmmm thanks a lot
[14:01] Guthur you're welcome
[14:01] Guthur happy coding
[19:54] CIA-22 zeromq2: 03Martin Sustrik 07master * r1619b3d 10/ (src/lb.cpp src/lb.hpp):
[19:54] CIA-22 zeromq2: Message atomicity bug in load-balancer fixed
[19:54] CIA-22 zeromq2: If the peer getting the message have disconnected in the middle
[19:54] CIA-22 zeromq2: of multiplart message, the remaining part of the message went
[19:54] CIA-22 zeromq2: to a different peer. This patch fixes the issue.
[19:54] CIA-22 zeromq2: Signed-off-by: Martin Sustrik <> -