Bug #40407 MyODBC takes 15 minutes to time out on network connection failure

Description:
Client hangs when network connection to the server is interrupted.  

gdb trace from client:

Thread 4 (Thread -1396245600 (LWP 3032)):
#0 0x00ad07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00c9f69b in __read_nocancel () from /lib/tls/libpthread.so.0
#2 0x006c1a19 in vio_read () from /usr/lib/libmyodbc3-3.51.19.so
#3 0x006c1a80 in vio_read_buff () from /usr/lib/libmyodbc3-3.51.19.so
#4 0x006c333e in my_net_set_write_timeout () from /usr/lib/libmyodbc3-3.51.19.so
#5 0x006c312a in my_net_read () from /usr/lib/libmyodbc3-3.51.19.so
#6 0x006bc159 in cli_safe_read () from /usr/lib/libmyodbc3-3.51.19.so
#7 0x006bec9c in mysql_close () from /usr/lib/libmyodbc3-3.51.19.so
#8 0x006bef0c in mysql_real_query () from /usr/lib/libmyodbc3-3.51.19.so
#9 0x006a06d2 in mysql_query () from /usr/lib/libmyodbc3-3.51.19.so
#10 0x00694b9a in do_query () from /usr/lib/libmyodbc3-3.51.19.so
#11 0x00695940 in my_SQLExecute () from /usr/lib/libmyodbc3-3.51.19.so
#12 0x0069575b in SQLExecute () from /usr/lib/libmyodbc3-3.51.19.so
#13 0x0807723f in otl_sel::first (this=0x87c8510, cur=@0x87c84b8, cur_row=@0x87c8500,
cur_size=@0x87c8504, row_count=@0x87c8508, eof_data=@0x87c84ec, array_size=50)
at /software/src/common/OTL/otlv4.h:11321
#14 0x080770b9 in otl_tmpl_select_cursor<otl_exc, otl_conn, otl_cur, otl_var, otl_sel>::first (
this=0x87c84a8) at /software/src/common/OTL/otlv4.h:5036
#15 0x08073850 in otl_tmpl_select_stream<otl_exc, otl_conn, otl_cur, otl_var, otl_sel, tagTIMESTAMP_STRUCT>::rewind (this=0x87c84a8) at /software/src/common/OTL/otlv4.h:5262
#16 0x0807397d in otl_stream::rewind (this=0xacc6f078) at /software/src/common/OTL/otlv4.h:12562
#17 0x0807255f in otl_stream::open (this=0xacc6f078, arr_size=50,
sqlstm=0x5bf518 "select id, TABLE_NAME, MODIFIED_TIME,now() from DB_CHANGES where id=(select max(id) from DB_CHANGES)", db=@0x87928d8, implicit_select=0, sqlstm_label=0x0)
at /software/src/common/OTL/otlv4.h:12624
#18 0x080711ee in DbQueryProcessor<DBQueryDbChanges>::prepare (this=0xacc6f020, match1=@0x808e680,
match2=@0x808e680, match3=@0x808e680)
at /software/src/common/platformservices/api/include/database/DbQueryProcessor.h:150
#19 0x08067898 in DbProxy_i::checkForDbChanges () at DbProxyMiddlewareInterface.cpp:337
#20 0x00917396 in PsTimerHdlr::handle_timeout (this=0x87ac580, curTime=@0xacc6f218)
at PsTimerHdlr.cpp:237
#21 0x0016816e in ACE_Event_Handler_Handle_Timeout_Upcall<ACE_Recursive_Thread_Mutex>::timeout (
this=0x876d718, timer_queue=@0x876ee10, event_handler=0x87ac580, act=0x0, recurring_timer=1,
cur_time=@0xacc6f218) at /software/src/common/ACE/ACE_wrappers/ace/Timer_Queue_T.cpp:408
#22 0x0016810c in ACE_Timer_Queue_T<ACE_Event_Handler*, ACE_Event_Handler_Handle_Timeout_Upcall<ACE_Recursive_Thread_Mutex>, ACE_Recursive_Thread_Mutex>::upcall (this=0x876ee10, info=@0xacc6f200,
#23 0x00325394 in ACE_TP_Reactor::handle_timer_events (this=0x876e630, guard=@0xacc6f290)
at TP_Reactor.cpp:395
#24 0x003251e8 in ACE_TP_Reactor::dispatch_i (this=0x876e630, max_wait_time=0x0, guard=@0xacc6f290)
at TP_Reactor.cpp:288
#25 0x0032500a in ACE_TP_Reactor::handle_events (this=0x876e630, max_wait_time=0x0) at TP_Reactor.cpp:173
#26 0x002fca36 in ACE_Reactor::run_reactor_event_loop (this=0x876ed54, eh=0) at Reactor.cpp:233
#27 0x0090b827 in PlatformServiceSingleton_i::ioEventLoop () at PlatformService.cpp:376
#28 0x00319950 in ACE_Thread_Adapter::invoke_i (this=0x879ad50) at Thread_Adapter.cpp:151
#29 0x00319889 in ACE_Thread_Adapter::invoke (this=0x879ad50) at Thread_Adapter.cpp:95
#30 0x0028841a in ace_thread_adapter (args=0x879ad50) at Base_Thread_Adapter.cpp:137
#31 0x00c9a3cc in start_thread () from /lib/tls/libpthread.so.0
#32 0x00bb31ae in clone () from /lib/tls/libc.so.6

