Oops. I guess I did miss that one detail. I'm using the c++ API; sorry I didn't mention that earlier.
>From what I could find in the source code, I tend to agree with Frase's assessment. I even contemplated extending the ConnectionImpl class and getting setting the non-blocking to true or tweaking the socket parameters. It's still not out of the question, but obviously its not ideal. As for the lookup service, I'm actually using LDAP, which tells me host, port, and exchange. I can't really modify it to do any sort of host checking; however, I've contemplated having a multi-threaded app that just checks to see of LDAP agrees with the broker (using QMF). Thanks Jason and Frase. I appreciate the responses. -Lance On Fri, May 3, 2013 at 1:00 PM, Fraser Adams <[email protected]>wrote: > 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].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
