| [Time] Name | Message |
|
[04:30] CIA-15
|
pyzmq: 03Brian Granger 07nocopy * r6250cb5 10/ (zmq/_zmq.c zmq/_zmq.pyx): Adding support for full non-copy send/recv using Message. - http://bit.ly/aoi0LX
|
|
[09:59] vincent00
|
hi all
|
|
[10:00] vincent00
|
i have a design question about how to do requests inside a service architecture
|
|
[10:00] vincent00
|
is it recommended to create a socket for each rpc call or is it better to maintain connections to each service and use them when you need to?
|
|
[10:02] vincent00
|
I'm thinking of wrapping the most used messages (protocol buffers) as python functions so they can easily be reused by the applications that are built by the researchers we support
|
|
[10:03] vincent00
|
that would be significantly easier if i could just create a req socket each time i want to send a message
|
|
[10:08] sustrik
|
vincent: you can do that
|
|
[10:08] sustrik
|
but obviously, you shouldn't expect it to be very efficient
|
|
[10:09] vincent00
|
hi sustrik_
|
|
[10:09] vincent00
|
so an option i should think about is some way of managing connections?
|
|
[10:09] vincent00
|
indexed by service
|
|
[10:09] sustrik
|
what are you trying to build
|
|
[10:10] sustrik
|
SOA?
|
|
[10:10] vincent00
|
yes :)
|
|
[10:10] sustrik
|
ok, then you need a shared queue in the middle
|
|
[10:10] mato
|
sustrik_: yo
|
|
[10:10] vincent00
|
we have some services that process and generate sound
|
|
[10:10] sustrik
|
mato: hi
|
|
[10:10] mato
|
sustrik_: you're not watching your messages...
|
|
[10:11] sustrik
|
what messages?
|
|
[10:11] mato
|
sustrik_: can i drop by to discuss some business stuff?
|
|
[10:11] mato
|
sustrik_: private messages on irc
|
|
[10:11] vincent00
|
sustrik_: so no direct connections to the services?
|
|
[10:11] sustrik
|
a-ha, sure, drop by
|
|
[10:11] mato
|
sustrik_: when? isn't your sister arriving today?
|
|
[10:11] sustrik
|
vincent: you can do that but that's not what's normally understood under the term "SOA"
|
|
[10:12] sustrik
|
mato: tomorrow
|
|
[10:12] sustrik
|
i'm at home today
|
|
[10:12] mato
|
sustrik_: ok, good, then i'll have lunch and go to your place...
|
|
[10:12] sustrik
|
ok
|
|
[10:12] mato
|
sustrik_: in an hour or so
|
|
[10:13] sustrik
|
vincent: the best way is to think a bit about what you want to achieve
|
|
[10:14] sustrik
|
and put that down on paper
|
|
[10:14] sustrik
|
then decide on setup of the network
|
|
[10:14] sustrik
|
and finally map the setup diagram to 0MQ concepts
|
|
[10:17] vincent00
|
sustrik_: ok, the design is ready to be mapped to zmq concepts i think, i'll take that approach :) thanks
|
|
[10:18] sustrik
|
have a block diagram?
|
|
[10:18] sustrik
|
is there a node in the middle?
|
|
[10:18] sustrik
|
or are clients connected to services directly
|
|
[10:18] sustrik
|
?
|
|
[10:19] vincent00
|
right now clients are connected directly to services, rpc style
|
|
[10:19] vincent00
|
between the task scheduler and the workers we have a different approach
|
|
[10:20] sustrik
|
so there's only one app instance for each server, right?
|
|
[10:20] sustrik
|
no load-balancing
|
|
[10:20] sustrik
|
no failover
|
|
[10:21] vincent00
|
multiple apps can be running on the same node, but never the same app twice on the network for now (except worker nodes, but we have that figured out, clients don't connect to them)
|
|
[10:21] vincent00
|
nope
|
|
[10:21] sustrik
|
then it's easy
|
|
[10:21] sustrik
|
REP socket in each service
|
|
[10:22] sustrik
|
REQ socket in each client
|
|
[10:22] sustrik
|
clients may close the socket after each RPC call
|
|
[10:22] sustrik
|
however, if you want to do lot of RPC calls efficiently
|
|
[10:22] sustrik
|
it's better to leave the connection open
|
|
[10:23] sustrik
|
rather than reopening it each time it's needed
|
|
[10:23] vincent00
|
ok, that was what i wondering about, whether it was ok to create sockets on the fly many times over, i guess it's to be decided on a case by case basis
|
|
[10:24] vincent00
|
thanks :) very helpful :)
|
|
[16:45] mikko
|
got the php extension windows builds in a minute
|
|
[16:59] sustrik
|
!
|
|
[17:27] mikko
|
trying to script up the whole process
|
|
[17:27] mikko
|
but windows batch is not the most pleasant scripting language
|
|
[17:40] mikko
|
http://valokuva.org/~mikko/builds/
|
|
[17:40] mikko
|
should update soon after my batch finishes
|
|
[17:47] mikko
|
http://valokuva.org/~mikko/builds/
|
|
[17:47] mikko
|
bam
|
|
[17:47] mikko
|
windows builds
|
|
[19:31] CIA-17
|
pyzmq: 03Brian Granger 07nocopy * reb61ac5 10/ (perf/local_lat.py perf/local_thr.py perf/remote_lat.py): Adding non-copy capability for recv's in perf tests. - http://bit.ly/aAsfvh
|
|
[20:03] CIA-17
|
pyzmq: 03Brian Granger 07nocopy * r42903ba 10/ (perf/remote_lat.py zmq/_zmq.c zmq/_zmq.pyx): Adding back Stopwatch for perf tests and modified lat test to use. - http://bit.ly/c9dOZ2
|
|
[20:30] CIA-17
|
pyzmq: 03Brian Granger 07nocopy * r8d32972 10/ (zmq/_zmq.c zmq/_zmq.pyx): Fixing old memory leak in Stopwatch. - http://bit.ly/98nJmz
|
