Does the connection leak happen with all plugins (other than GWT) disabled?
On Tuesday, August 28, 2012 7:57:37 AM UTC-7, Brian Slesinsky wrote: > > Thanks, I think I can do something about this. > > On Tue, Aug 28, 2012 at 2:15 AM, Thomas Broyer wrote: > > In other words: it looks like the Firefox plugin doesn't send a > QuitMessage > > to the DevMode, and worse, is kept alive in the background! > > > > > > On Tuesday, August 28, 2012 11:05:38 AM UTC+2, Chris Lercher wrote: > >> > >> I analyzed this a bit more (this time on Linux), and I noticed, that > the > >> number of Thread also grows: 1 thread per reload. Again, this happens > only > >> with Firefox, not with Chrome. So probably the ClassLoader references > will > >> be discarded only when the Thread terminates... > >> > >> One more thing that might be interesting: When closing the entire FF > >> instance (just closing the tab is not enough), then the threads are > >> discarded, and Heap/PermGen space can be garbage collected. > >> > >> By the way, closing the FF instance leads to the following Exception > >> printed by the DevMode server: > >> > >> 10:53:21.549 [ERROR] [mymodule] Remote connection lost > >> > >> com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote > >> connection lost > >> at > >> > com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:308) > > > >> at > >> > com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) > > > >> at > >> > com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) > > > >> at java.lang.Thread.run(Thread.java:662) > >> Caused by: java.io.EOFException: null > >> at java.io.DataInputStream.readByte(DataInputStream.java:250) > >> at > >> > com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChannel.java:1100) > > > >> at > >> > com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:284) > > > >> at > >> > com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547) > > > >> at > >> > com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364) > > > >> at java.lang.Thread.run(Thread.java:662) > >> > >> > >> > >> > >> On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote: > >>> > >>> That's an interesting report. We always want to garbage collect the > >>> ClassLoader when the session is over and if that doesn't happen, it's > a bug. > >>> I don't know why Firefox would behave differently; the JVM side should > work > >>> the same way for Firefox versus Chrome. The only thing I can think of > is > >>> some difference in distributed garbage collection, but that shouldn't > matter > >>> once the session ends. > >>> > >>> Alan's not on the team anymore. I'd like to fix this, but I'm busy > with > >>> other things and I don't have a good idea where to begin. If someone's > handy > >>> with a memory profiler, figuring out what's preventing the classloader > from > >>> being gc-ed in this case would be very useful. > >>> > >>> - Brian > >>> > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/YxkUXpopHQYJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
