DRb: remote methods not running remotely?

I have a drb server on one machine, which is basically started with:

def server(uri)
    puts "uri is #{uri}, self is #{self}"
    primary = DRb::DRbServer.new(uri, self)
    # May want to do something else here.
    p primary.class.ancestors
    return primary
end

called with “druby://:0”

I then have a client, which is given the resulting url, and started
like this:

    @remote_server = remote_server(serverURI)[1]

where

def remote_server(uri)
    primary = DRb::DRbServer.new
    remote = DRb::DRbObject.new(nil, uri)
    puts "in #{caller()}, <Contractor> remote is #{remote}"
    return primary, remote
end

and uri is that obtained from the running server. I.e. I’m using
the server to share work out to the clients, who do the fragments
for the server.

Fine. However, after the client connects to the server object
(which it does successfully) when the server invokes a method of the
client’s, that method is exected on the server machine, not on the
client machine.

I know this because I created a instance method of the client class:

def ping
    x = "#{caller(0)[0]} #{Socket.gethostname} #{$$}"
    puts x
    return x
end

which always yields the name of the server machine, not the client
machine. Plus the print statements appear in the wrong window.
Furthermore, when the client sees code in the server running the
caller(0)[0] is a druby uri, but when my server runs client methods
the calller(0)[0] is just a normal file:line_number type expression

Is there anything I have missed in this?

How can I test an object in a server to see if it is remote or local?

Will certain kinds of objects always end up as local after being
sent to a server – if for example they contain references to IO
objects which cannot be marshalled, or maybe references to the
sever?

The thing is, I’m fairly sure the simplified version of this code
worked when it doe no I/O or serious work.

    Thank you,
    Hugh

IIRC any object you return that does not include DRbUndumped will
be marshalled and returned to the client side.

···

Hugh Sasse Staff Elec Eng (hgs@dmu.ac.uk) wrote:

How can I test an object in a server to see if it is remote or local?

Will certain kinds of objects always end up as local after being
sent to a server – if for example they contain references to IO
objects which cannot be marshalled, or maybe references to the
sever?

The thing is, I’m fairly sure the simplified version of this code
worked when it doe no I/O or serious work.


Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

How can I test an object in a server to see if it is remote or local?

Will certain kinds of objects always end up as local after being
sent to a server – if for example they contain references to IO
objects which cannot be marshalled, or maybe references to the
sever?

The thing is, I’m fairly sure the simplified version of this code
worked when it doe no I/O or serious work.

IIRC any object you return that does not include DRbUndumped will
be marshalled and returned to the client side.

OK, I have not mixed that into the client class myself…
If I do client.kind_of?(DRbUndumped) I get “false”, which is what
I’d expect. So the client methods should run on the client then?


Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

    Hugh
···

On Tue, 11 Mar 2003, Eric Hodel wrote:

Hugh Sasse Staff Elec Eng (hgs@dmu.ac.uk) wrote:

