From: Eric Hodel <drbrain@...7.net>
Date: 2004-06-18T15:03:36-07:00
Subject: Re: Drb graceful shutdown

--oJAv8lSwuaQsYd0G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Carl Youngblood (carl.youngblood@gmail.com) wrote:

> On Sat, 19 Jun 2004 05:48:21 +0900, Eric Hodel <drbrain@segment7.net> wro=
te:
> >=20
> > Han Holl (han.holl@pobox.com) wrote:
> >=20
> > > As far as I can see from the source, there is no other way to end the
> > > connection to a remote object than through a raised exception.  Of
> > > course, most of the time this will be a connect error because the
> > > client just disconnects, but using ethereal I can see that the server
> > > still writes a complete backtrace to the socket.  Wouldn't it be
> > > desirable to have a more elegant way of disconnecting, or is there one
> > > that I just didn't see ?
> >=20
> > Nope!  There's no way to gracefully disconnect a DRb session, since you
> > may not know what all is still "alive" and being shared between servers.
> > Also note that there are not strict "clients" or "servers" in DRb, since
> > an object may be shared both ways.  At some time the "server" may try to
> > access a resource from the "client", even when it is long-gone, either
> > from the client disconnecting, or from the resource being
> > garbage-collected on the client side.
>
> So how do you gracefully shutdown your application?

You must be careful when designing an application that uses DRb so that
you know where remote references are created and ensure that they are
alive when you expect them to be alive, and die when you expect them to
die.

This is an example of what not to do:

class RemoteObj
  include DRbUndumped
  ...
end

class Server
  def get_resource
    return RemoteObj.new
  end
end

DRb.start_service nil, Server.new

In this case the server will return to the client a resource that will
dissappear after the GC gets run.  DRb has a mechanism to handle this,
id conversion, so that remotely referenced objects have a chance to stay
"alive" longer than the GC would let them.  Look at DRb::TimerIdConv
compared to DRb::DRbIdConv.  (For those of you not following along at
home, TimerIdConv uses a time-since-last-access to recycle remote
objects, while DRbIdConv uses ObjectSpace to retrieve objects.)

You could extend DRb::TimerIdConv to delay shutting down the DRb server
until after all remote objects expire.  Unfortunately, this brings you
to the choice of either waiting a long time to complete application
shutdown, or shutting down before the client processes are done with the
references.

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


--oJAv8lSwuaQsYd0G
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFA02a4MypVHHlsnwQRApX9AKC4PbzRf5CPy6eywy9czhrXs5btTgCfR8Jp
4XD3nSNNo7MbHK56a4PCm10=
=MA2j
-----END PGP SIGNATURE-----

--oJAv8lSwuaQsYd0G--