[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Lease on Life Sponsor Question

lfiedler

10/14/2004 8:56:00 PM

I have a few questions on how to make sure remoted objects leases don't
expire when they are needed, but also are garbage collected when not needed
anymore. I believe I have a solution, but would like others' opinions and
solutions.

Basically, in my programming model, any node that remotes an object will
keep a reference to that object until the clients are done w/ it and until
the node is done w/ it. When all references are removed, it's up for
garbage collection. So, to make sure the lease on life doesn't expire on
these remoted objects, I was going to extend the marshalbyrefobject class
have a sponsor associated w/ it. When the sponsor gets notified that the
lease on life is going to expire and the KILL flag isn't set just add time
to it. When the reference to the remoted object in the serving node is
removed, a kill() method on the object is also called, setting the KILL
flag.

So the kill method kindof acts like the delete keyword in c++, only that the
memory isn't freed until the lease on life expires and until the garbage
collection gets it. So, it really doesn't act like it, but the programmers
call kill like delete.

But, this brings up a point, if a programmer doesn't call the kill() method,
then the object will live forever - thus introducing possible memory leaks.
So what's the point in having all this nice garbage collection stuff if you
can still have memory leaks?
5 Answers

Sam Santiago

10/14/2004 10:00:00 PM

0

Sounds like your approach should work. The kill() method would have to be
called for it to work as expected. You could also try keeping the sponsor
on your client, when your client is done with the remote object or exits,
unregister the sponsor or dereference it so that the sponsor is garbage
collected. If your sponsor cannot be reached at lease renewal time, I'm
assuming the remote object's lease will expire (I haven't tried this to
verify). Garbage collection becomes more complicated across app domain
boundaries, so you're still vulnerable to memory leaks.



Thanks,

Sam

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"nospam" <lfiedler@cc.gatech.edu> wrote in message
news:43deea51.0410141255.64e401dd@posting.google.com...
> I have a few questions on how to make sure remoted objects leases don't
> expire when they are needed, but also are garbage collected when not
needed
> anymore. I believe I have a solution, but would like others' opinions and
> solutions.
>
> Basically, in my programming model, any node that remotes an object will
> keep a reference to that object until the clients are done w/ it and until
> the node is done w/ it. When all references are removed, it's up for
> garbage collection. So, to make sure the lease on life doesn't expire on
> these remoted objects, I was going to extend the marshalbyrefobject class
> have a sponsor associated w/ it. When the sponsor gets notified that the
> lease on life is going to expire and the KILL flag isn't set just add time
> to it. When the reference to the remoted object in the serving node is
> removed, a kill() method on the object is also called, setting the KILL
> flag.
>
> So the kill method kindof acts like the delete keyword in c++, only that
the
> memory isn't freed until the lease on life expires and until the garbage
> collection gets it. So, it really doesn't act like it, but the programmers
> call kill like delete.
>
> But, this brings up a point, if a programmer doesn't call the kill()
method,
> then the object will live forever - thus introducing possible memory
leaks.
> So what's the point in having all this nice garbage collection stuff if
you
> can still have memory leaks?

unknown

10/14/2004 10:30:00 PM

0

I like the idea of having the logic/control on the client because it
relieves the need to keep the reference on the server. But having another
object that you basically have to carry around w/ the remoting object can
get kindof ugly/messy.

"Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
news:OP7qzkjsEHA.2128@TK2MSFTNGP11.phx.gbl...
> Sounds like your approach should work. The kill() method would have to be
> called for it to work as expected. You could also try keeping the sponsor
> on your client, when your client is done with the remote object or exits,
> unregister the sponsor or dereference it so that the sponsor is garbage
> collected. If your sponsor cannot be reached at lease renewal time, I'm
> assuming the remote object's lease will expire (I haven't tried this to
> verify). Garbage collection becomes more complicated across app domain
> boundaries, so you're still vulnerable to memory leaks.
>
>
>
> Thanks,
>
> Sam
>
> --
> _______________________________
> Sam Santiago
> ssantiago@n0spam-SoftiTechture.com
> http://www.SoftiTe...
> _______________________________
> "nospam" <lfiedler@cc.gatech.edu> wrote in message
> news:43deea51.0410141255.64e401dd@posting.google.com...
> > I have a few questions on how to make sure remoted objects leases don't
> > expire when they are needed, but also are garbage collected when not
> needed
> > anymore. I believe I have a solution, but would like others' opinions
and
> > solutions.
> >
> > Basically, in my programming model, any node that remotes an object will
> > keep a reference to that object until the clients are done w/ it and
until
> > the node is done w/ it. When all references are removed, it's up for
> > garbage collection. So, to make sure the lease on life doesn't expire
on
> > these remoted objects, I was going to extend the marshalbyrefobject
class
> > have a sponsor associated w/ it. When the sponsor gets notified that
the
> > lease on life is going to expire and the KILL flag isn't set just add
time
> > to it. When the reference to the remoted object in the serving node is
> > removed, a kill() method on the object is also called, setting the KILL
> > flag.
> >
> > So the kill method kindof acts like the delete keyword in c++, only that
> the
> > memory isn't freed until the lease on life expires and until the garbage
> > collection gets it. So, it really doesn't act like it, but the
programmers
> > call kill like delete.
> >
> > But, this brings up a point, if a programmer doesn't call the kill()
> method,
> > then the object will live forever - thus introducing possible memory
> leaks.
> > So what's the point in having all this nice garbage collection stuff if
> you
> > can still have memory leaks?
>
>

Sam Santiago

10/14/2004 11:34:00 PM

0

The object is not literally carried around with the remoting object. It is
strictly registered as a sponsor of that object that is notified by the
lease manager. Check out the ClientSponsor class:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemruntimeremotinglifetimeclientsponsorclas...

Thanks,

Sam

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"nospam" <nospam@nospam.com> wrote in message
news:T5Dbd.4$k01.2@dfw-service2.ext.ray.com...
> I like the idea of having the logic/control on the client because it
> relieves the need to keep the reference on the server. But having another
> object that you basically have to carry around w/ the remoting object can
> get kindof ugly/messy.
>
> "Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
> news:OP7qzkjsEHA.2128@TK2MSFTNGP11.phx.gbl...
> > Sounds like your approach should work. The kill() method would have to
be
> > called for it to work as expected. You could also try keeping the
sponsor
> > on your client, when your client is done with the remote object or
exits,
> > unregister the sponsor or dereference it so that the sponsor is garbage
> > collected. If your sponsor cannot be reached at lease renewal time, I'm
> > assuming the remote object's lease will expire (I haven't tried this to
> > verify). Garbage collection becomes more complicated across app domain
> > boundaries, so you're still vulnerable to memory leaks.
> >
> >
> >
> > Thanks,
> >
> > Sam
> >
> > --
> > _______________________________
> > Sam Santiago
> > ssantiago@n0spam-SoftiTechture.com
> > http://www.SoftiTe...
> > _______________________________
> > "nospam" <lfiedler@cc.gatech.edu> wrote in message
> > news:43deea51.0410141255.64e401dd@posting.google.com...
> > > I have a few questions on how to make sure remoted objects leases
don't
> > > expire when they are needed, but also are garbage collected when not
> > needed
> > > anymore. I believe I have a solution, but would like others' opinions
> and
> > > solutions.
> > >
> > > Basically, in my programming model, any node that remotes an object
will
> > > keep a reference to that object until the clients are done w/ it and
> until
> > > the node is done w/ it. When all references are removed, it's up for
> > > garbage collection. So, to make sure the lease on life doesn't expire
> on
> > > these remoted objects, I was going to extend the marshalbyrefobject
> class
> > > have a sponsor associated w/ it. When the sponsor gets notified that
> the
> > > lease on life is going to expire and the KILL flag isn't set just add
> time
> > > to it. When the reference to the remoted object in the serving node
is
> > > removed, a kill() method on the object is also called, setting the
KILL
> > > flag.
> > >
> > > So the kill method kindof acts like the delete keyword in c++, only
that
> > the
> > > memory isn't freed until the lease on life expires and until the
garbage
> > > collection gets it. So, it really doesn't act like it, but the
> programmers
> > > call kill like delete.
> > >
> > > But, this brings up a point, if a programmer doesn't call the kill()
> > method,
> > > then the object will live forever - thus introducing possible memory
> > leaks.
> > > So what's the point in having all this nice garbage collection stuff
if
> > you
> > > can still have memory leaks?
> >
> >
>
>

