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


 

Forums >

microsoft.public.dotnet.framework.remoting

Remoted objects never garbage collected.

banderbe

6/4/2004 8:31:00 PM

I have an application which handles events raised remotely. The
object through which the events are raised is remoted to my
application, and it has had its InitializeLifetimeService method
overridden to return null, so that it stays alive for the lifetime of
the application.

When these events are raised, one of the arguments to the event
handler is an object (call it Carrier) that contains, among other
things, a string. These events are raised thousands and thousands of
times over the course of an hour, and during that time the .NET
Profiler by SciTech shows that string objects are allocated but remain
"alive", ie. reachable and thus are never garbage collected. Of
course, the program eventually starts to buckle as it has consumed all
available memory.

If I examine the root path of these string objects they're all
contained in various Carrier objects that have been sent over the
lifetime of the app.

The odd thing is that the .NET Profiler does NOT indicate that the
Carrier objects are not being garbage collected. How is this
possible?

Please help me! I do not know remoting that well and our application
has to be restarted every day to keep it running!!!
3 Answers

Sunny

6/4/2004 9:04:00 PM

0

Hi,

how is the Carrier class declared? Does it inherits from
MarshalByReferenceObject, or from any other class, which inherits MBR?

Or, it is simple custom based class, marked as Serializable?

Sunny

In article <9dd925b8.0406041231.510e8fdc@posting.google.com>,
banderbe@yahoo.com says...
> I have an application which handles events raised remotely. The
> object through which the events are raised is remoted to my
> application, and it has had its InitializeLifetimeService method
> overridden to return null, so that it stays alive for the lifetime of
> the application.
>
> When these events are raised, one of the arguments to the event
> handler is an object (call it Carrier) that contains, among other
> things, a string. These events are raised thousands and thousands of
> times over the course of an hour, and during that time the .NET
> Profiler by SciTech shows that string objects are allocated but remain
> "alive", ie. reachable and thus are never garbage collected. Of
> course, the program eventually starts to buckle as it has consumed all
> available memory.
>
> If I examine the root path of these string objects they''re all
> contained in various Carrier objects that have been sent over the
> lifetime of the app.
>
> The odd thing is that the .NET Profiler does NOT indicate that the
> Carrier objects are not being garbage collected. How is this
> possible?
>
> Please help me! I do not know remoting that well and our application
> has to be restarted every day to keep it running!!!
>

(Barry Anderberg)

6/5/2004 2:01:00 AM

0

Hello Sunny.

I''m not at work now so this is from memory but I think the Carrier class
inherits from an object that inherits from MarshalByReferenceObject.

It is possible it is marked serializable but I am pretty sure it isn''t.

Since it inherits from MarshalByReferenceObject that means the client is
passed a reference to the object right?

Objects marked serializable are passed by value meaning the client gets
its own copy.

Anyway, any help you can offer to clear this up would be greatly
appreciated.


*** Sent via Devdex http://www.... ***
Don''t just participate in USENET...get rewarded for it!

Sunny

6/7/2004 3:34:00 PM

0

Hi Barry,

if your Carrier object is MBR, than its lifetime does not depend on the
GC but on the lifetime rules for all remoted objects. I.e. if its
InitializeLifetime... is set to null, it will never be released. Or if
after passed to client, the client makes some calls back, it will extend
Carriers lifetime.

So take a look there who and how is instaniating the Carrier object. And
maybe you can consider to limit its lifetime to lets say 30 secs or
less, depends on your situation.

Generally I do not see a reason to pass an MBR in an event handler.
Events in most cases are just to notify the client that something that
happened, so sending only the required info is enough.

Sunny

In article <eG3B$DqSEHA.3016@tk2msftngp13.phx.gbl>, banderbe@yahoo.com
says...
> Hello Sunny.
>
> I''m not at work now so this is from memory but I think the Carrier class
> inherits from an object that inherits from MarshalByReferenceObject.
>
> It is possible it is marked serializable but I am pretty sure it isn''t.
>
> Since it inherits from MarshalByReferenceObject that means the client is
> passed a reference to the object right?
>
> Objects marked serializable are passed by value meaning the client gets
> its own copy.
>
> Anyway, any help you can offer to clear this up would be greatly
> appreciated.
>
>
> *** Sent via Devdex http://www.... ***
> Don''t just participate in USENET...get rewarded for it!
>