similar to: undefined method `verify_active_connections!''

I have a problem where I can''t run tests on a rails app that was written for rails 1.0. Sequence of events was this: Develop Application1 on Rails 1.0 / Ruby 1.8.2 Freeze rails into vendor folder on Application1 Develop Application2 on Rails 1.1 / Ruby 1.8.4 Return to Application1 and run tests, every test fails with the error "undefined method

Hi, I''ve just got a quick question. How come ActiveRecord::ConnectionAdapters::ConnectionHandler#verify_active_connections! is marked with :nodoc: ? I understand that this is used internally (depending upon an application''s configuration?) on every request (?) to clear out old, stale database connections. All this to prevent the old, classic "MySQL server has gone

Hi all, I''m trying to make for nicer system error handling, with the help of rescue_action_in_public (see Recipe 47, in ''Rails Recipes'') PROBLEM: While it lets me capture an incorrect db name in database.yml (for example), with lower level errors like when the DB server is just down, I still get the default system error screen for MySQL::ERROR :

Hi, I''m new to mongrel and so far have liked it a lot during development. I just tried to stand up a production server following the guide here: http://blog.innerewut.de/articles/2006/04/21/scaling-rails-with-apache-2-2-mod_proxy_balancer-and-mongrel This was working well for a few days, until this weekend it crashed with the following stack trace. It''s running on redhat

Hi guys, i have been experiencing this problem once i put in some constant declarations in /config/environments/development.rb. I declared it very normally like this : USER_DETAILS = { :name => ''abc'', :password => ''123''} it works in the controller and when i run the application, i managed to get the values out from the development.rb by using some

I setup a testing model in my Depot web app from the Agile Web Development with Rails book and came up with the following errors: Loaded suite test/unit/product_test Started EE Finished in 0.050279 seconds. 1) Error: test_create(ProductTest): Errno::ENOENT: No such file or directory - /Users/Mike/Sites/depot/config/../test/fixtures/categories

Recently I started noticing that after running for a while puppetmaster would freeze after a client called `freshness` which would eventually result in the client getting a timeout and the client dyeing. I tracked the freeze down to the call to ActiveRecord::Base.verify_active_connections! in rails.rb on line 26. After scouring the nets I finally found:

For testing, I use: self.use_transactional_fixtures = true This should cause a ROLLBACK for each test case. If I run a single file, foo_controller_test.rb, it works as expected. I see BEGIN and ROLLBACK 8 times in the log files. But if I run: rake test:functionals I get 3 COMMITs, 196 BEGINS and 193 ROLLBACKs. The code in fixtures.rb that deals with this is : def

Seemingly random db connection drop (FastCGI/Apache/PostgreSQL). Kills the app with an ''Application Error (Rails)'' Any suggestions? production.log as follows: Processing Base#index (for xxx.xxx.xxx.xxx at 2007-12-07 13:39:03) [GET] Session ID: 4bfd0284bd7672b57e65bdb21637adb5 Parameters: {} Errno::ECONNRESET (Connection reset by peer):

Hi, I'm hitting that issue since Mesa 20.0.6 and it is present still in latest version 20.1.7 ``` [tkloczko at barrel SPECS]$ coredumpctl gdb 3926866 PID: 3926866 (test_va_api) UID: 1000 (tkloczko) GID: 1000 (tkloczko) Signal: 11 (SEGV) Timestamp: Sun 2020-09-13 18:57:06 BST (32s ago) Command Line: ./test_va_api Executable:

All of a sudden, I''m getting this error: 1) Error: test_index(AccountControllerTest): RuntimeError: The number of parameters does not match the number of substitutions. /home/joe/projects/tanga/trunk/config/../vendor/rails/actionpack/lib/action_controller/assertions.rb:92:in `assert_redirected_to''

I''ve been trying to get fast cgi working for nearly a month now. Yes, an entire month! The application starts perfect, but it will die randomly after several hours. I have traced the problem back to /usr/lib/ruby/1.8/mysql.rb:1042:in `flush'' This happens when the app trys to query the database driver to see if it still has a connnection. This causes the app to crash. Here is

I am not sure when it exactly occurred but I have 2 servers I am about to migrate to apache+mongrel from lighty+fastcgi oddly, both my servers seemed to have died at the same time everytime I restart within a 24 hr period ( I don''t know when, my logs don''t show it ). Can someone please point me in the direction of what I need to do to trace the cause of this. Or what you would

On Thu, Jan 04, 2018 at 11:29:09AM +0000, Jon Hunter wrote: > Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") > introduced add a teardown helper function for BAR1. During > initialisation of the Nouveau, initially all the teardown helpers are > called once, before calling their init counterparts. For gk20a, after > the BAR1 teardown function is called, the

Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") introduced add a teardown helper function for BAR1. During initialisation of the Nouveau, initially all the teardown helpers are called once, before calling their init counterparts. For gk20a, after the BAR1 teardown function is called, the device is hanging during the initialisation of the FB sub-device. At this point it

Hey all, I got annoyed recently that I couldn''t specifiy multiple chunks of test setup and teardown code that get executed for each test. You''re currently limited to just one setup method (unless I''m much mistaken). Anyway, I just wrapped up my solution in a plugin. The answer: use blocks! class Test::Unit::TestCase # This is overridden by the subclass and will

For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline

For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline

On Thu, Aug 15, 2019 at 01:12:22PM -0700, Dan Williams wrote: > On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse <jglisse at redhat.com> wrote: > > > > On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote: > > > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse <jglisse at redhat.com> wrote: > > > > > > > > On Wed, Aug 14, 2019 at

I know this question gets asked a lot but I can''t seem to find the answer when I search through the mailing list. First off here''s my set up. Cent OS 4.3 Apache 2.0 Fast CGI 2.4.0 Rails 1.1 Mysql 5.0 The app starts up fine, but every morning it refuses to start and gives me the dreaded Application error untill I reload Apache. I thought my database was timing out so I added