Exceptions cause DRb connection to be closed
If an exception is thrown in a DRb server of a class that is not defined in the client process, the DRb connection is closed abrubtly. In Ruby 1.8, the exception was translated to an instance generic exception class (DRb::DRbRemoteError).
Steps to reproduce:
- Start DRb client+server
- Throw exception of custom class in server (class not defined in client script).
- Client raises DRb::DRbConnError because connection is closed - used to be generic error.
- Client raises DRb::DRbRemoteError, and preserves full stack trace from server.
Attached is server/client script showing the problem.
Here is the stack trace of the client:
load': connection closed (DRb::DRbConnError) from C:/lang/Ruby193/lib/ruby/1.9.1/drb/drb.rb:632:in recv_reply'
recv_reply' from C:/lang/Ruby193/lib/ruby/1.9.1/drb/drb.rb:1197:in send_message'
block (2 levels) in method_missing' from C:/lang/Ruby193/lib/ruby/1.9.1/drb/drb.rb:1172:in open'
block in method_missing' from C:/lang/Ruby193/lib/ruby/1.9.1/drb/drb.rb:1105:in with_friend'
method_missing' from drbclient.rb:3:in '
Updated by ko1 (Koichi Sasada) about 11 years ago
- Category set to lib
- Assignee set to seki (Masatoshi Seki)
Updated by shyouhei (Shyouhei Urabe) about 11 years ago
- Status changed from Open to Assigned
Updated by felixbuenemann (Felix Bünemann) about 8 years ago
This issue still exists in Ruby 2.1.5.
Updated by jeremyevans0 (Jeremy Evans) over 3 years ago
This issue is unrelated to whether the client defines the same exception class as the server, and the behavior in my testing appears to be the same on 1.8 as in the master branch.
The underlying issue is that the example code here uses a subclass of
DRb::DRbServer::InvokeMethod#perform does not rescue
Exception. Attached is a patch that fixes this issue.
Updated by jeremyevans (Jeremy Evans) over 3 years ago
- Status changed from Assigned to Closed
Applied in changeset git|50b8033d6b7404670ee985de1473fffc10dd7d9c.
Handle subclasses of Exception in drb
This makes it so that client instances that call a method on a
server-side object that raise a subclass of Exception are handled
similarly to those that raise a subclass of StandardError.
Only reraise exceptions that we are fairly sure we don't want to
Fixes [Bug #5618]