2 messages in com.mysql.lists.plusplusRe: Timeouts on queries under Solaris| From | Sent On | Attachments |
|---|---|---|
| Des Smith | 05 Sep 2007 08:00 | |
| Warren Young | 05 Sep 2007 09:17 |
| Subject: | Re: Timeouts on queries under Solaris |
|---|---|
| From: | Warren Young (mysq...@etr-usa.com) |
| Date: | 09/05/2007 09:17:20 AM |
| List: | com.mysql.lists.plusplus |
Des Smith wrote:
I'm using the version of the libraries with the fix for the Connection->set_option issue that was reported on the MySQL mailing list
I don't know why you call this a "version of the library". That makes it sound official. What you have there is the official library with some third party's patch installed.
You compound my mystification by continuing to use this hacked library after the issue is fixed in an official version. (v2.3.2)
When I suspend the database, using kill -SIGSTOP, the executing write query does not timeout as expected.
The read/write timeout has been set to 1 second.
It looks like timeouts work on Red Hat Enterprise Linux 4 (compiler g++ (GCC) 3.4.5 (Red Hat 3.4.5-2)) , but not Solaris?
This is not a MySQL++ issue. MySQL++ has no timeout logic, at all. It's all up to the underlying C API library.
Not that knowing that will do you any good, I think. I haven't looked at the code, but I have no doubt that the C API library in turn is relying on the behavior of the network stack it's running on to get these behaviors. If the Solaris stack behaves differently from the Linux stack, then that's just the way it is.
If you must have a guaranteed maximum limit on the run time for a given function call, I suggest looking at alarm(2).
I make this suggestion under the assumption that you're using a 1-second timeout for testing purposes only. If you really need a guaranteed go/no-go response in no more than 1 second, alarm() won't have the resolution you need. But if you did need that, I'd question why you're using MySQL++ and MySQL anyway, since you'd be crossing into hard real-time territory.