>I don't see that on Linux. (I assume from your "m_" MFCism that
you're on Windows.) I see these behaviors:
The code is running on mac os x, windows, and linux. We see it on
mac and windows, have to try it on my ubuntu box later. It's just a
style thing used by my colleages and myself (about twelve of us) that
prefer to know what the scope is with a quick glance.
Thanks for answering the question. That makes sense now.
On Sep 10, 2007, at 3:18 PM, Warren Young wrote:
> Graham Reitz wrote:
>> Are there any known issues with the Connection object timeout
> The main fact of timeouts in MySQL++ came up here just last
> Wednesday. (See the thread "Timeouts on queries under Solaris".)
> MySQL++ itself has no timeout code in it, at all. And, the
> underlying C API library probably doesn't have much of this sort of
> code in it, if any. Most of it's going to be up to the underlying
> network stack. Firewalls can be involved, too.
> None of this is MySQL++-specific, and so there's not much more you
> can say that's on topic here.
>> Changing the timeout to 5 seconds results in a ~22 second timeout,
>> and a 22 second timeout results in a ~22 second timeout. A 30
>> second timeout results in a ~22 second timeout. A 60 second
>> timeout takes ~22 seconds to realize the IP address is bogus.
> I don't see that on Linux. (I assume from your "m_" MFCism that
> you're on Windows.) I see these behaviors:
> - Giving examples/simple1 the address of a legitimate server not
> running MySQL results in an almost instant failure.
> - Giving it an IP that's currently unused results in a 3-second
> - Giving it an IP of a machine that's stealth-firewalling the MySQL
> server port results in a timeout over 3 minutes long when you don't
> specify a timeout. With:
> Connection::set_option(Connection::opt_connect_timeout, 10u);
> added before the connect() call, you get a 10-second timeout.
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: http://lists.mysql.com/plusplus?