[Time] Name | Message |
[00:09] Seta00
|
brianthelion, I'd suggest building from source with PGM disabled
|
[02:35] cremes
|
Seta00: are you still working on improving windows performance with native (instead of posix) calls?
|
[02:52] Seta00
|
cremes, I never worked on that..
|
[04:18] cremes
|
Seta00: sorry, my memory is faulty
|
[04:19] Seta00
|
heh
|
[05:28] michelp
|
anyone know what diagram tool was used to write the guide? i'm needing to draw some of these diagrams myself and i'd love to reuse whatever there is
|
[05:31] johnm1234
|
I don't know specifically but I use OmniGraffle for stuff like that and it looks similar.
|
[05:33] sustrik
|
michelp: ditaa
|
[06:01] michelp
|
sustrik, thanks!
|
[08:08] mikko
|
Seta00: ?
|
[08:57] Araq
|
hi, I built 2.1.7 from source and the example client server .c programs from the documentation simply hang. any ideas?
|
[09:01] mikko
|
Araq: which ones?
|
[09:01] Araq
|
http://zguide.zeromq.org/page:all#Ask-and-Ye-Shall-Receive
|
[09:02] mikko
|
are you running the client as well?
|
[09:02] Araq
|
yes
|
[09:03] Araq
|
the client sends hello but the server does not reply
|
[09:05] Araq
|
which means both hang in 'zmq_recv'
|
[09:05] mikko
|
have you got firewall setup?
|
[09:06] Araq
|
I guess ... (linux mint noob ;-) )
|
[09:07] Araq
|
but that shouldn't affect localhost port 5555, should it?
|
[09:13] mikko
|
i don't know
|
[09:13] mikko
|
depends on the firewall i guess
|
[09:19] jsimmons
|
there won't be any firewall rules by default
|
[09:22] Araq
|
jsimmons: true, I checked the docs
|
[09:23] jsimmons
|
have you made sure they're both pointing at the same place, ie server and client
|
[09:25] Araq
|
I just tried with "tcp://127.0.0.1:5412"
|
[09:25] Araq
|
same problem
|
[10:09] Araq
|
what's the difference between 'bind' and 'connect'?
|
[10:09] mikko
|
bind binds and connect connects
|
[10:09] mikko
|
hee hee heee
|
[10:10] mikko
|
Araq: bind binds to an endpoint and waits for connections
|
[10:10] mikko
|
Araq: connect connects to a bound endpoint
|
[10:11] Araq
|
so REP makes sense with bind
|
[10:11] Araq
|
and REQ with 'connect'
|
[10:11] mikko
|
not necessarily
|
[10:11] mikko
|
you can connect/bind any socket
|
[10:11] mikko
|
but in general it makes more sense to bind rep
|
[10:13] Araq
|
hm somehow it escapes me why socket() needs a mode and then I need to distinguish between connect and bind nevertheless afterwards ...
|
[10:14] mikko
|
Araq: the 'mode' you refer to is messaging pattern
|
[10:14] mikko
|
the patterns are independent from the transport
|
[10:22] Araq
|
yeah but there are combinations of patterns and transports which do not make sense
|
[10:22] mikko
|
such as ?
|
[10:23] Araq
|
REP and 'connect'
|
[10:23] mikko
|
well, it's hard to say that noone would have a use-case for that
|
[10:24] Araq
|
what's wrong with open/close send/retrieve as the basic API btw?
|
[10:24] mikko
|
you mean the bsd socket api?
|
[10:24] Araq
|
no I mean the API could be even easier to use I think
|
[10:24] Araq
|
zmq_msg_t seems to be completely unnecessary for example
|
[10:25] Araq
|
all you can do is init-send-close
|
[10:25] mikko
|
send what?
|
[10:25] Araq
|
or init-recv-close
|
[10:25] mikko
|
zmq_msg_t wraps the message object with reference counting
|
[10:25] Araq
|
why not send(char* msg, size_t len) ?
|
[10:26] Seta00
|
Araq, you probably want to take a look at czmq or zfl
|
[10:26] Araq
|
who needs to copy messages anyway if they can be used only once?
|
[10:26] mikko
|
Araq: there are wrappers that do it
|
[10:26] Araq
|
yeah, it's simple to wrap, I know
|
[10:26] Araq
|
just saying ... ;-)
|
[10:26] Seta00
|
http://czmq.zeromq.org/ and http://libzfl.zeromq.org/
|
[10:28] Araq
|
thanks for the links
|
[10:28] Araq
|
like I said, it's a non-issue really
|
[10:29] Araq
|
but maybe for 3.0 ;-)
|
[10:31] Araq
|
does zmq_msg_init_data() copy the data?
|
[10:31] Araq
|
or does it simpy store a pointer?
|
[10:33] jsimmons
|
http://man.cx/zmq_msg_init_data Araq
|
[10:35] Araq
|
"No copy of data shall be performed and 0MQ shall take ownership of the supplied buffer."
|
[10:35] Araq
|
how can it take ownership of the supplied buffer?
|
[10:35] Araq
|
if it does not copy?
|
[10:35] Araq
|
it can't assume I 'malloc'ed the buffer
|
[10:36] mikko
|
Araq: you give it a free function
|
[10:36] mikko
|
Araq: you can't really send data from stack
|
[10:36] Araq
|
oh ...
|
[10:36] mikko
|
Araq: the data is not necessarily sent immediately
|
[10:36] mikko
|
it might sit in a queue
|
[10:37] Araq
|
so if free function is NULL it uses 'free' ?
|
[10:37] mikko
|
and if you give it a pointer to stack you might have garbage when it's sent
|
[10:38] Araq
|
what if free function is NULL? what does it do then?
|
[10:38] mikko
|
if you use null no function is called iirc
|
[10:39] mikko
|
https://github.com/zeromq/zeromq2-1/blob/master/src/zmq.cpp#L151
|
[10:42] Araq
|
so zmq_msg_init_size() allocates a buffer for my that I can fill right?
|
[10:42] Araq
|
*for mee
|
[10:42] Seta00
|
yep
|
[10:42] Araq
|
and no free function issues right?
|
[10:42] mikko
|
yes
|
[10:42] Araq
|
alright, much better for my purposes
|
[10:43] Seta00
|
yes? I thought msg_close free'd the memory allocated in msg_init_site
|
[10:44] Seta00
|
size*
|
[10:44] Araq
|
Seta00: I think msg_close() does free the buffer
|
[10:45] Seta00
|
oh, I see what you meant
|
[10:47] sustrik
|
just use zmq_msg_init_size to create a message object and zmq_msg_close to destroy it and you should be ok
|
[10:47] sustrik
|
zmq_msg_init_data is for zero-copy and thus not relevant for most users
|
[10:47] Araq
|
yes I think so too after reading the code
|
[10:48] Seta00
|
so, has anyone made any progress on removing stdc++ dependency? I thought about giving it a shot this weekend
|
[10:48] Seta00
|
libstdc++*
|
[10:50] sustrik
|
Seto00: no, afaik
|
[10:50] sustrik
|
you'll have a bit of hard time with reimplementing STL containers though
|
[10:54] Araq
|
thank you for the help, bye
|
[10:56] mikko
|
heyo sustrik
|
[10:56] sustrik
|
hi mikko
|
[10:57] sustrik
|
any idea how to fix the jira problem?
|
[10:57] sustrik
|
should we just ignore it
|
[10:57] sustrik
|
?
|
[11:05] mikko
|
sustrik: i fixed the import locally
|
[11:05] mikko
|
and sent new version to atlassian
|
[11:05] mikko
|
(this morning)
|
[11:06] mikko
|
the guy who works on our issue was on emergency leave
|
[11:07] sustrik
|
great
|
[11:07] sustrik
|
thanks
|
[13:56] nicolas
|
is it too ugly to use mutexes in zmq apps?
|
[14:03] tproa
|
there's a whole section in the zmq guide that talks about concurrency and the various ills shared data suffers. i haven't done much with zeromq yet, but mutexes just kinda feel wrong.
|
[14:03] tproa
|
in a zmq application
|
[14:05] cremes
|
nicolas_: use a pair of sockets communicating via the inproc transport to communicate between threads
|
[14:07] mikko
|
nicolas_: what is the use-case?
|
[15:25] nicolas
|
mikko: I need to signal a thread that runs a main loop to reload a config file
|
[15:25] nicolas
|
i was thinking of constantly check on a shared bool value
|
[15:25] ianbarber
|
definitely use an inproc
|
[15:25] ianbarber
|
just have the reloader polling the connection, and push a message to it when the reload should occur
|
[15:25] nicolas
|
it is fundamental to the reloader not no block
|
[15:26] ianbarber
|
that's fine, just do a recv(ZMQ_NO_BLOCK), it'll just return EAGAIN if there's nothing there
|
[15:26] ianbarber
|
i presume there's a loop going on, so just put that check it at a reasonable point
|
[15:27] nicolas
|
hmm sounds good
|
[15:27] nicolas
|
i was not sure about how to implement polling with zmq
|
[15:27] ianbarber
|
your other options is to do a poll with a defined timeout, if you can handle some blocking = it's zmq_poll and accepts a timeout in microseconds
|
[15:28] ianbarber
|
you can also get the FD back from zeromq and check for state changes yourself if you need to integrate it into something else
|
[15:28] ianbarber
|
but i'd probably start with recv and only add complexity as you need it
|
[15:28] nicolas
|
poll blocks i think
|
[15:29] Seta00
|
nicolas_, not if you pass a timeout of 0
|
[15:29] Seta00
|
as ianbarber pointed out
|
[15:30] ianbarber
|
yep, 0 will return immediately
|
[15:30] Seta00
|
in this case, I'd rather use recv with ZMQ_NOBLOCK, for simplicity
|
[15:31] nicolas
|
and in the recv case, does pub/sub sound good ?
|
[15:31] ianbarber
|
doesn't sound right, unless i'm missing something
|
[15:31] nicolas
|
what do you suggest?
|
[15:31] ianbarber
|
pub sub is for one message out to many receivers, all of whom will get the same thing
|
[15:31] ianbarber
|
i would guess PUSH/PULL
|
[15:31] nicolas
|
in principle its one to one
|
[15:32] ianbarber
|
the reloader is a PULL, the client PUSHes a message to it
|
[15:32] mikko
|
if it's one to one then PAIR
|
[15:32] ianbarber
|
i would maybe not use PAIR
|
[15:32] nicolas
|
im already using pair in that same loop and it seems to work fine
|
[15:33] ianbarber
|
i mean, it works and all, but it makes it difficult to add other threads later that may need to send a message
|
[15:33] ianbarber
|
i would also prefer PUSH/PULL as it's explict about the type of messaging you're doing. it's a taste issue though, no technical reason not to use PAIR i'm aware of
|
[15:34] mikko
|
you could even use pub/sub
|
[15:34] mikko
|
if you want multiple subscribers later
|
[15:35] ianbarber
|
yeah, though without a device in the middle you're going to have a problem of having to explicitly connect to your other subs
|
[15:36] ianbarber
|
i think if you want that kind of messaging it would be worth having a little broker thread doing pub/sub forwarding, which is a bit more complex.
|
[15:36] ianbarber
|
this is fun, we should arrange another london pub meet :)
|
[15:36] nicolas
|
what im doing right now is a req/rep broker
|
[15:36] Seta00
|
ianbarber, in this case, pub/sub would be optimal, since push/pull would load balance and not all workers would reload the config file
|
[15:36] nicolas
|
that signals the main loop thread
|
[15:37] nicolas
|
when certaing command is requested
|
[15:37] ianbarber
|
Seta00: the PULL would be on the reloader
|
[15:37] ianbarber
|
i would envisage there is a single reloader thread, and a potentially dynamic number of client threads that might want to request a reload
|
[15:38] Seta00
|
oh yeah, the main loop is the one who reloads
|
[15:38] Seta00
|
you are right
|
[15:39] nicolas
|
the case is more likely to evolve as multiple reloaders and one control client
|
[15:40] ianbarber
|
in that case, Seta00 is right, pub/sub is the way to go
|
[15:40] nicolas
|
for the simplest case I will test push/pull first
|
[15:41] nicolas
|
with ZMQ_NOBLOCK
|
[15:47] taotetek
|
ianbarber: we're doing some patching and testing and more patching of our rsyslog plugins today, going to be a fun one
|
[15:48] ianbarber
|
excellent, looking forward to seeing the results :)
|
[15:49] taotetek
|
ianbarber: I am too! for my own uses - once I can bless this and get it into production it simplifies some of my current production environment a great deal
|
[16:13] CIA-31
|
jzmq: 03kwo 07master * re6c3c0b 10/ (pom.xml src/org/zeromq/App.java src/org/zeromq/ZMQ.java): Modified Maven POM to include the JNI library within the JAR file. ...
|
[16:13] CIA-31
|
jzmq: 03Gonzalo Diethelm 07master * r59616d9 10/ (pom.xml src/org/zeromq/App.java src/org/zeromq/ZMQ.java): Merge pull request #49 from kwo/embedded2 ...
|
[19:16] michelp
|
does anyone know where i can find the source to the guide?
|
[19:16] michelp
|
i'm looking in my git clone but don't see it in there
|
[19:16] michelp
|
poking around the wiki i don't see any reference to it either
|
[19:20] rbancroft
|
michelp: https://github.com/imatix/zguide/tree/master/examples/
|
[19:21] michelp
|
rbancroft, thanks!
|
[19:21] michelp
|
didn't think to dig around github
|
[19:21] rbancroft
|
there's actually a link right at the very top of the guide
|
[19:21] rbancroft
|
err
|
[19:21] rbancroft
|
on the manual page, anyways
|
[19:22] michelp
|
thanks, i'll did deeper next time
|
[19:28] blk
|
will a PUSH socket do load-balancing on a multicast transport ?
|
[19:30] guido_g
|
push/pull is tcp only
|
[19:35] blk
|
ok
|
[19:36] blk
|
what I would like to do is round-robin queueing
|
[19:36] blk
|
with a fan-out socket
|
[19:43] cremes
|
guido_g: doesn't push/pull also work with inproc & ipc?
|
[19:44] guido_g
|
which is tcp w/o ip
|
[19:45] guido_g
|
connected and a byte-stream
|
[20:39] wailupe2k
|
Working on getting the node.js bindings to work on BSD, NODE V 0.4.8, zeromq.node version 0.5.0. require('zeromq'); results in /libexec/ld-elf.so.1: /root/node_modules/zeromq/binding.node: Undefined symbol "_ZN2v811HandleScopeC1Ev"
|
[20:39] wailupe2k
|
anybody out there have any idea what this could be?
|
[20:42] wailupe2k
|
and Zeromq 2.1.7 , via bsd ports to /usr/local/[lib | include]. I have the perl ZeroMQ lib working great on the same machine
|