7 messages in com.mysql.lists.plusplusRe: Connection object timeout questio...| From | Sent On | Attachments |
|---|---|---|
| Mandy Llanes | 10 Sep 2007 07:30 | |
| Graham Reitz | 10 Sep 2007 07:57 | |
| Warren Young | 10 Sep 2007 08:24 | |
| Jim Wallace | 10 Sep 2007 09:01 | |
| Graham Reitz | 10 Sep 2007 12:40 | |
| Warren Young | 10 Sep 2007 13:18 | |
| Graham Reitz | 10 Sep 2007 14:41 |
| Subject: | Re: Connection object timeout question... |
|---|---|
| From: | Warren Young (mysq...@etr-usa.com) |
| Date: | 09/10/2007 01:18:24 PM |
| List: | com.mysql.lists.plusplus |
Graham Reitz wrote:
Are there any known issues with the Connection object timeout parameter?
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 timeout.
- 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.