El Sábado, 5 de Septiembre de 2009, Jeremy Evans escribió: > On Sep 4, 4:06 pm, Iñaki Baz Castillo <[email protected]> wrote: > > El Sábado, 5 de Septiembre de 2009, Iñaki Baz Castillo escribió: > > > El Sábado, 5 de Septiembre de 2009, Iñaki Baz Castillo escribió: > > > > El Sábado, 5 de Septiembre de 2009, Jeremy Evans escribió: > > > > > The patch athttp://pastie.org/606419.txtshould fix this error. > > > > > > > > Applied, but still happens: > > > > > > > > Mysql::Error: Can't connect to local MySQL server through socket > > > > '/var/run/mysqld/mysqld.sock' (2) > > > > > > I think it occurs when I call to ps#call (prepared stament) while the > > > MySQL is restarting/stopped. > > Is that not wrapped in a Sequel::DatabaseError (or a subclass) > instance? > > > Yes, the bug must be there. Please note what me app logs say: > > > > - I run my app so DB.set is called: > > > > I 2009-09-05 01:00:03 [6441] INFO : Setting DB prepared staments > > D 2009-09-05 01:00:03 [6441] DEBUG : DB: ds_get_document.prepare > > I 2009-09-05 01:00:03 [6441] INFO : Done > > > > - At this point my app is running as well MySQL. A request arrives so my > > app does a select using the prepared stament. > > > > D 2009-09-05 01:00:26 [6441] DEBUG : DB: ps_get_document.call > > > > - Now I stop MySQL. A new request arrives: > > > > D 2009-09-05 01:00:35 [6441] DEBUG : DB: ps_get_document.call > > F 2009-09-05 01:00:35 [6441] FATAL : Mysql::Error: Can't connect to local > > MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) > > > > - I rescue the error (any error for now) so call again to DB.set: > > > > I 2009-09-05 01:00:35 [6441] INFO : Setting DB prepared staments > > D 2009-09-05 01:00:35 > > [6441] DEBUG : DB: ds_get_document.prepare I 2009-09-05 01:00:35 [6441] > > INFO : Done > > > > - MySQL still down and a new request arrives: > > > > D 2009-09-05 01:00:44 [6441] DEBUG : DB: ps_get_document.call > > F 2009-09-05 01:00:44 [6441] FATAL : Sequel::DatabaseConnectionError: > > Mysql::Error Can't connect to local MySQL server through socket > > '/var/run/mysqld/mysqld.sock' (2) > > > > - Again DB.set is called. > > > > I 2009-09-05 01:00:44 [6441] INFO : Setting DB prepared staments > > D 2009-09-05 01:00:44 [6441] DEBUG : DB: ds_get_document.prepare > > I 2009-09-05 01:00:44 [6441] INFO : Done > > > > - MySQL is up again. A new request arrives (and now it works): > > > > D 2009-09-05 01:00:55 [6441] DEBUG : DB: ps_get_document.call > > That's the changed behavior. Before, when the MySQL server was up > again, the connection still thought the statement had already been > prepared. Now it knows that it hasn't, so it prepares the statement > first before executing it. > > I can't replicate your issue: > > $ ruby -I lib bin/sequel -E mysql://root:r...@localhost/test > Your database is stored in DB... > irb(main):001:0> ps = DB['SELECT 1'].prepare(:first, :a) > => <Sequel::MySQL::Dataset/PreparedStatement "SELECT 1"> > irb(main):002:0> ps.call({}) > I, [2009-09-04T15:56:13.020397 #23364] INFO -- : PREPARE a FROM > 'SELECT 1' > I, [2009-09-04T15:56:13.020999 #23364] INFO -- : EXECUTE a > => {:"1"=>1} > irb(main):003:0> > irb(main):004:0* ps.call({}) > I, [2009-09-04T15:56:21.646780 #23364] INFO -- : EXECUTE a > => {:"1"=>1} > irb(main):005:0> [2] + Suspended ruby -I lib bin/sequel -E > mysql://root:r...@loc > $ sudo mysqladmin --user root -p shutdown > Password: > Enter password: > $ fg > ruby -I lib bin/sequel -E mysql://root:r...@loc > irb(main):005:0> ps.call({}) > I, [2009-09-04T15:57:17.794880 #23364] INFO -- : EXECUTE a > Sequel::DatabaseDisconnectError: Mysql::Error: Can't connect to local > MySQL server through socket '/var/run/mysql/mysql.sock' (2) > from ./lib/sequel/adapters/mysql.rb:157:in `query' > from ./lib/sequel/adapters/mysql.rb:157:in `_execute' > from ./lib/sequel/adapters/mysql.rb:234:in > `execute_prepared_statement' > from ./lib/sequel/connection_pool.rb:112:in `hold' > from ./lib/sequel/database.rb:482:in `synchronize' > from ./lib/sequel/adapters/mysql.rb:221:in > `execute_prepared_statement' > from ./lib/sequel/adapters/mysql.rb:136:in `execute' > from ./lib/sequel/dataset.rb:334:in `execute' > from ./lib/sequel/adapters/mysql.rb:359:in `execute' > from ./lib/sequel/adapters/mysql.rb:271:in `execute' > from ./lib/sequel/adapters/mysql.rb:315:in `fetch_rows' > from ./lib/sequel/dataset.rb:189:in `each' > from ./lib/sequel/dataset/convenience.rb:196:in > `single_record' > from ./lib/sequel/dataset/convenience.rb:59:in `first' > from ./lib/sequel/dataset/prepared_statements.rb:118:in `run' > from ./lib/sequel/dataset/prepared_statements.rb:24:in `call' > from (irb):5irb(main):006:0> ps.call({}) > Sequel::DatabaseConnectionError: Mysql::Error: Can't connect to local > MySQL server through socket '/var/run/mysql/mysql.sock' (2) > from ./lib/sequel/adapters/mysql.rb:101:in `real_connect' > from ./lib/sequel/adapters/mysql.rb:101:in `connect' > from ./lib/sequel/database.rb:93:in `initialize' > from ./lib/sequel/connection_pool.rb:169:in `call' > from ./lib/sequel/connection_pool.rb:169:in `make_new' > from ./lib/sequel/connection_pool.rb:156:in `available' > from ./lib/sequel/connection_pool.rb:147:in `acquire' > from ./lib/sequel/connection_pool.rb:146:in `synchronize' > from ./lib/sequel/connection_pool.rb:146:in `acquire' > from ./lib/sequel/connection_pool.rb:102:in `hold' > from ./lib/sequel/database.rb:482:in `synchronize' > from ./lib/sequel/adapters/mysql.rb:221:in > `execute_prepared_statement' > from ./lib/sequel/adapters/mysql.rb:136:in `execute' > from ./lib/sequel/dataset.rb:334:in `execute' > from ./lib/sequel/adapters/mysql.rb:359:in `execute' > from ./lib/sequel/adapters/mysql.rb:271:in `execute' > from ./lib/sequel/adapters/mysql.rb:315:in `fetch_rows' > from ./lib/sequel/dataset.rb:189:in `each' > from ./lib/sequel/dataset/convenience.rb:196:in > `single_record' > from ./lib/sequel/dataset/convenience.rb:59:in `first' > from ./lib/sequel/dataset/prepared_statements.rb:118:in `run' > from ./lib/sequel/dataset/prepared_statements.rb:24:in `call' > from (irb):6irb(main):007:0> [2] + Suspended ruby - > I lib bin/sequel -E mysql://root:r...@loc > $ fg %1 > sudo mysqld_safe > /dev/null 2>&1 > $ sudo mysqld_safe > /dev/null 2>&1 > ^Z[1] + Suspended sudo mysqld_safe > /dev/null 2>&1 > $ bg > [1] sudo mysqld_safe > /dev/null 2>&1 > $ fg %2 > ruby -I lib bin/sequel -E mysql://root:r...@loc > ps.call({}) > I, [2009-09-04T15:57:55.261062 #23364] INFO -- : PREPARE a FROM > 'SELECT 1' > I, [2009-09-04T15:57:55.261715 #23364] INFO -- : EXECUTE a > => {:"1"=>1} > irb(main):008:0> ps.call({}) > I, [2009-09-04T15:57:57.052248 #23364] INFO -- : EXECUTE a > => {:"1"=>1} > irb(main):009:0> >
I get the *same* result. > The difference could be due to the fact that I just committed an > exception related change to the master branch. Please try with the > master branch and let me know your results. I have sequel gem 3.4.0 installed, and I applied your patch http://pastie.org/606419.txt. Is it enough or must I use the master branch? # gem list | grep sequel sequel (3.4.0) # gem list | grep mysql do_mysql (0.9.9) mysql (2.8.1, 2.7) > If you find that there is > still a situation where the Mysql::Error is not being wrapped in a > Sequel::DatabaseError, please post an example with a backtrace so I > can track it down. In my app still occcurs: - If I shutdown MySQL and call ps.call I get Mysql.Error. - After MySQL becomes available again, a ps.call doesn't invoke PREPARE query. Let's continue next week. If I don't get it fixed and you are interested, I could give you access to my server if you want to see it by yourself. -- Iñaki Baz Castillo <[email protected]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
