| [Time] Name | Message |
|
[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
|
http://tinyurl.com/4hggvuq
|
|
[04:38] bth
|
im a hacker :P
|
|
[04:38] bth
|
http://tinyurl.com/4hggvuq
|
|
[04:38] bth
|
http://tinyurl.com/4hggvuq
|
|
[04:38] bth
|
http://tinyurl.com/4hggvuq
|
|
[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
|
https://gist.github.com/878260
|
|
[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 http://zguide.zeromq.org/page:all#toc37
|
|
[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 <sustrik@250bpm.com> - http://bit.ly/eAhwVE
|
