IRC Log


Sunday January 2, 2011

[Time] NameMessage
[00:03] andrewvc neopallium: it's actually a push socket
[00:04] andrewvc errr a pull socket I mena
[00:04] andrewvc maybe it didn't finish binding yet or something?
[00:04] andrewvc though the FD did trigger
[00:19] mikko andrewvc: are you sure it's a pull and not push socket?
[00:28] andrewvc yeah I'm certain
[00:29] andrewvc mikko: I'm certain because the messages eventually do start coming off
[00:29] andrewvc I should double check though
[00:50] andrewvc mikko: Oh how about that, I didn't realize that was being called on both send AND recv.... Thanks for the pointer
[00:50] andrewvc it was a PUSH after all. Thanks for recognizing that!
[00:51] mikko no prob, i think i've done that before as well
[00:51] andrewvc but recv isn't being called on it
[00:51] andrewvc send is
[00:51] andrewvc so, does that mean the socket isn't in a state where it's ready for sending I suppose
[00:54] andrewvc mikko: Well, re-checking it I'm getting all proper codes, and EAGAIN where I expect it. I guess cleaning up my testing code must have fixed whatever the err was
[00:55] andrewvc thanks for the help though, still good to know for later
[10:08] sustrik andrewvc: you've got ENOTSUPP from zmq_recv?
[10:11] sustrik looking at the code...
[10:12] sustrik hm, it can possibly happen when the socket is not yet fully initialised
[10:31] sustrik do you have a test program to reproduce it?
[22:20] shykes Hello
[22:29] mikko hi
[22:31] shykes I'm weighing my options for a "smarter" req/rep device. Are you aware of any projects going in that direction?
[22:31] mikko what do you mean by smarter?
[22:31] mikko brb
[22:32] shykes Currently we have a forwarder with bind on both sides
[22:32] shykes ie dynamic workers, dynamic clients
[22:32] shykes we use that to load-balance synchronous rpc. I'm guessing this is a classic use case
[22:34] shykes I'd like my device to stop forwarding requests to a worker which doesn't behave properly
[22:34] shykes eg. a pre-configured timeout
[22:37] shykes Maybe I could implement this as a 'proxy device' in front of each worker
[22:38] shykes each proxy has only one message to worry about at a time, which makes it simpler to write
[22:38] shykes Any insight would be much appreciated :)