It has been a long time since I looked at the logic in EJBClassLoader, so I am not sure how helpful this will be. But I'll try.
The basic purpose of the sentinel streams is twofold.
1. When an app is unloaded or undeployed, its classloader (an EJBClassLoader even if the app has nothing to do with EJBs) is notified to clean up. Part of that clean-up work is to close any streams that GlassFish or the application opened through that class loader (for example, through getResourceAsStream) but has not closed explicitly. To do that the class loader records all such streams.
2. When a stream is closed in an unusual way - for example, either as the class loader is cleaning up or when the stream is finalized (which of course is not guaranteed to happen in a timely way if ever) - then that means GlassFish or the app has not closed the stream explicitly itself. That's a bug, and the sentinel stream reports where it was opened from to help track down the leak.
It is possible you have found a bug in this logic, although I do not think that GlassFish will by itself use the class loader to open a stream for each request. It's also possible as your app is running that it is opening streams - perhaps indirectly (via getResource and then opening a stream using the URL, or via getResourceAsStream) - but not closing them. This would cause the accumulation of streams you describe.
To track this down further you might try starting GlassFish with the debugger. Then attach to it using a debugger (from an IDE for example). Run a request or two through your app, then set a method breakpoint at the SentinelInputStream constructor. SentinelInputStream is an inner class inside EJBClassLoader. Then submit another request and see if and from where the constructor is invoked. That might provide some hints where to look.
- Tim
[Message sent by forum member 'tjquinn']
http://forums.java.net/jive/thread.jspa?messageID=486435