DRb cleaning up client objects created by clients

A

Aaron Turner

Hopefully the below makes sense...

My DRb server's front object has a method called 'create_foo' which
creates & returns a new instance of class Foo. The Foo class must
keep track of the number of active Foo objects and enforces a limit.
Well behaved clients call my_foo_obj.free before releasing their
reference to my_foo_obj which updates the Foo class tracker. Of
course, not all clients are well behaved (they crash, user CTRL-C's
them, server they're on get rebooted, etc). The result is that stale
objects stay around indefinitely and are never marked as released in
the Foo class. Foo class leaks objects and ends up stoping creating
new ones.

I've tried creating a Foo.finalizer method which does the free(), but
that doesn't work, even when I force garbage collection. Both the
front object and Foo class are DRbUndumped.

Anyways, it would be great if there was a way for the DRb server to
detect a client has disconnected and react accordingly, but I can't
find any way to hook into the DRb class to do that. Suggestions?

--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin
 
M

Marcin Raczkowski

Aaron said:
Hopefully the below makes sense...

My DRb server's front object has a method called 'create_foo' which
creates & returns a new instance of class Foo. The Foo class must
keep track of the number of active Foo objects and enforces a limit.
Well behaved clients call my_foo_obj.free before releasing their
reference to my_foo_obj which updates the Foo class tracker. Of
course, not all clients are well behaved (they crash, user CTRL-C's
them, server they're on get rebooted, etc). The result is that stale
objects stay around indefinitely and are never marked as released in
the Foo class. Foo class leaks objects and ends up stoping creating
new ones.

I've tried creating a Foo.finalizer method which does the free(), but
that doesn't work, even when I force garbage collection. Both the
front object and Foo class are DRbUndumped.

Anyways, it would be great if there was a way for the DRb server to
detect a client has disconnected and react accordingly, but I can't
find any way to hook into the DRb class to do that. Suggestions?

It's problem with both GC and DRb.

finilizer will never be run becouse it's run just before object is
collected - since DRb is not releasing reference it's newer collected.

try using object proxy (delegator)
 
A

Aaron Turner

It's problem with both GC and DRb.

finilizer will never be run becouse it's run just before object is
collected - since DRb is not releasing reference it's newer collected.

That tends to agree with my research
try using object proxy (delegator)

Sorry not familiar with the module, concept or whatever you're
referring to. Link?

Thanks,
Aaron

--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin
 
M

Marcin Raczkowski

Aaron said:
That tends to agree with my research


Sorry not familiar with the module, concept or whatever you're
referring to. Link?

Thanks,
Aaron

On server side you define empty object that ovverwrites method_missing
and every call is transported to coresponding "real" object.

It's ugly hack, becouse proxy objects will never be collected unless
issue is fixed in DRb, but that should help with memory usage (almost
empty objects should not be really memory consuming)

and you can menage all the references server side.

If you are looking for better solution check packet and EventMachine,
BackgroundRB recently switched to Packet becouse of DRb issues.

cheers
 
A

ara.t.howard

My DRb server's front object has a method called 'create_foo' which
creates & returns a new instance of class Foo. The Foo class must
keep track of the number of active Foo objects and enforces a limit.
Well behaved clients call my_foo_obj.free before releasing their
reference to my_foo_obj which updates the Foo class tracker. Of
course, not all clients are well behaved (they crash, user CTRL-C's
them, server they're on get rebooted, etc). The result is that stale
objects stay around indefinitely and are never marked as released in
the Foo class. Foo class leaks objects and ends up stoping creating
new ones.

- use DRbUndumped to keep Foos on the server

- store all active Foos in a list

- provide a callback to the client when constructing the Foos,
possibly just a block passed to the method (since invocation of it
would run on the client)

- whenever a new Foos is requested sweep the list invoking the
callbacks/blocks. if the client has evaporated this will throw -
nuke the Foo from the list

a @ http://codeforpeople.com/
 
A

Aaron Turner

- use DRbUndumped to keep Foos on the server

- store all active Foos in a list

- provide a callback to the client when constructing the Foos,
possibly just a block passed to the method (since invocation of it
would run on the client)

- whenever a new Foos is requested sweep the list invoking the
callbacks/blocks. if the client has evaporated this will throw -
nuke the Foo from the list

Ah, yes, that should meet my needs. Thanks to everyone else who
responded with ideas.

--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top