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 :) |