«

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

Aaron Turner wrote:
> 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)

On Jan 23, 2008 9:48 PM, Marcin Raczkowski <> wrote:
>
> 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

Aaron Turner wrote:
> On Jan 23, 2008 9:48 PM, Marcin Raczkowski <> wrote:
>> 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
>

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

On Jan 23, 2008, at 10:12 PM, Aaron Turner wrote:

>
> 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/
--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama

>
> - use DRbUndumped to keep Foos on the server
he mentioned that he's using that already

On Jan 24, 2008 12:33 AM, ara.t.howard <> wrote:
> - 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