DRb cleaning up client objects created by clients

Discussion in 'Ruby' started by Aaron Turner, Jan 24, 2008.

  1. Aaron Turner

    Aaron Turner Guest

    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, Jan 24, 2008
    #1
    1. Advertising

  2. 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)
     
    Marcin Raczkowski, Jan 24, 2008
    #2
    1. Advertising

  3. Aaron Turner

    Aaron Turner Guest

    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, Jan 24, 2008
    #3
  4. 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
     
    Marcin Raczkowski, Jan 24, 2008
    #4
  5. Aaron Turner

    ara.t.howard Guest

    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
     
    ara.t.howard, Jan 24, 2008
    #5
  6. >
    > - use DRbUndumped to keep Foos on the server

    he mentioned that he's using that already
     
    Marcin Raczkowski, Jan 24, 2008
    #6
  7. Aaron Turner

    Aaron Turner Guest

    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
     
    Aaron Turner, Jan 24, 2008
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Francesco
    Replies:
    1
    Views:
    552
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Dec 27, 2006
  2. Miles Keaton
    Replies:
    3
    Views:
    205
    Miles Keaton
    Mar 30, 2005
  3. Kirk Haines

    More DRb; SSL & DRB & errors

    Kirk Haines, Jul 1, 2005, in forum: Ruby
    Replies:
    0
    Views:
    150
    Kirk Haines
    Jul 1, 2005
  4. J. Wook
    Replies:
    16
    Views:
    306
    Robert Klemme
    May 16, 2007
  5. Ittay Dror
    Replies:
    1
    Views:
    154
    Ittay Dror
    Oct 21, 2008
Loading...

Share This Page