JRuby

error accessing JRuby DRb server from MRI DRb client

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: JRuby 1.1
  • Fix Version/s: None
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Environment:
    MacOS 10.4.11, Java 1.5.0_13, JRuby trunk r5949
  • Number of attachments :
    1

Description

I'm not sure if this should work – I'd like it if it did.

DRb Server, run in JRuby

include Java
require 'drb' 
class TestServer 
  def method_missing(methodname, *args)
    klass = methodname.to_s
    methodd = args.delete_at(0)
    puts args.inspect
    puts methodd
    puts args.inspect
    the_script = "#{klass}.#{methodd}(*args)"
    puts the_script
    instance_eval(the_script)
  end
end 
server = TestServer.new 
DRb.start_service('druby://localhost:9000', server) 
DRb.thread.join # Don't exit just yet!

DRb client

require 'drb' 
DRb.start_service() 
obj = DRbObject.new(nil, 'druby://localhost:9000') 
puts obj.java.lang.System.getProperties["java.runtime.version"]

When the client is run in JRuby (the result is correct):

1.5.0_13-b05-241

When the client is run in MRI 1.8.6

TypeError: wrong argument type String (expected Module)
        from (druby://localhost:9000) /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/1.8/drb/drb.rb:1538:in `check_insecure_method'
        from (druby://localhost:9000) /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/1.8/drb/drb.rb:1543:in `setup_message'
        from (druby://localhost:9000) /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/1.8/drb/drb.rb:1494:in `perform'
        from (druby://localhost:9000) /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/1.8/drb/drb.rb:1589:in `main_loop'
        from (druby://localhost:9000) /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/1.8/drb/drb.rb:1585:in `loop'
        from (druby://localhost:9000) /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/1.8/drb/drb.rb:1585:in `main_loop'
        from (druby://localhost:9000) /Users/stephen/dev/jruby_trunk/jruby/lib/ruby/1.8/drb/drb.rb:1585:in `accept'
        from (irb):4

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

Perhaps you could raise this with Ruby core? I'm punting this to post 1.1, since there's perhaps nothing here we should actually fix, but if there's a reason for the error in C Ruby, maybe we will want to consider whether we duplicate it.

Show
Charles Oliver Nutter added a comment - Perhaps you could raise this with Ruby core? I'm punting this to post 1.1, since there's perhaps nothing here we should actually fix, but if there's a reason for the error in C Ruby, maybe we will want to consider whether we duplicate it.
Hide
Permalink
Charles Oliver Nutter added a comment -

I've got good news and bad news. The good news is that we match MRI exactly now. The bad news is that the behavior you wanted is now gone. If you can take this up with ruby-core and make progress toward the original behavior, we can try to reinstate it.

Show
Charles Oliver Nutter added a comment - I've got good news and bad news. The good news is that we match MRI exactly now. The bad news is that the behavior you wanted is now gone. If you can take this up with ruby-core and make progress toward the original behavior, we can try to reinstate it.
Hide
Permalink
Riley Lynch added a comment -

There may be a lingering incompatibility here. An MRI server will return a (mocked-up) Java::Java module which is unknown to an MRI client as DRb::DRbUnknown. But a JRuby server returns the (real) Java::Java module to an MRI client as a DRBObject, but one which appears to be a reference to the name of the module rather than to the module itself. (Hence the "wrong argument type String (expected Module)" error.) This is probably worth looking into.

Regarding the submitter's request ("I'm not sure if this should work - I'd like it if it did."), there are issues beyond the scope of DRb which would need to be addressed in order for the sample code – or something similar – to work. The main problem is that arbitrary Java objects can't be marshaled and reconstructed by DRb. It might be possible to extend DRb for JRuby clients so that DRB worked with Serializable objects, but this still wouldn't cover the case of an MRI client. That said, it's possible to use DRb::Undumpable and a wrapper class to achieve something like the desired effect. (Sample server code attached.)

Show
Riley Lynch added a comment - There may be a lingering incompatibility here. An MRI server will return a (mocked-up) Java::Java module which is unknown to an MRI client as DRb::DRbUnknown. But a JRuby server returns the (real) Java::Java module to an MRI client as a DRBObject, but one which appears to be a reference to the name of the module rather than to the module itself. (Hence the "wrong argument type String (expected Module)" error.) This is probably worth looking into. Regarding the submitter's request ("I'm not sure if this should work - I'd like it if it did."), there are issues beyond the scope of DRb which would need to be addressed in order for the sample code – or something similar – to work. The main problem is that arbitrary Java objects can't be marshaled and reconstructed by DRb. It might be possible to extend DRb for JRuby clients so that DRB worked with Serializable objects, but this still wouldn't cover the case of an MRI client. That said, it's possible to use DRb::Undumpable and a wrapper class to achieve something like the desired effect. (Sample server code attached.)
Hide
Permalink
Riley Lynch added a comment -

Clarification: A JRuby server also returns a Java::Java module which is unknown to a JRuby client as a DRbObject. Interestingly, if the Java module is included in the client, then the marshalled module is unmarshalled as a Module, and the sample client code works.

Show
Riley Lynch added a comment - Clarification: A JRuby server also returns a Java::Java module which is unknown to a JRuby client as a DRbObject. Interestingly, if the Java module is included in the client, then the marshalled module is unmarshalled as a Module, and the sample client code works.
Hide
Permalink
Riley Lynch added a comment -

See also JRUBY-1235 for another issue related to marshalling Java objects.

Show
Riley Lynch added a comment - See also JRUBY-1235 for another issue related to marshalling Java objects.
Hide
Permalink
Riley Lynch added a comment -

Upon further inspection, there's no incompatibility here in terms of how modules are marshaled: The package module Java::Java is created in the java layer rather than in the ruby layer, and so is not considered a module for purposes of marshaling – so the remaining issue is essentially a duplicate of RUBY-1235.

Show
Riley Lynch added a comment - Upon further inspection, there's no incompatibility here in terms of how modules are marshaled: The package module Java::Java is created in the java layer rather than in the ruby layer, and so is not considered a module for purposes of marshaling – so the remaining issue is essentially a duplicate of RUBY-1235.
Hide
Permalink
Charles Oliver Nutter added a comment -

Marking as duplicate of JRUBY-1235, per Riley's comment.

Show
Charles Oliver Nutter added a comment - Marking as duplicate of JRUBY-1235 , per Riley's comment.

People

  • Assignee:
    Unassigned
    Reporter:
    Stephen Bannasch
Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: