Sunday January 2, 2011
[Time] Name | Message |
---|---|
[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 :) |