unknown

10/15/2004 1:15:00 AM

0

ahh. that's pretty cool. so basically on each client I could have a
singleton ClientSponsor. And whenever I get a remoted object from the
server, I can register it w/ the single ClientSponsor. When I'm done w/ the
remoted object, I can unregister it. The server should contact my
ClientSponsor when the lease is about to expire on any of the registered
objects, and then the clientsponsor should simple renew the lease.
-Lars


"Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
news:uaDcAZksEHA.2300@TK2MSFTNGP09.phx.gbl...
> The object is not literally carried around with the remoting object. It
is
> strictly registered as a sponsor of that object that is notified by the
> lease manager. Check out the ClientSponsor class:
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/c...
frlrfsystemruntimeremotinglifetimeclientsponsorclasstopic.asp
>
> Thanks,
>
> Sam
>
> --
> _______________________________
> Sam Santiago
> ssantiago@n0spam-SoftiTechture.com
> http://www.SoftiTe...
> _______________________________
> "nospam" <nospam@nospam.com> wrote in message
> news:T5Dbd.4$k01.2@dfw-service2.ext.ray.com...
> > I like the idea of having the logic/control on the client because it
> > relieves the need to keep the reference on the server. But having
another
> > object that you basically have to carry around w/ the remoting object
can
> > get kindof ugly/messy.
> >
> > "Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
> > news:OP7qzkjsEHA.2128@TK2MSFTNGP11.phx.gbl...
> > > Sounds like your approach should work. The kill() method would have
to
> be
> > > called for it to work as expected. You could also try keeping the
> sponsor
> > > on your client, when your client is done with the remote object or
> exits,
> > > unregister the sponsor or dereference it so that the sponsor is
garbage
> > > collected. If your sponsor cannot be reached at lease renewal time,
I'm
> > > assuming the remote object's lease will expire (I haven't tried this
to
> > > verify). Garbage collection becomes more complicated across app
domain
> > > boundaries, so you're still vulnerable to memory leaks.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Sam
> > >
> > > --
> > > _______________________________
> > > Sam Santiago
> > > ssantiago@n0spam-SoftiTechture.com
> > > http://www.SoftiTe...
> > > _______________________________
> > > "nospam" <lfiedler@cc.gatech.edu> wrote in message
> > > news:43deea51.0410141255.64e401dd@posting.google.com...
> > > > I have a few questions on how to make sure remoted objects leases
> don't
> > > > expire when they are needed, but also are garbage collected when not
> > > needed
> > > > anymore. I believe I have a solution, but would like others'
opinions
> > and
> > > > solutions.
> > > >
> > > > Basically, in my programming model, any node that remotes an object
> will
> > > > keep a reference to that object until the clients are done w/ it and
> > until
> > > > the node is done w/ it. When all references are removed, it's up
for
> > > > garbage collection. So, to make sure the lease on life doesn't
expire
> > on
> > > > these remoted objects, I was going to extend the marshalbyrefobject
> > class
> > > > have a sponsor associated w/ it. When the sponsor gets notified
that
> > the
> > > > lease on life is going to expire and the KILL flag isn't set just
add
> > time
> > > > to it. When the reference to the remoted object in the serving node
> is
> > > > removed, a kill() method on the object is also called, setting the
> KILL
> > > > flag.
> > > >
> > > > So the kill method kindof acts like the delete keyword in c++, only
> that
> > > the
> > > > memory isn't freed until the lease on life expires and until the
> garbage
> > > > collection gets it. So, it really doesn't act like it, but the
> > programmers
> > > > call kill like delete.
> > > >
> > > > But, this brings up a point, if a programmer doesn't call the kill()
> > > method,
> > > > then the object will live forever - thus introducing possible memory
> > > leaks.
> > > > So what's the point in having all this nice garbage collection stuff
> if
> > > you
> > > > can still have memory leaks?
> > >
> > >
> >
> >
>
>

Sam Santiago

10/15/2004 2:58:00 AM

0

Yes, that sounds like a workable solution. Be sure to check out this
article too:

Managing the Lifetime of Remote .NET Objects with Leasing and Sponsorship
http://msdn.microsoft.com/msdnmag/issues/03/12/LeaseManager/de...

Thanks,

