Maybe I will implement a distributed garbage collector.
Who knows the exact consequences of having no distributed garbage
collector ?
I would like to know if it implies that only the skeletons on
the server side are never collected, while the server is running.
I have a method in a Remote class that returns a Remote object.
If a client gets a remote reference on this object, and the client stops,
is my remote object never collected because it is related to its skeleton
?
In advance thank you all,
Gérard Borreill,
Bruno Dumant wrote:
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "unsubscribe jonathan". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
For the time being, the answer is no. A student at France Telecom started to work on it, but this work was never sufficiently stabilized to be integrated in the release.I have never really worked on the problem myself, but the following principle could work :
One solution to actually garbage collect your objects on the server side would be to use a list of all no longer acquired exported objects (the value of their counter is zero). When a new object is released, and its counter becomes zero, you add it to the list. If the length of the list becomes greater than a given constant, you remove the oldest object in the list and unexport it.
- Add an acquire() and a release() method on the remote interfaces you're interested in (or define an appropriate Remote interface and use interface inheritance)
- The acquire() method simply increases a counter
- The release() method decrements it.
- When a client receives a remote object, it calls the acquire() method on it. When it stops using a remote object, it calls the release() method on it. This could be done automatically when creating and finalizing stubs, but it should only be done on the client side. You may patch your stubs to do that.
This mecanism is simple, and may be a workaround, but it is not correct in all cases : you may be unlucky and remove objects just while you were sending their reference to some client. However, applicative considerations may give you hints whether this is a risk or not.
Hope this helps !
Bruno
Gerard BORREILL wrote:
Hello,Does anyone know if there is a version of Jeremie that has an
implemented distributed garbage collector ? I really need this because
when a client disconnects from my server, remote objects are never
garbage collected, and it generates memory leaks.
Is there a work around, or do I have to implement a distributed garbage
collector ? Is there anyone working on it ?
I am using the 2.4 version, and knows that it does not support
distributed garbage collection.Gérard,
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonathan".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
