| Bug #21358 | mysqlslap does not report error properly | ||
|---|---|---|---|
| Submitted: | 31 Jul 2006 8:31 | Modified: | 1 Jul 2008 16:06 |
| Reporter: | Magnus Blåudd | Email Updates: | |
| Status: | Patch pending | Impact on me: | |
| Category: | MySQL Server: Tests | Severity: | S3 (Non-critical) |
| Version: | 5.1 | OS: | Any (all) |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
[31 Jul 2006 8:31]
Magnus Blåudd
[5 Oct 2007 14:06]
Brian Aker
Please reverify (I think I fixed this, but it may have been in 5.1).
[13 Nov 2007 22:10]
Sveta Smirnova
Thank you for the report.
Verified as described:
$./bin/mysqlslap --socket=/tmp/mysql50.sock -uroot -q"select 1" && echo $?
./bin/mysqlslap: Error when connecting to server: 1049 Unknown database 'mysqlslap'
Benchmark
Average number of seconds to run all queries: 1.018 seconds
Minimum number of seconds to run all queries: 1.018 seconds
Maximum number of seconds to run all queries: 1.018 seconds
Number of clients running queries: 1
Average number of queries per client: 1
0
$./bin/mysqlslap --socket=/tmp/mysql5011.sock -uroot -q"select 1" && echo $?
./bin/mysqlslap: Error when connecting to server: Can't connect to local MySQL server through socket '/tmp/mysql5011.sock' (2)
$
[13 Nov 2007 22:12]
Sveta Smirnova
Verified with current 5.1 main tree.
[30 Jun 2008 22:26]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/48788 2677 Chad MILLER 2008-06-30 Bug#21358: mysqlslap does not report error properly In a thread that connects to the server, if it fails, we only return from that function (and thereby destroy the thread), and the main thread continues operating as if the operations were complete. It should instead halt and signal an error to the executor. This is the simplest fix that could possibly work. I considered creating a new global errorness variable and having the thread creator check its value upon the thread's exit and then pass the error value back up the call chain, I instead just instructed the thread to shut down the entire process when there is a fatal error. The first fix would have been 30 lines of changes instead of two, though perhaps more correct if we intend to do more with mysqlslap in the future (like make it into a library). I don't think that's likely.
[30 Jun 2008 22:43]
Brian Aker
No offense, but fix it right. If there will be no good fixes applied, please tell me so I can take it out of the tree and put it up as its own project.
[1 Jul 2008 16:06]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/48824 2677 Chad MILLER 2008-07-01 Bug#21358: mysqlslap does not report error properly In a thread that connects to the server, if it fails, we only return from that function (and thereby destroy the thread), and the main thread continues operating as if the operations were complete. It should instead halt and signal an error to the executor. Now, check for fatal errors in threads and have the main process behave correctly. Also, fix some of the more egregious problems with a spawned thread killing the entire process with the exit syscall. Also, start to use the exit value to tell the user where the error is -- locally or near the SQL server. 0=no error 1=local 2=server (This could be made into bit flags later, too.)
[1 Jul 2008 16:13]
Brian Aker
For cases of "cannot connect" put a counter in the stats structure and count the number of times this occurs. Then print those on exit. When you run MySQL with enough concurrent connections it turns out that it will sometimes not handle it. It is valuable to know what that is.
[1 Jul 2008 17:19]
Chad MILLER
Brian, I don't want to expand the scope of this bug any more.
[29 Jul 2008 18:28]
BJ Dierkes
Applied patches above to 5.1.26-rc ... build/test is successful on Redhat 5Server i386, however fails in a different manner on Redhat 5server 64bit: main.mysqldump [ pass ] 27291 main.mysqlshow [ pass ] 1743 main.mysqlslap [ fail ] mysqltest: At line 5: command "$MYSQL_SLAP --silent --concurrency=5 --iterations=20 --number-int-cols=2 --number-char-cols=3 --auto-generate-sql" failed The result from queries just before the failure was: exec of '/builddir/build/BUILD/mysql-5.1.26-rc/client/mysqlslap -uroot --port=9306 --socket=/builddir/build/BUILD/mysql-5.1.26-rc/mysql-test/var/tmp/master.sock --password= --silent --concurrency=5 --iterations=20 --number-int-cols=2 --number-char-cols=3 --auto-generate-sql' failed, error: 512, status: 2, errno: 0 More results from queries before failure can be found in /builddir/build/BUILD/mysql-5.1.26-rc/mysql-test/var/log/mysqlslap.log Aborting: main.mysqlslap failed in default mode. To continue, re-run with '--force'. Stopping All Servers make: *** [test-ns] Error 1 FROM THE ADDITIONAL LOG: /builddir/build/BUILD/mysql-5.1.26-rc/mysql-test/var/log/mysqlslap.log exec of '/builddir/build/BUILD/mysql-5.1.26-rc/client/mysqlslap -uroot --port=9306 --socket=/builddir/build/BUILD/mysql-5.1.26-rc/mysql-test/var/tmp/master.sock --password= --silent --concurrency=5 --iterations=20 --number-int-cols=2 --number-char-cols=3 --auto-generate-sql' failed, error: 512, status: 2, errno: 0 Please me know if there is any further information I could provide.
