Disasterous use of ThreadLocals...

Am I the only one seeing all of the errors about "the web application /blah-blah created a ThreadLocal with key of type [com.vaadin.util.CurrentInstance]
and a value of type [java.util.HashMap]
but failed to remove it when the web application was stopped…

I thought it was just a portlet issue so I opened a bug on it, but it also seems to be the case on the servlet side as well.

These things can lead to big memory leaks (i.e. think live redeployment on system w/ a lot of service threads running)…

I mean, I can see using thread locals as a shortcut to passing a context object around, but this requires extra diligence to clean them up…

Not exactly the only one
http://dev.vaadin.com/ticket/9993
. I would also like to know, if there is something wrong with the solution that it wasn’t used in the latest Vaadin releases.

And that bug says it won’t be addressed until 7.1…

Seriously, between now and then are we forced to do an application container restart after every deployment just to ensure we don’t have runtime memory issues?

This is a big problem for me as well. Vaadin´s Thread Locals (CurrentInstance) are not cleaned up properly. So even after a UI has been detached, it ist still referenced by CurrentInstance as long as the dedicated thread in the app server exists and has not yet been re-used.

I think this is a serious memory leak even if you do not have to redeploy the app.

Stefan

According to the ticket http://dev.vaadin.com/ticket/9993, this has been fixed in 7.0.4. I’m on 7.0.4 but still having this issue.

Hello everybody.

I have experienced the same issue in Tomcat 6.0.24 and Tomcat 7.0.39.
But when I use Jetty 8.1.10, I do not encounter this issue.
Any thoughts ?

Only recent Tomcat versions try to check for such possible memory leaks and complain about them.

I read through the related code and created two more tickets for exceptional cases that could still leak some memory at application redeploy time (
#11905
and
#11906
).

Thank you Henri for the two tickets.
I hope, in the future, the application servers, such as Tomcat, Glassfish and Jetty, can deal with this thorny issue of ThreadLocal, because it is commonly used by many servlet-dependent framework, such as Vaadin and Springsource.

Hello, I am using Vaadin 7.1.0, and I had this error running the application in Tomcat:

The web application created a ThreadLocal with key of type [com.vaadin.util.CurrentInstance$1]
(value [com.vaadin.util.CurrentInstance$1@62c8f901]
) and a value of type [java.util.HashMap]
(value [{class com.vaadin.ui.UI=com.vaadin.util.CurrentInstance@7853e351, interface com.vaadin.server.VaadinRequest=com.vaadin.util.CurrentInstance@4b71188e, class com.vaadin.server.VaadinService=com.vaadin.util.CurrentInstance@6e033953, class com.vaadin.server.VaadinSession=com.vaadin.util.CurrentInstance@15a8b092, interface com.vaadin.server.VaadinResponse=com.vaadin.util.CurrentInstance@75e04c59}]
) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

This is also an error with Tomcat and Vaadin Sessions or i’m doing something wrong with it? I only create a VaadinSession to save user data, but I create no threads in my app.
Any thoughts?
Thank you