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