Well, I’ve done further tests on this, and while I still can’t get
it to run the code on the right machine, I now know that:
All the instance vars of the client give false in response to
.kind_of(DRbUndumped);
That when the client is marshalled (a) it happens successfully and
(b) I get something like:
marshalling…
“\004\006o:\016TlmClient\t:\f@configo:\024TlmClientConfig\v:\v@table{\t"\vidfile"\020@ident_file"\010tmp"\n@temp"\010uri"\016@uri_page"\niddir"\017@ident_dir:\016@uri_page"?http:///URIs.txt:\017@ident_dir"\rPTlmUIds:\020@ident_file"\020PTlmIds.txt:\n@temp"\t/tmp:\017@conf_file"\rTlm.conf:\023@remote_serveru:\023DRb::DRbObject
\004\006[\a"\031druby://neelix:464390:\v@ident"\fsasse01:\016@skillseto:\rSkillset\006;\021c\016TlmClient”
…marshalled

from
$stderr.puts “marshalling…”
$stderr.puts data.inspect
$stderr.puts “…marshalled”
So that looks fairly sensible (except that the
has the correct value, which I’m not publishing yet.

    Hugh
···

On Tue, 11 Mar 2003, Hugh Sasse Staff Elec Eng wrote:

On Tue, 11 Mar 2003, Eric Hodel wrote:

Hugh Sasse Staff Elec Eng (hgs@dmu.ac.uk) wrote:

How can I test an object in a server to see if it is remote or local?

Will certain kinds of objects always end up as local after being
sent to a server – if for example they contain references to IO
objects which cannot be marshalled, or maybe references to the
sever?

The thing is, I’m fairly sure the simplified version of this code
worked when it doe no I/O or serious work.

IIRC any object you return that does not include DRbUndumped will
be marshalled and returned to the client side.

OK, I have not mixed that into the client class myself…
If I do client.kind_of?(DRbUndumped) I get “false”, which is what
I’d expect. So the client methods should run on the client then?

A while back I posted a message about how UnDumped makes things behave
in response to a question by ahoward. You should be able to find it in
the archives. If not, I may be able to dig the subject from my outgoing
folder.

···

Hugh Sasse Staff Elec Eng (hgs@dmu.ac.uk) wrote:

On Tue, 11 Mar 2003, Hugh Sasse Staff Elec Eng wrote:

On Tue, 11 Mar 2003, Eric Hodel wrote:

Hugh Sasse Staff Elec Eng (hgs@dmu.ac.uk) wrote:

How can I test an object in a server to see if it is remote or local?

Will certain kinds of objects always end up as local after being
sent to a server – if for example they contain references to IO
objects which cannot be marshalled, or maybe references to the
sever?

IIRC any object you return that does not include DRbUndumped will
be marshalled and returned to the client side.

OK, I have not mixed that into the client class myself…
If I do client.kind_of?(DRbUndumped) I get “false”, which is what
I’d expect. So the client methods should run on the client then?

Well, I’ve done further tests on this, and while I still can’t get
it to run the code on the right machine, I now know that:
All the instance vars of the client give false in response to
.kind_of(DRbUndumped);


Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

The one that really stood out is the thread that really gets going
at Ruby-Talk:63281. Is that the one you meant?

If so, I think I understand that: undumped will mean the object
remains on the machine that serves the object. OK, but my situation
differs slightly from that example in so far as – call the
machines/programs A and B, and the objects o and p for the sake of
clarity:

A serves the front object o to B # that’s the same
B uses o to pass p to A # that’s the same
A calls p.meth, but it runs on A . # That differs…

So…if I want p to always run on B I should include DRbUndumped in
it?

Once I have a better black-box model of how to use this I’ll feel
more confident about studying the code in greater depth.

    Thank you,
    Hugh
···

On Tue, 11 Mar 2003, Eric Hodel wrote:

Well, I’ve done further tests on this, and while I still can’t get
it to run the code on the right machine, I now know that:
All the instance vars of the client give false in response to
.kind_of(DRbUndumped);

A while back I posted a message about how UnDumped makes things behave
in response to a question by ahoward. You should be able to find it in
the archives. If not, I may be able to dig the subject from my outgoing
folder.

A while back I posted a message about how UnDumped makes things behave
in response to a question by ahoward. You should be able to find it in
the archives. If not, I may be able to dig the subject from my outgoing
folder.

The one that really stood out is the thread that really gets going
at Ruby-Talk:63281. Is that the one you meant?

So…if I want p to always run on B I should include DRbUndumped in
it?

Well, I tried this out today, and it seems to be working fairly
well, now, apart from my other bugs :slight_smile: Thank you for pushing me in
the right direction. If you have more to add to this I’d be
grateful for any further insight.

    Thank you,
    Hugh
···

On Tue, 11 Mar 2003, Hugh Sasse Staff Elec Eng wrote:

On Tue, 11 Mar 2003, Eric Hodel wrote:

A while back I posted a message about how UnDumped makes things behave
in response to a question by ahoward. You should be able to find it in
the archives. If not, I may be able to dig the subject from my outgoing
folder.

The one that really stood out is the thread that really gets going
at Ruby-Talk:63281. Is that the one you meant?

Yep

So…if I want p to always run on B I should include DRbUndumped in
it?

Well, I tried this out today, and it seems to be working fairly
well, now, apart from my other bugs :slight_smile: Thank you for pushing me in
the right direction. If you have more to add to this I’d be
grateful for any further insight.

Remember that DRb is bi-directional, you create and pass objects back
and forth from each end. (Or proxied objects)

···

Hugh Sasse Staff Elec Eng (hgs@dmu.ac.uk) wrote:

On Tue, 11 Mar 2003, Hugh Sasse Staff Elec Eng wrote:

On Tue, 11 Mar 2003, Eric Hodel wrote:


Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

the right direction. If you have more to add to this I’d be
grateful for any further insight.

Remember that DRb is bi-directional, you create and pass objects back
and forth from each end. (Or proxied objects)

Thanks, I’ll bear that in mind.


Eric Hodel - drbrain@segment7.net - http://segment7.net

    Hugh
···

On Wed, 12 Mar 2003, Eric Hodel wrote:

Hugh Sasse Staff Elec Eng (hgs@dmu.ac.uk) wrote:

On Tue, 11 Mar 2003, Hugh Sasse Staff Elec Eng wrote: