With respect to only the problem of attempting to make initial connection to a broker and handling the case in which the OS that broker is running on may be down:
Since you are on a *nix box, you will have the epoll or select system call available to you. I believe that you can initiate your own (direct, not through the Qpid client library) socket connection to broker as an asynchronous operation (that is, tell the open not to wait for completion), and do this for all brokers in parallel. After a short timeout you can see who has responded with epoll or select. Machines that are up, with their networking enabled, and which are running a broker, will respond promptly, and be in the list of responders. You remove the others from your list of brokers to try. You now close ALL these connections (since I doubt that there is a way to pass the working ones off to the library). Then you can use the Qpid library to connect to the ones that are alive. You could argue that this is, in a sense, multi threaded in that multiple socket opens are flying at once, but it does not involve the use of kernel threads or a threading library in the client process (and the kernel itself is multi threaded whether you like it or not). You could, of course, make these test connections sequentially, specifying a short timeout (and not involve epoll or select at all), but the approach above gets you doing real work on live brokers that much sooner. Bill On Fri, May 3, 2013 at 5:06 PM, Andrew Stitcher <[email protected]>wrote: > On Fri, 2013-05-03 at 08:14 -0400, 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? > > Assumptions: > * You are using the C++ messaging API (namespace qpid::messaging) > > I think you can solve this by setting the heartbeat timeout option on > the connection. If I remember correctly the client sets the heartbeat > timer before trying the connection so if it doesn't get a connection > within 2*heartbeat interval it will abort the connection. > > For example using the qpid-send application: > > qpid-send -a foo -b example.com > > Takes a long time to time out(your situation); > > qpid-send -a foo -b example.com -connection-options {heartbeat:1} > > Times out in 2 seconds (or so): > 2013-05-03 16:55:27 [Network] warning Connect failed: Connection > timedout > 2013-05-03 16:55:27 [Client] warning Connection closed > qpid-send: Failed to connect (reconnect disabled) > > programatically (untested snippets): > connection = Connection(url, "{heartbeat:1}"); > connection.open(); > > Or > connection.setOption("heartbeat", 1); > connection.open(); > > Hope that helps. > > Andrew > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
