• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Tomcat deployment issue: thread local memory leak

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a JEE application which stops after 24 hours and indicates an Out Of Memory problem.
I used Netbeans profile to locate the problem but I couldn't fix it.
In tomcat log of my application, I found those lignes :

Is those warnings have a relation with the memory leak faced in my application? If yes, how can I resolve this problem?
I use Tomcat 7.0.41
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Creating Threads without cleaning them up correctly will eventually run you out of memory - been there, done that.

I trust that you realize that creating your own Threads inside a servlet application is generally frowned on - probably because it is hard to debug.

If you review your architecture and decide that you absolutely have to create your own Threads then you better instrument your code with logging statements at the point where Threads are created and destroyed.

I found my problem by using the Tomcat Management App to watch the active request threads and memory use. To my surprise certain request Threads were hanging indefinately!

Bill
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Something's wrong here. I wrote a fairly detailed explanation on why spawning threads in web code is forbidden. The posting has vanished.

Short answer, however, is that the thread a request is processed under isn't permanently attached to the servlet. Instead, it's pulled from a common thread pool. The servlet code (this includes JSPs) runs under that thread, and it should complete as quickly as possible in order to keep the thread pool from being drained dry.

All of the threads in the execution thread pool should be identical - otherwise it's not a reliable pool. If you spawn a child thread under the servlet thread and that thread goes back to the pool, it's no longer identical. And it will later be passed to another request that doesn't realize that there's excess baggage already attached to the servlet handler pool thread. Results are unpredictable. You could crash the request. You could crash the app. Or you could crash Tomcat itself.

If you spawn a child thread and wait for it to terminate before finishing the web request, you're violating the "get-it-done-quick" convention. This can cause exhaustion of the thread pool and drag down the performance of the server.

So don't spawn threads in servlet request handling code. If you need threads, spawn them from a non-servlet part of the app such as a ServletContextListener.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic