Friday May 21, 2010

[Time] NameMessage
[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. -
[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
[17:40] mikko should update soon after my batch finishes
[17:47] mikko
[17:47] mikko bam
[17:47] mikko windows builds
[19:31] CIA-17 pyzmq: 03Brian Granger 07nocopy * reb61ac5 10/ (perf/ perf/ perf/ Adding non-copy capability for recv's in perf tests. -
[20:03] CIA-17 pyzmq: 03Brian Granger 07nocopy * r42903ba 10/ (perf/ zmq/_zmq.c zmq/_zmq.pyx): Adding back Stopwatch for perf tests and modified lat test to use. -
[20:30] CIA-17 pyzmq: 03Brian Granger 07nocopy * r8d32972 10/ (zmq/_zmq.c zmq/_zmq.pyx): Fixing old memory leak in Stopwatch. -