Hi Lance,
perhaps someone else might be able to give you a better answer, but from my recollection none of the APIs give any particularly easy way to retrieve the underlying socket. Indeed from memory any methods that do exist at that level have been private or protected scope. Another person was trying to get socket info a bit back so I took a bit of a look then and couldn't find anything useful.

I suspect that your best bet might be to do your own "network probe" - you say that you are using a lookup service, is that your own or something off the shelf? As I say you could probably do a port scan for port 5672 and use success there to feed your lookup service.

Sorry that I can't give a more useful response, but I suspect that's what I'd do if faced with a similar problem.

I guess that you *might* be able to do something clever with select/epoll so if you get some info from your lookup service you could try to establish a raw socket connection and use select/poll to check for the available active file descriptors then you could close them and use the knowledge to open up real AMQP connections to the active hosts. At least that'll avoid you needing to use threads.

<caveat>It's been a while since I did anything that low level, so I could be talking rubbish :-D </caveat>

Frase


On 03/05/13 13:14, Lance D. wrote:
Hello,

I've got a question about Socket timeouts. I've got a program that must be
single threaded.  I know that's got its own share of problems, but the
biggest one that I have right now is the case of trying to connect to a
broker on a host that doesn't exist.

I'll start with my configuration.  I have a client running with the 0.14
API on a Redhat Linux OS.  My program uses a lookup service to find brokers
and exchanges that are providing data.  The client connects to each
exchange, pulls the data and disconnects.  I don't need to do this
extremely quickly, but it really shouldn't take more than 1-2 seconds per
connection because they are all on a small network.

My problems begin when the lookup service gives me a broker address for a
host that is powered off.  When I call open on the connection, the SYN
packet is sent and I'm stuck waiting for the kernel socket timeout to
expire before qpid throws that exception.  That means that I'm stalled for
20 seconds for each down host.

So, my question to this wonderful group of users is this: what is the best
way (other than going multi-threaded), to reduce my wait from 20 seconds
down to 2 seconds?

Thanks all for the help!
-Lance



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to