TCCL memory leak in RMI registry creation

[Mark Thomas]

On 25/04/2016 22:26, Stuart Marks wrote:
> On 4/22/16 3:03 AM, Mark Thomas wrote:

Sorry for the delayed reply. I got distracted on other things.

>> The good news is that, with the information above, this leak is
>> something that modules/applications can and should do something about.
> 
> I think the general rule has to be that, if an application has exported
> a remote object, that object should be unexported when the application
> shuts down. This applies equally well to registry objects created by the
> application.

I agree completely. That hard part will be getting web application
developers to do this. Hence my desire to be able to detect, report and
(if possible) fix this.

>> This moves the problem to how to detect when modules/applications fail
>> to clean up an RMI Registry they created. I'd like to be able to provide
>> nice loud error messages when this happens. Open questions are:
>> - How to get a list of RMI registries?
>> - How to determine the TCCL for a registry (held in the ccl field of the
>>   associated sun.rmi.transport.Target object) so I can figure out if a
>>   module/application created it?
> 
> I don't have a good answer for this.
> 
> I do think that talking about registries is a bit of a distraction. As I
> mentioned above, the general problem can occur with any remote object,
> and a registry is mostly an ordinary remote object.

Fair point.

> All remote objects in this JVM are kept in the ObjectTable, and the
> cleanup code you have looks through this for Target objects with the
> right ccl etc. already.
> 
> If you want the cleanup function to continue to be active in production
> use of Tomcat, then you'll probably need to explore the JVM command-line
> options that enable the reflective access to continue, e.g. -XaddExports
> or -Xpatch.

I can confirm that -XaddExports with appropriate settings does allow the
current code to work correctly.

I'd like to be able to avoid reflection and -XaddExports if possible. Is
there any chance at all of the RMI API being extended support this sort
of clean-up without reflection?

> A variant of this is to get one's hands on the remote object itself and
> then call unexportObject() on it, instead of directly removing things
> from the various maps. This probably does the cleanup in a more robust
> fashion, though it doesn't help with the main problem of getting
> reflective access.
> 
> If this doesn't need to run in production, and can be run only in, say,
> some "diagnostic mode," (not sure if such a thing exists) then there are
> some other possibilities. For example, one might load an agent, or use
> the debugger interface, to track remote objects being exported and
> unexported. If, after shutting down an application, remote objects
> remain exported, this could cause some errors to be issued.

Unfortunately, this needs to run in production.

Thanks again for all your help.

Mark