I currently have a Rails 3.2.13 app using redis as its cache_store and for Sidekiq.
I'm also using redis master-slave. I ran into an issue where during failover a slave would be in the process of becoming master, Rails then connected to this node and once it tried to write to the node, even though the node was master, this exception was raised:
Redis::CommandError: READONLY You can't write against a read only slave.
vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis/client.rb:85:in `call'
vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis.rb:1181:in `block in srem'
vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis.rb:36:in `block in synchronize'
/usr/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis.rb:36:in `synchronize'
vendor/bundle/ruby/1.9.1/gems/redis-3.0.4/lib/redis.rb:1180:in `srem'
vendor/bundle/ruby/1.9.1/gems/redis-namespace-1.3.0/lib/redis/namespace.rb:306:in `method_missing'
vendor/bundle/ruby/1.9.1/gems/sidekiq-2.11.2/lib/sidekiq/manager.rb:123:in `block in clear_worker_set'
vendor/bundle/ruby/1.9.1/gems/connection_pool-1.0.0/lib/connection_pool.rb:48:in `with'
vendor/bundle/ruby/1.9.1/gems/sidekiq-2.11.2/lib/sidekiq.rb:67:in `redis'
vendor/bundle/ruby/1.9.1/gems/sidekiq-2.11.2/lib/sidekiq/manager.rb:118:in `clear_worker_set'
vendor/bundle/ruby/1.9.1/gems/sidekiq-2.11.2/lib/sidekiq/manager.rb:45:in `block in stop'
vendor/bundle/ruby/1.9.1/gems/sidekiq-2.11.2/lib/sidekiq/util.rb:15:in `watchdog'
vendor/bundle/ruby/1.9.1/gems/sidekiq-2.11.2/lib/sidekiq/manager.rb:33:in `stop'
vendor/bundle/ruby/1.9.1/gems/celluloid-0.14.0/lib/celluloid/calls.rb:25:in `public_send'
vendor/bundle/ruby/1.9.1/gems/celluloid-0.14.0/lib/celluloid/calls.rb:25:in `dispatch'
vendor/bundle/ruby/1.9.1/gems/celluloid-0.14.0/lib/celluloid/calls.rb:125:in `dispatch'
vendor/bundle/ruby/1.9.1/gems/celluloid-0.14.0/lib/celluloid/actor.rb:328:in `block in handle_message'
vendor/bundle/ruby/1.9.1/gems/celluloid-0.14.0/lib/celluloid/tasks.rb:42:in `block in initialize'
vendor/bundle/ruby/1.9.1/gems/celluloid-0.14.0/lib/celluloid/tasks/task_fiber.rb:9:in `block in create'
I know the issue could easily be resolved by disconnecting anything that's using redis (e.g. sidekiq, rails cache_store) so that any subsequent commands that write to that node would reconnect with a valid connection.
The issue is where to catch and handle the exception? My initial thought was to do an airbrake kind of global rescue but not sure if that would be the best way to go about it.
Has anyone run into this issue?
Related
I get "No route matches" when Passbook, on iOS6, sends my server an HTTP DELETE route.
In config/routes.rb, the route looks like:
delete "/v1/devices/:device_id/registrations/:pass_type_id/:serial_number" => "registrations#destroy"
and when I run "rake routes" I can see the route is there:
DELETE /v1/devices/:device_id/registrations/:pass_type_id/:serial_number(.:format) {:controller=>"registrations", :action=>"destroy"}
but when the route comes in to the Rails 3.0.3 development server as
Started DELETE "/v1/devices/515a5c955dcdd66f558e1b4041392bf3/registrations/pass.com.myserver.FreeDrink/11" for 192.168.0.22 at 2012-12-23 15:03:25 -0500
the rails server says:
ActionController::RoutingError (No route matches "/v1/devices/515a5c955dcdd66f558e1b4041392bf3/registrations/pass.com.myserver.FreeDrink/11"):
actionpack (3.0.3) lib/action_dispatch/middleware/show_exceptions.rb:53:in `call'
railties (3.0.3) lib/rails/rack/logger.rb:13:in `call'
rack (1.2.4) lib/rack/runtime.rb:17:in `call'
activesupport (3.0.3) lib/active_support/cache/strategy/local_cache.rb:72:in `call'
rack (1.2.4) lib/rack/lock.rb:11:in `block in call'
<internal:prelude>:10:in `synchronize'
rack (1.2.4) lib/rack/lock.rb:11:in `call'
actionpack (3.0.3) lib/action_dispatch/middleware/static.rb:30:in `call'
railties (3.0.3) lib/rails/application.rb:168:in `call'
railties (3.0.3) lib/rails/application.rb:77:in `method_missing'
railties (3.0.3) lib/rails/rack/log_tailer.rb:14:in `call'
rack (1.2.4) lib/rack/content_length.rb:13:in `call'
rack (1.2.4) lib/rack/handler/webrick.rb:52:in `service'
/home/user/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
/home/user/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
/home/user/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'
All the other routes, using HTTP GET and POST work fine. This is the only route I'm having trouble with. I know that some browsers don't send HTTP DELETE, only HTTP GET and HTTP POST, and rails puts something in the header to indicate that the request is a delete, but it is Passbook that is sending the HTTP DELETE request, so I don't know if that has anything to do with the problem.
I've also tried other flavors of the route in config/routes.rb such as:
match "/v1/devices/:device_id/registrations/:pass_type_id/:serial_number" => "registrations#destroy", :via => :delete
and I've also tried using other controllers.
Any one know why Rails says that "No route matches" when the request is an HTTP DELETE?
I finally got the delete route to work by using the route from this post
delete "/v1/devices/:device_id/registrations/:pass_type_id/:serial_number" => "users#delete_pass", :constraints => { :pass_type_id => /[^\/]+/ }
which has the constraint added:
:constraints => { :pass_type_id => /[^\/]+/ }
I am trying to use devise from a Rails app to grant access to a Sinatra application within the Rack middleware.
My config/routes.rb has:
authenticate "admin" do
mount Admins::Dashboard, :at => "/admins"
end
In my Sinatra app, I use:
before do
env["warden"].authenticate!(:scope => "admin")
end
get "/dashboard" do
erb :dashboard
end
Now, I get an error with the following stacktrace:
Started GET "/admins/dashboard" for 127.0.0.1 at 2012-10-11 08:45:13 +0200
NoMethodError (undefined method `failure_app' for nil:NilClass):
devise (2.1.2) lib/devise/delegator.rb:11:in `failure_app'
devise (2.1.2) lib/devise/delegator.rb:5:in `call'
warden (1.2.1) lib/warden/manager.rb:130:in `call_failure_app'
warden (1.2.1) lib/warden/manager.rb:116:in `process_unauthenticated'
warden (1.2.1) lib/warden/manager.rb:47:in `call'
actionpack (3.2.8) lib/action_dispatch/middleware/best_standards_support.rb:17:in `call'
rack (1.4.1) lib/rack/etag.rb:23:in `call'
rack (1.4.1) lib/rack/conditionalget.rb:25:in `call'
The error message is a complaint about missing configuration for customizing the warden failure app to point to sinatra.
Check out this previous answer and the related (detailed) blogpost about setting up Sinatra+Warden & Rails+Devise; hopefully the instructions there will help you implement the solution successfully.
Had the same error message and this comment on Github helped me out.
In my sessions_controller.rb I had:
sign_in(:user, #resource, store: false, bypass: false)
which I replaced with:
sign_in(:users, #resource, store: false, bypass: false)
for it to work.
Specifically, the issue was only happening after one user would delete his account... Also I am using devise_token_auth (hence the overriden sessions controller).
Is there a way to change this behavior? i.e make Rails lazily get the connection from the pool and not when the request comes in.
We are using Postgres as a secondary source of data, so if that secondary source is down, app should not be affected and we want to rescue from that.
Right now when postgres goes down, all requests get affected.
Any inputs would be appreciated.
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/postgresql_adapter.rb:1213:in `initialize'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/postgresql_adapter.rb:1213:in `new'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/postgresql_adapter.rb:1213:in `connect'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/postgresql_adapter.rb:329:in `initialize'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/postgresql_adapter.rb:28:in `new'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/postgresql_adapter.rb:28:in `postgresql_connection'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:309:in `new_connection'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:319:in `checkout_new_connection'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:241:in `block (2 levels) in checkout'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:236:in `loop'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:236:in `block in checkout'
vendor/ruby-1.9.3/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:233:in `checkout'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:96:in `block in connection'
vendor/ruby-1.9.3/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:95:in `connection'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:404:in `retrieve_connection'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_specification.rb:170:in `retrieve_connection'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_specification.rb:144:in `connection'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/query_cache.rb:67:in `rescue in call'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/query_cache.rb:61:in `call'
vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:473:in `call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:405:in `_run__1061097989250305020__call__4547997776545495741__callbacks'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:405:in `__run_callback'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:385:in `_run_call_callbacks'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:81:in `run_callbacks'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/callbacks.rb:27:in `call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/remote_ip.rb:31:in `call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/debug_exceptions.rb:16:in `call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/rack/logger.rb:26:in `call_app'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/rack/logger.rb:16:in `call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/request_id.rb:22:in `call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/methodoverride.rb:21:in `call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/runtime.rb:17:in `call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/static.rb:62:in `call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:479:in `call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/application.rb:223:in `call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/railtie/configurable.rb:30:in `method_missing'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/deflater.rb:13:in `call'
vendor/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:535:in `process_client'
vendor/bundle/ruby/1.9.1/gems/unicorn-4.4.0/lib/unicorn/http_server.rb:610:in `worker_loop'
This is due to the QueryCache middleware. Unless you want to monkey patch it, you can just remove it from the middleware stack:
config.middleware.delete ActiveRecord::QueryCache
you might need to remove ActiveRecord::ConnectionAdapters::ConnectionManagement middleware as well.
I've just updated an app to rails 3.0.15, I'm not sure if that's the relevant bit, but I now get struct Arel::Attributes::Attribute not compatible (struct size differs) error right after running the server.
The log shows this:
tarted GET "/" for 127.0.0.1 at 2012-06-14 10:34:09 -0400
TypeError (struct Arel::Attributes::Attribute not compatible (struct size differs)):
Rendered gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/templates/rescues/_trace.erb (1.3ms)
SQL (1.9ms) describe `groups_users`
Rendered gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/templates/rescues/_request_and_response.erb (239.8ms)
Rendered gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/templates/rescues/diagnostics.erb within rescues/layout (244.9ms)
update
This problem seems to happen only when I use a certain url that loops back to localhost, namely live.dev:3000, it is fine with say localhost:3000, or another loop-back url.
This is the application trace
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/session_store.rb:58:in `load'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/session_store.rb:58:in `unmarshal'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/session_store.rb:131:in `data'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/session_store.rb:298:in `block in get_session'
gems/ruby/1.9.1/gems/activesupport-3.0.15/lib/active_support/benchmarkable.rb:55:in `silence'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/session_store.rb:294:in `get_session'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/session/abstract_store.rb:195:in `block in load_session'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/session/abstract_store.rb:223:in `stale_session_check!'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/session/abstract_store.rb:193:in `load_session'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/session/abstract_store.rb:121:in `load!'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/session/abstract_store.rb:113:in `load_for_read!'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/session/abstract_store.rb:53:in `[]'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/flash.rb:178:in `call'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/session/abstract_store.rb:149:in `call'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/cookies.rb:302:in `call'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/query_cache.rb:32:in `block in call'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/connection_adapters/abstract/query_cache.rb:28:in `cache'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/query_cache.rb:12:in `cache'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/query_cache.rb:31:in `call'
gems/ruby/1.9.1/gems/activerecord-3.0.15/lib/active_record/connection_adapters/abstract/connection_pool.rb:354:in `call'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/callbacks.rb:46:in `block in call'
gems/ruby/1.9.1/gems/activesupport-3.0.15/lib/active_support/callbacks.rb:416:in `_run_call_callbacks'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/callbacks.rb:44:in `call'
gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/sendfile.rb:106:in `call'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/remote_ip.rb:48:in `call'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/show_exceptions.rb:47:in `call'
gems/ruby/1.9.1/gems/railties-3.0.15/lib/rails/rack/logger.rb:13:in `call'
gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/runtime.rb:17:in `call'
gems/ruby/1.9.1/gems/activesupport-3.0.15/lib/active_support/cache/strategy/local_cache.rb:72:in `call'
gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/lock.rb:13:in `block in call'
<internal:prelude>:10:in `synchronize'
gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/lock.rb:13:in `call'
gems/ruby/1.9.1/gems/actionpack-3.0.15/lib/action_dispatch/middleware/static.rb:30:in `call'
gems/ruby/1.9.1/gems/railties-3.0.15/lib/rails/application.rb:168:in `call'
gems/ruby/1.9.1/gems/railties-3.0.15/lib/rails/application.rb:77:in `method_missing'
gems/ruby/1.9.1/gems/railties-3.0.15/lib/rails/rack/log_tailer.rb:14:in `call'
gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/content_length.rb:13:in `call'
gems/ruby/1.9.1/gems/rack-1.2.5/lib/rack/handler/webrick.rb:52:in `service'
/Users/victorstan/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
/Users/victorstan/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
/Users/victorstan/.rvm/rubies/ruby-1.9.2-p320/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'
I'm deploying my Rails 3 application to a Tomcat 6 server. I've been using warble to package my project up into a war file and so far have not had any troubles, until now. I just added a cache_sweeper to my application. When I tried hitting the application, I received the standard 500 error page.
Looking at my logs, I saw this:
org.jruby.rack.RackInitializationException: undefined method `cache_sweeper' for ApplicationController:Class
It can't find the cache_sweeper method? Isn't that part of Rails?
This doesn't happen while in development mode, though in development I'm using MRI ruby and using the rails server instead.
Anyone have any ideas?!
Full error:
SEVERE: Application Error
org.jruby.rack.RackInitializationException: undefined method `cache_sweeper' for ApplicationController:Class
from C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/app/controllers/application_controller.rb:239:in `require'
from C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/gems/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:239:in `require'
from C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/gems/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:227:in `load_dependency'
from C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/gems/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:239:in `require'
from C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/gems/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:346:in `require_or_load'
from C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/gems/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:491:in `load_missing_constant'
from C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/gems/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:183:in `const_missing'
from C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/gems/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:181:in `each'
... 39 levels...
from file:/C:/bin/apache-tomcat-6.0.29/webapps/rails3app/WEB-INF/lib/jruby-rack-1.0.3.jar!/vendor/rack-1.2.1/rack/builder.rb:46:in `initialize'
from <script>:2:in `new'
from <script>:2
at org.jruby.rack.DefaultRackApplicationFactory$4.init(DefaultRackApplicationFactory.java:184)
at org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:59)
at org.jruby.rack.PoolingRackApplicationFactory.getApplication(PoolingRackApplicationFactory.java:94)
at org.jruby.rack.servlet.DefaultServletDispatcher.process(DefaultServletDispatcher.java:36)
at org.jruby.rack.RackFilter.doFilter(RackFilter.java:59)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)
at java.lang.Thread.run(Thread.java:619)
For whatever reason, you have to include the module when using jruby/warble. However, this step is not necessary when using MRI and the rails server.
I added this to my ApplicationController and it worked:
class ApplicationController < ActionController::Base
include ActionController::Caching::Sweeping if defined?(JRUBY_VERSION)
...
end