Possible Connection roblem in version 4
Posted: Mon 23 Apr 2007 18:13
I have a rather complex application which works well with version 3.55 of the MySQL Direct tool. Today I upgraded my developement machine to version 4.0 without error, and recompiled my application. At first things appeared to be working properly, but then the application started to hang intermittently. Attempts to kill it with the task manager proved troublesome, and sometimes when I ran it in debug mode I couldn't kill it within the debugger.
In trying to investigate the problem, I attached DBMonitor and managed to see the following which strikes me as very suspicious:
4/23/2007 1:54:07 PM 0:0.0 Open: User Id=haldi;Password=XXXXX;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:07 PM 0:0.0 Connect: User Id=haldi;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:07 PM 0:0.16 Execute: select * from trades where id > 47346 Complete
4/23/2007 1:54:07 PM 0:0.15 Open: User Id=haldi;Password=XXXXX;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:07 PM 0:0.0 Connect: User Id=haldi;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:07 PM 0:0.16 Execute: select * from fix_status where msg_type = 'Heartbeat' order by timestamp desc limit 1 Complete
4/23/2007 1:54:07 PM 0:19.250 Open: User Id=haldi;Password=XXXXX;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:26 PM 0:0.0 Execute: select * from fix_status where id > 147577 and msg_type = 'Error' order by timestamp desc limit 1 Complete
Why on earth would it suddenly take 19.25 seconds to open a connection to a db server? This application is run by about 10 users here, and the code in question fires every second on a timer control. Usually the round trip for all of the queries associated with this timer event is about 50-75 milliseconds.
In the log file snippet I've included, the only thing which changed was my upgrade to version 4 of the MySQL Direct object.
Also, the snippet shown is trying to access a MySQL Server version 5.0.18-nt-max running on a Win2003 server, 2 GB RAM, 4 CPU box, and the DB in question is about 6 MB in size (including indexes) and the tables in question are no more than 2,000 records max.
One last piece of info for you: After logging this behavior, I uninstalled version 4 and re-installed version 3.55. After swapping out the reference to CoreLab.MySQL 4, the new app runs fine with no system hangs or connection problems.
Hope this is helpful,
John
In trying to investigate the problem, I attached DBMonitor and managed to see the following which strikes me as very suspicious:
4/23/2007 1:54:07 PM 0:0.0 Open: User Id=haldi;Password=XXXXX;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:07 PM 0:0.0 Connect: User Id=haldi;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:07 PM 0:0.16 Execute: select * from trades where id > 47346 Complete
4/23/2007 1:54:07 PM 0:0.15 Open: User Id=haldi;Password=XXXXX;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:07 PM 0:0.0 Connect: User Id=haldi;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:07 PM 0:0.16 Execute: select * from fix_status where msg_type = 'Heartbeat' order by timestamp desc limit 1 Complete
4/23/2007 1:54:07 PM 0:19.250 Open: User Id=haldi;Password=XXXXX;Host=10.99.255.214;Database=mm_inputs;" Complete
4/23/2007 1:54:26 PM 0:0.0 Execute: select * from fix_status where id > 147577 and msg_type = 'Error' order by timestamp desc limit 1 Complete
Why on earth would it suddenly take 19.25 seconds to open a connection to a db server? This application is run by about 10 users here, and the code in question fires every second on a timer control. Usually the round trip for all of the queries associated with this timer event is about 50-75 milliseconds.
In the log file snippet I've included, the only thing which changed was my upgrade to version 4 of the MySQL Direct object.
Also, the snippet shown is trying to access a MySQL Server version 5.0.18-nt-max running on a Win2003 server, 2 GB RAM, 4 CPU box, and the DB in question is about 6 MB in size (including indexes) and the tables in question are no more than 2,000 records max.
One last piece of info for you: After logging this behavior, I uninstalled version 4 and re-installed version 3.55. After swapping out the reference to CoreLab.MySQL 4, the new app runs fine with no system hangs or connection problems.
Hope this is helpful,
John