DRb::DRbServerNotFound passing Sinatra params - ruby

Question

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.

Answer 1

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.