From: Nwallins <rick.hull@...>
Date: 2007-07-13T02:55:04+09:00
Subject: Re: DRb object mutation issues

On Jul 12, 1:46 pm, Nwallins <rick.h...@gmail.com> wrote:
> On Jul 11, 3:02 pm, Joel VanderWerf <v...@path.berkeley.edu> wrote:
>
>
>
> > Nwallins wrote:
> > > # file 1
> > > require 'drb/drb'
> > > require 'thread'
> > > DRb.start_service("druby://:1234", Hash.new.extend(DRbUndumped))
> > > DRb.thread.join
> > > # EOF
>
> > > # file 2
> > > require 'drb/drb'
> > > d = DRbObject.new_with_uri("druby://:1234")
> > > d[0] = 'zero'
> > > d[0] #=> "zero"
> > > d[0].slice!(0, 1)
> > > d[0] #=> "zero"
>
> > > # file 3
> > > h = Hash.new
> > > h[0] = 'zero'
> > > h[0].slice!(0, 1)
> > > h[0] #=> "ero"
>
> > > # how can I change the state of the distributed hash's values?
>
> > Some options:
>
> > 1. make the values DRbUndumped, too.
>
> > 2. use non-destructive methods on the values:
>
> >    d[0] = d[0].slice(0, 1)
>
> > 3. define a method on your front object that handles everything at
> > server side, so the client says this:
>
> >    idx = 0
> >    d.slice_at_index(idx,0,1)
>
> > --
> >        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
> Joel,
>
> thanks for the response.
>
> (1) is not viable, as you cannot make objects or classes undumpable
> from the client
> (2) does not address the issue -- to mutate the value
> (3) is interesting, but violates the architecture that my simplified
> example is distilled from
>
> I'm still wondering if the demonstrated behavior is a bug or a
> feature.  I'm leaning towards the former ;)
>
> - Rick

Regarding my comment for (1), I presume you mean something like this:

# file 2
require 'drb/drb'
d = DRbObject.new_with_uri("druby://:1234")
d[0] = 'zero'.extend(DRbUndumped)


# DRb::DRbConnError: DRb::DRbServerNotFound
#        from /usr/lib/ruby/1.8/drb/drb.rb:1650:in `current_server'

- Rick