Re: DRb question

Btw, this is with ruby-1.8.1 and dRuby 2.0.4 on a recent FreeBSD -current,
installed from ports. I should also add that what's weird is that the _second_
_identical_ call fails in the controller, i.e.:

    cp.execute_each_user(:load_file, args, usernames)
    puts "\n2nd call fails:"
    cp.execute_each_user(:load_file, args, usernames)

On Sun, Jan 04, 2004 at 06:06:46AM +0900, Shashank Date wrote:
> > I am trying to write a simple remote execution framework, and am running
> into a
> 
> Interesting ... keep us posted.

Sure.

> > DRb problem I can't seem to figure out. The system consists of a
> controller and
> > a number of clients; the controller sends commands to the clients (these
> > commands in turn will eventually talk to a server).
> 
> Looking at the code makes me feel that the controller is a DRb client
> and your client is actually a DRb server. Not a big issue at all ... just
> tripped
> me initially.
 
Yeah, that is why I gave the short description. The clients will eventually be
making HTTP calls to a web server, which is why I called them clients, even
though from the controller's perspective they are really servers.

> > The problem is that when I
> > make the same method call twice in a row I see the following error on the
> > controller side:
> >
> > Terminal A: running the client:
> >
> > lizzy:~/public_html/ruby/webrun% ./webrun-client.rb
> > Starting WebRun service on localhost:12345
> > WebRunClient.add(u1)
> > users=[u1]
> > cmd=load_file
> >
> > Terminal B: running the controller:
> >
> > lizzy:~/public_html/ruby/webrun% ./webrun-control.rb
> > assigning proxy for localhost
> > #<UserPool:0x8174ba8 @userlist={"u1"=>#<User:0x8174b30
> @client_class="Client_u1", @name="u1", @filename=nil, @thread=nil>}>
> > #<UserPool:0x8174234 @userlist={"u1"=>#<User:0x81741bc
> @client_class="Client_u1", @name="u1", @filename=nil, @thread=nil>}>
> > user u1 -> client localhost:12345
> > execute cmd load_file on client localhost:12345 for users [u1]
> >
> > 2nd call fails:
> > #<DRb::DRbUnknown:0x8172d44
> @buf="\004\010o:\rUserPool\006:\016@userlist{\006
>                 ^^^^^^^^^^^^^^^
> I tried hard to track down the source of this object ... but was not very
> successful :-(
 
Same here :-(

> > /webrun.rb:29:in `has_user?': undefined method `has_user?' for
> #<DRb::DRbUnknown:0x81719d0>
> 
> This was my starting point of investigation
> 
> > NoMethodError)
> >         from ./webrun.rb:82:in `where_is_user'
> >         from ./webrun.rb:80:in `each'
> >         from ./webrun.rb:75:in `each'
> >         from ./webrun.rb:75:in `each'
> >         from ./webrun.rb:87:in `where_is_user'
> >         from ./webrun.rb:138:in `execute_each_user'
> >         from ./webrun.rb:137:in `each'
> >         from ./webrun.rb:137:in `execute_each_user'
> >         from ./webrun-control.rb:17
> 
> <snip>
> 
> > Does anybody have any idea what I could be doing wrong or how to debug
> this
> > problem?
> 
> Well, I can point you to some obvious typos (see line 15 in webrun.rb):
> 
>       @proxy = DRbObject.new(nil, "druby://#@name:#@port")
>                                                                   ^^^^
> ^^^^
> Don't you want this to be:
> 
>      @proxy = DRbObject.new(nil, "druby://#{@name}:#{@port}")
> 
> Search for #@ in your code and you will find few more occurances
 
This syntax is actually permissible, see

    http://www.rubycentral.com/book/tut_classes.html

for some examples. It's smelly in some ways.

> And line 17:
> 
>      yield @proxy if block_given? and @proxy
> 
> I would rewrite as:
> 
>     yield @proxy if (block_given? and @proxy)
> 
> just to be on the safe side...."and" has very low precedence.
 
Fortunately it doesn't matter in this case. Thanks for the reminder though.

> Unfortunately, even after changing this and using ruby 1.8.1 on Win XP,
> I got the same errors as before. I tried running in the debugger mode (with
> -rdebug option) and I got even more errors, even for the first call.
> 
> All I can suggest is: try single-threaded, non-distributed version first, if
> possible
> and slowly introduce the more advanced features. Best of luck !
 
Thanks. I may have to simplify it some more. Taking out the threading stuff
didn't seem to make any difference though.

> -- shanko

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'