How to repeat:
Here is the test scenario: Client is on node1 and using ODBC/OTL 4.0 to connect to MySQL server, which is running on node2. Now when a network cable is pulled out from node2, the client on node1 hangs for 15 minutes. It doesn't get the socket timeout network failure and fails to return immediately.

Hey Kyle.

I think you rushed too fast and disregarded possible regression related to Bug #9678.

My test:
  o MySQL server version: 5.0.67-community-nt MySQL Community Edition (GPL) on Vista x64 remote host.
  o MySQL client 5.0.67 on localhost.

Connection id:    5
Current database: information_schema

mysql> select sleep(5), 1+1;
+----------+-----+
| sleep(5) | 1+1 |
+----------+-----+
|        0 |   2 |
+----------+-----+
1 row in set (5.22 sec)

mysql> select sleep(10), 1+1;

--<server network cable disconnected>--

Query aborted by Ctrl+C (after 30 minutes waiting)
^C

I fail to see how this is related to ODBC...

Client screen shoot after disconnecting server from network.

Attachment: Bug9678.JPG (image/jpeg, text), 133.01 KiB.

Sveta, I need to know if *Linux* client fails. Please retest once again.

With Linux client connection fails as well: C API behavior is correct

Thanks Sveta for checking client library for regression.
	mysql_options(&conn, MYSQL_OPT_READ_TIMEOUT, (void *)&timeout);
	mysql_options(&conn, MYSQL_OPT_WRITE_TIMEOUT, (void *)&timeout);
work as expected but, unfortunately, we do not implement those in c/ODBC...

Fix pushed to

https://code.launchpad.net/~myodbc-developers/myodbc/bug40407_351

Pushed as rev 689.

Will be released in 3.51.27.

Added READTIMEOUT and WRITETIMEOUT connection options that correspond to the MYSQL_OPT_READ_TIMEOUT and MYSQL_OPT_WRITE_TIMEOUT options of libmysql.

An entry was added to the 3.51.27 changelog:

The client program hung when the network connection to the server was interrupted. 

Also, information was added to the main documentation for the options READTIMEOUT and WRITETIMEOUT.

I don't see if this bug was/is also present in 5.1, is it?
Can someone confirm that this bug isn't present in 5.1?
Can someone confirm the READTIMEOUT and WRITETIMEOUT options are available in 5.1 ?

Bonny,