I just upgraded my rails project from rails 4.2 to rails 5.1.4. And after the upgrade my maincontroller started crashing. When i call it, it throws an error on the routes file, which states “uninitialized main controller”
After searching for a long time i set on my heroku server the config.cache_classes to false and everything worked all of a sudden. Though i’m unable to reproduce the logic on my local environment.
Anyone that has any idea where to search for a fix or how to fix this? I have been searching for days but without a single hit on what it might be!
Happy to provide any detail that anybody finds it usefully to help out! Just ask!
Ruby version 2.4.2
** EDIT - Added information as requested **
Full error is:
ActionController::RoutingError (uninitialized constant HomeController):
2017-11-26T15:16:55.051341+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/inflector/methods.rb:269:in `const_get'
2017-11-26T15:16:55.051342+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/inflector/methods.rb:269:in `block in constantize'
2017-11-26T15:16:55.051343+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/inflector/methods.rb:267:in `each'
2017-11-26T15:16:55.051343+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/inflector/methods.rb:267:in `inject'
2017-11-26T15:16:55.051344+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/inflector/methods.rb:267:in `constantize'
2017-11-26T15:16:55.051345+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:582:in `get'
2017-11-26T15:16:55.051346+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:613:in `constantize'
2017-11-26T15:16:55.051346+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/actionpack-5.1.4/lib/action_dispatch/http/request.rb:85:in `controller_class_for'
2017-11-26T15:16:55.051347+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/actionpack-5.1.4/lib/action_dispatch/http/request.rb:78:in `controller_class'
2017-11-26T15:16:55.051348+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/actionpack-5.1.4/lib/action_dispatch/routing/route_set.rb:43:in `controller'
2017-11-26T15:16:55.051348+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/actionpack-5.1.4/lib/action_dispatch/routing/route_set.rb:29:in `serve'
2017-11-26T15:16:55.051349+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/actionpack-5.1.4/lib/action_dispatch/journey/router.rb:50:in `block in serve'
2017-11-26T15:16:55.051350+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/actionpack-5.1.4/lib/action_dispatch/journey/router.rb:33:in `each'
2017-11-26T15:16:55.051350+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/actionpack-5.1.4/lib/action_dispatch/journey/router.rb:33:in `serve'
2017-11-26T15:16:55.051351+00:00 app[web.1]: vendor/bundle/ruby/2.4.0/gems/actionpack-5.1.4/lib/action_dispatch/routing/route_set.rb:834:in `call'
The controller is based in /myapp/app/HomeController.rb
class HomeController < ActionController::API
def click
# Execution of method, removed to keep post small
end
end
The routes file in the /myapp/config folder looks like:
Rails.application.routes.draw do
# root is set to a explainer json
root to: "home#not_found"
# New Routes
get '/clk', to: 'home#click'
# wildcard for any route not matched
get "*unmatched_route", to: "tracking#not_found"
end
Found the issue, It's related to a change in rails 5 for autoload paths.
now eager_load_paths should be used in the application.rb instead of autoload_paths
References:
https://github.com/rails/rails/commit/212ef5278b673aee304519d886d5db86a87b1437
https://blog.bigbinary.com/2016/08/29/rails-5-disables-autoloading-after-booting-the-app-in-production.html
Related
I trying to get ruby to read the source of a url thats being hosted on my own computer. I've tried using open-uri gem with:
source = open('http://127.0.0.1:8000/wikipedia_en_all_nopic_01_2012/A/Mick%20Jagger.html', &:read)
With normal external urls this works fine but it raises multiple errors when i try to access the url im hosting on my computer. Does anyone have any idea how to this? Heres the command line error report:
/Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http/response.rb:357:in `finish': incorrect header check (Zlib::DataError)
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http/response.rb:357:in `finish'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http/response.rb:262:in `ensure in inflater'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http/response.rb:262:in `inflater'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http/response.rb:274:in `read_body_0'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http/response.rb:201:in `read_body'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:328:in `block (2 levels) in open_http'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http.rb:1415:in `block (2 levels) in transport_request'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http/response.rb:162:in `reading_body'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http.rb:1414:in `block in transport_request'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http.rb:1405:in `catch'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http.rb:1405:in `transport_request'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http.rb:1378:in `request'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:319:in `block in open_http'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http.rb:853:in `start'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:313:in `open_http'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:723:in `buffer_open'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:210:in `block in open_loop'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:208:in `catch'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:208:in `open_loop'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:149:in `open_uri'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:703:in `open'
from /Users/rorycampbell/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/open-uri.rb:34:in `open'
from testurl.rb:6:in `<main>'
UPDATE: I'm using kiwix server to host the URL
Try using net/http instead.
require 'net/http'
source = Net::HTTP.get URI.parse('http://127.0.0.1:8000/wikipedia_en_all_nopic_01_2012/A/Mick%20Jagger.html')
Why do you want you use a URL if it's on the local machine? Why not just give the path?
That error sounds like there's something wrong with the actual file you're trying to parse, or the way it's being served by the way. From reading about Kiwix server it sounds like the latter...On the Kiwix site it says that it uses some type compression method called openzim which is most likely why open-uri can't find a way to parse it.
You could try nokogiri and see if it has a problem parsing it. But since it seems like you're trying to open/manipulate a zim file in ruby, I'd look for a zim library for ruby instead of trying to serve it.
Here:
https://github.com/chrisistuff/zim-ruby
I've never dealt with kiwix/zim, so I don't know if this one works but it was the only one the a google search for 'zim ruby' came back with.
I had the same problem with kiwix. I extracted all the URLs in a file called hrefs.txt (in my case it was the german project gutenberg) and used wget to download each of them:
f = File.open("hrefs.txt", "r")
f.each_line do |url|
#filename = url.split("/").last.gsub!(/[^A-Za-z]/, '')[0..-4]
system "wget #{url}"
end
f.close
I'm playing with Ruby / Sinatra at present and attempting to get HTTPS working.
I've taken a look at the rack:ssl gem here: https://github.com/josh/rack-ssl
It seems to be working when I run the application (as in redirecting to HTTPS), but nothing is displayed in the browser and the log comes up with the following error:
!! Invalid request
#!/usr/bin/env ruby
require 'rack/ssl'
require 'sinatra'
use Rack::SSL
get '/' do
'Hello World'
end
I'm not sure what to do from here.
Update:
Turned Thin Logging on in the sinatra app and got the following in the log:
!! Invalid request
Invalid HTTP format, parsing fails.
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/request.rb:82:in `execute'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/request.rb:82:in `parse'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/connection.rb:39:in `receive_data'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/backends/base.rb:63:in `start'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/server.rb:159:in `start'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/rack-1.5.2/lib/rack/handler/thin.rb:16:in `run'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1408:in `run!'
/Users/ashleycox/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/main.rb:25:in `block in <module:Sinatra>'
Any help would be greatly appreciated, thank you.
TLDR: Using require 'classname' in another model file (so I can deserialize a column) works locally but results in the No such file to load -- Classname error when deploying to Heroku.
I've made the admittedly poor design decision to serialize a model attribute which contains an array of another model's objects (UserCategoryQueue has a serialized queue of Card objects). In order to actually de-serialize these objects, I've followed the advice in YAML::load raises undefined class/module error to use require 'Card' in the files where I need to deserialize that column. That avoids the issue where YAML doesn't know what it's looking at when it gets to the Card object.
This works fine on the localhost server but has resulted in a lot of issues when deploying to Heroku, all of the form No such file to load -- Card". Initially, this occurred during the asset precompilation phase, then I precompiled the assets myself and the same error has moved to when I try to run $ heroku run rake db:migrate to get everything set up for the first time.
Sample Files:
# app/models/user_category_queue.rb
class UserCategoryQueue < ActiveRecord::Base
...
# Our queue of Cards
serialize :queue, Array
end
# app/models/quiz.rb
class Quiz < ActiveRecord::Base
...
require 'Card'
...
# grab a random card from the user's queues
# produces YAML error without the above require statement
def sample_card
self.user.user_category_queues.sample.queue.sample
end
end
This ultimately resulted in the following errors on pushing to Heroku (prior to any asset precompilation attempts on my part):
Running: rake assets:precompile
rake aborted!
No such file to load -- Card
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `block in require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:213:in `load_dependency'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/app/models/quiz.rb:18:in `<class:Quiz>'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/app/models/quiz.rb:1:in `<top (required)>'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `block in require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:213:in `load_dependency'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:329:in `require_or_load'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:288:in `depend_on'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:206:in `require_dependency'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/engine.rb:465:in `block (2 levels) in eager_load!'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/engine.rb:464:in `each'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/engine.rb:464:in `block in eager_load!'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/engine.rb:462:in `each'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/engine.rb:462:in `eager_load!'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/engine.rb:347:in `eager_load!'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/application/finisher.rb:56:in `each'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/application/finisher.rb:56:in `block in <module:Finisher>'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/initializable.rb:30:in `instance_exec'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/initializable.rb:30:in `run'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/initializable.rb:55:in `block in run_initializers'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/initializable.rb:54:in `run_initializers'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/application.rb:215:in `initialize!'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/railtie/configurable.rb:30:in `method_missing'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/config/environment.rb:5:in `<top (required)>'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `block in require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:213:in `load_dependency'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `require'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/application.rb:189:in `require_environment!'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/application.rb:249:in `block in run_tasks_blocks'
/tmp/build_d0e6e2b8-a3fd-4a90-ae44-e703b0093401/vendor/bundle/ruby/2.0.0/gems/sprockets-rails-2.0.0/lib/sprockets/rails/task.rb:54:in `block (2 levels) in define'
Tasks: TOP => environment
(See full trace by running task with --trace)
!
! Precompiling assets failed.
As I said, even when precompiling assets, though the push went fine, the ensuing database migration had the same error pop up.
Heroku runs a case-sensitive filesystem, whereas your OS may not be case-sensitive. Try changing that require to this instead:
require 'card'
As a general rule of thumb, most files within Ruby are required using lowercase letters with underscores serving as a word separator, like this:
require 'card_shuffler'
I have a Rails 3.1 application running on Heroku Cedar and it has a custom built Admin panel.
Admin is just a namespaced controller/view combination which live in controllers/admin and in views/admin.
I also 'namespaced' the assets: called them assets/javascripts/admin.js.coffe and assets/stylesheets/admin.css.scss and include both from layouts/admin/application.html.haml
Heroku perfectly compiles application.(css.scss|js.coffee) to a javascript/stylesheet files. When I visit frontend application it just works.
But when I visit '/admin' I get the following error:
When I visit website in production I get the following error:
2011-09-19T15:47:18+00:00 app[web.1]: /app/vendor/bundle/ruby/1.9.1/gems/execjs-1.2.5/lib/execjs/runtimes.rb:46:in `autodetect': Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/execjs-1.2.5/lib/execjs.rb:5:in `<module:ExecJS>'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/execjs-1.2.5/lib/execjs.rb:4:in `<top (required)>'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.1.0/lib/active_support/dependencies.rb:240:in `require'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.1.0/lib/active_support/dependencies.rb:240:in `block in require'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.1.0/lib/active_support/dependencies.rb:223:in `block in load_dependency'
2011-09-19T15:47:18+00:00 app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.1.0/lib/active_support/dependencies.rb:240:in `require'
2011-09-19T15:47:18+00:00 heroku[web.1]: Process exited
2011-09-19T15:47:20+00:00 heroku[web.1]: State changed from starting to crashed
According to Heroku's documentation I don't need to add gems like therubyracer-heroku to my gemfile. My admin asset files are manifest files and are similar to application asset manifests:
# application.js.coffee
#= require jquery
#= require jquery_ujs
# admin.js.coffee
#= require jquery
#= require jquery_ujs
Any thoughts?
Update 19 sept: As it turns out, admin assets are never compiled into public/assets and neither are present in public/assets/manifest.yml
Did you update your application's PATH, as also mentioned in the Heroku documentation you linked?
I had this same problem, adding 'bin' to the PATH solved it.
I have a Sinatra application and DRb server object paired. When I try to pass the Sinatra params hash to a method on my server object I get DRb::DRbConnError …
DRb::DRbServerNotFound, yet the same method works when I pass a simple hash directly.
Why am I getting this error with the Sinatra params hash?
What are the easiest and most correct workarounds to fix this problem?
Here's a simple test case:
# server.rb
require 'drb'
class Server; def echo( hash ); hash; end; end
DRb.start_service 'druby://localhost:9007', Server.new
DRb.thread.join
# app.rb
require 'sinatra'
require 'drb'
SERVER = DRbObject.new_with_uri 'druby://localhost:9007'
get("/params"){ SERVER.echo(params).inspect }
get("/hash" ){ SERVER.echo(hello:'world').inspect }
With both of these running in their own processes:
phrogz$ curl http://localhost:4567/hash
{:hello=>"world"}
phrogz$ curl http://localhost:4567/params
DRb::DRbConnError - DRb::DRbServerNotFound:
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1653:in `current_server'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1721:in `to_id'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1050:in `initialize'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:642:in `new'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:642:in `make_proxy'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:559:in `rescue in dump'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:556:in `dump'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:603:in `block in send_request'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:602:in `each'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:602:in `send_request'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:903:in `send_request'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1196:in `send_message'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1088:in `block (2 levels) in method_missing'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1172:in `open'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1087:in `block in method_missing'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1105:in `with_friend'
/usr/local/lib/ruby/1.9.1/drb/drb.rb:1086:in `method_missing'
app.rb:4:in `block in <main>'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:1152:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:1152:in `block in compile!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:724:in `instance_eval'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:724:in `route_eval'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:708:in `block (2 levels) in route!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:758:in `block in process_route'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:755:in `catch'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:755:in `process_route'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:707:in `block in route!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:706:in `each'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:706:in `route!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:843:in `dispatch!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:644:in `block in call!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `instance_eval'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `block in invoke'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `catch'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `invoke'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:644:in `call!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:629:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/head.rb:9:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/commonlogger.rb:18:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/showexceptions.rb:21:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/methodoverride.rb:24:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:1272:in `block in call'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:1303:in `synchronize'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:1272:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/content_length.rb:13:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/chunked.rb:15:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/thin-1.2.11/lib/thin/connection.rb:84:in `block in pre_process'
/usr/local/lib/ruby/gems/1.9.1/gems/thin-1.2.11/lib/thin/connection.rb:82:in `catch'
/usr/local/lib/ruby/gems/1.9.1/gems/thin-1.2.11/lib/thin/connection.rb:82:in `pre_process'
/usr/local/lib/ruby/gems/1.9.1/gems/thin-1.2.11/lib/thin/connection.rb:57:in `process'
/usr/local/lib/ruby/gems/1.9.1/gems/thin-1.2.11/lib/thin/connection.rb:42:in `receive_data'
/usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
/usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
/usr/local/lib/ruby/gems/1.9.1/gems/thin-1.2.11/lib/thin/backends/base.rb:61:in `start'
/usr/local/lib/ruby/gems/1.9.1/gems/thin-1.2.11/lib/thin/server.rb:159:in `start'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/handler/thin.rb:14:in `run'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/base.rb:1234:in `run!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.2.6/lib/sinatra/main.rb:25:in `block in <module:Sinatra>'
This is running under Ruby 1.9.2 on OS X, not that I think it makes a difference.
Short answer
You need to add
DRb.start_service
to app.rb before you try to make a remote call.
Explanation if you're interested
The Sinatra params hash is created with an associated block to handle the case when missing keys are referenced (here's the source). This means there's a Proc object associated with it.
Drb passes arguments back and forth by Marshalling them. However, from the Marshal docs:
Some objects cannot be dumped: if the objects to be dumped include bindings, procedure or method objects, instances of class IO, or singleton objects, a TypeError will be raised.
So there's going to be problems trying to pass this params hash about over the wire, as it contains an unmarshallable procedure object.
Now onto the Drb docs:
However, if an object cannot be marshalled, a dRuby reference to it is passed or returned instead. This will turn up at the remote end as a DRbObject instance. All methods invoked upon this remote proxy are forwarded to the local object, as described in the discussion of DRbObjects. This has semantics similar to the normal Ruby pass-by-reference.
Good news, it should still work. So what's wrong? A bit further on in the Drb docs we find this in the example code:
# Start a local DRbServer to handle callbacks.
#
# Not necessary for this small example, but will be required
# as soon as we pass a non-marshallable object as an argument
# to a dRuby call.
DRb.start_service
So what appears to be happening is Drb is trying to get a remote reference for the procedure object to pass to the server, but is unable as there's no Drb service set up client side.
Original answer
(I'll leave this here, it might me of interest. It was a resting point on my journey to figuring it all out. It's also a possible alternate solution. Interestingly, it appears that I'm now the more knowledgable person I referred to, at least with respect to the why.)
Here's a possible workaround. The problem seems to be with hashes created with a block to deal with missing keys (which Sinatra's params hash is), so you could extract the contents of the hash into a new one. params.clone and params.merge({}) both appear to retain the proc (you can check with Hash#default_proc), but {}.merge(params) (or merge!) gives you a nice clean hash that works with Drb.
So, in this example, do this:
get("/params"){ SERVER.echo({}.merge params).inspect
Why this happens with Drb and hashes with procs, and whether this is the easiest or most correct workaround, I'll leave to someone more knowledgable.