Sam

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"nospam" <nospam@nospam.com> wrote in message
news:PwFbd.6$k01.1@dfw-service2.ext.ray.com...
> ahh. that's pretty cool. so basically on each client I could have a
> singleton ClientSponsor. And whenever I get a remoted object from the
> server, I can register it w/ the single ClientSponsor. When I'm done w/
the
> remoted object, I can unregister it. The server should contact my
> ClientSponsor when the lease is about to expire on any of the registered
> objects, and then the clientsponsor should simple renew the lease.
> -Lars
>
>
> "Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
> news:uaDcAZksEHA.2300@TK2MSFTNGP09.phx.gbl...
> > The object is not literally carried around with the remoting object. It
> is
> > strictly registered as a sponsor of that object that is notified by the
> > lease manager. Check out the ClientSponsor class:
> >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/c...
> frlrfsystemruntimeremotinglifetimeclientsponsorclasstopic.asp
> >
> > Thanks,
> >
> > Sam
> >
> > --
> > _______________________________
> > Sam Santiago
> > ssantiago@n0spam-SoftiTechture.com
> > http://www.SoftiTe...
> > _______________________________
> > "nospam" <nospam@nospam.com> wrote in message
> > news:T5Dbd.4$k01.2@dfw-service2.ext.ray.com...
> > > I like the idea of having the logic/control on the client because it
> > > relieves the need to keep the reference on the server. But having
> another
> > > object that you basically have to carry around w/ the remoting object
> can
> > > get kindof ugly/messy.
> > >
> > > "Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
> > > news:OP7qzkjsEHA.2128@TK2MSFTNGP11.phx.gbl...
> > > > Sounds like your approach should work. The kill() method would have
> to
> > be
> > > > called for it to work as expected. You could also try keeping the
> > sponsor
> > > > on your client, when your client is done with the remote object or
> > exits,
> > > > unregister the sponsor or dereference it so that the sponsor is
> garbage
> > > > collected. If your sponsor cannot be reached at lease renewal time,
> I'm
> > > > assuming the remote object's lease will expire (I haven't tried this
> to
> > > > verify). Garbage collection becomes more complicated across app
> domain
> > > > boundaries, so you're still vulnerable to memory leaks.
> > > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Sam
> > > >
> > > > --
> > > > _______________________________
> > > > Sam Santiago
> > > > ssantiago@n0spam-SoftiTechture.com
> > > > http://www.SoftiTe...
> > > > _______________________________
> > > > "nospam" <lfiedler@cc.gatech.edu> wrote in message
> > > > news:43deea51.0410141255.64e401dd@posting.google.com...
> > > > > I have a few questions on how to make sure remoted objects leases
> > don't
> > > > > expire when they are needed, but also are garbage collected when
not
> > > > needed
> > > > > anymore. I believe I have a solution, but would like others'
> opinions
> > > and
> > > > > solutions.
> > > > >
> > > > > Basically, in my programming model, any node that remotes an
object
> > will
> > > > > keep a reference to that object until the clients are done w/ it
and
> > > until
> > > > > the node is done w/ it. When all references are removed, it's up
> for
> > > > > garbage collection. So, to make sure the lease on life doesn't
> expire
> > > on
> > > > > these remoted objects, I was going to extend the
marshalbyrefobject
> > > class
> > > > > have a sponsor associated w/ it. When the sponsor gets notified
> that
> > > the
> > > > > lease on life is going to expire and the KILL flag isn't set just
> add
> > > time
> > > > > to it. When the reference to the remoted object in the serving
node
> > is
> > > > > removed, a kill() method on the object is also called, setting the
> > KILL
> > > > > flag.
> > > > >
> > > > > So the kill method kindof acts like the delete keyword in c++,
only
> > that
> > > > the
> > > > > memory isn't freed until the lease on life expires and until the
> > garbage
> > > > > collection gets it. So, it really doesn't act like it, but the
> > > programmers
> > > > > call kill like delete.
> > > > >
> > > > > But, this brings up a point, if a programmer doesn't call the
kill()
> > > > method,
> > > > > then the object will live forever - thus introducing possible
memory
> > > > leaks.
> > > > > So what's the point in having all this nice garbage collection
stuff
> > if
> > > > you
> > > > > can still have memory leaks?
> > > >
> > > >
> > >
> > >
> >
> >
>
>