I'm not the expert but...
On 10/9/05, Binildas C <[EMAIL PROTECTED]> wrote:
> We are building a high volume site in Tomcat5.0.28.
> Our single Tomcat5.0.28 instance in the Web Farm is
> having 10 HTTP Threads. Each HTTP Thread collects
> request events in a ThreadLocal. At every 1000
> requests (in a particular HTTP Thread) the HTTP Thread
> will collect events from the ThreadLocal, sets them in
> "it's" deamon thread (There is one-to-one
> correspondance between the number of Tomcat HTTP
> Threads and Deamon threads, hence we have 10 Deamon
> threads), notifies the deamon thread, and clears the
> ThreadLocal. The Deamon thread will pushes the events
> to a seperate single process through RMI.
What exactly is the goal of all this? Why do you gather information in
the HTTP Thread, and not in the daemon thread? It seems obvious to me
to hold the data there (if at all).
Btw, what do you mean by high volume?
> Everything works fine (functional and otherwise) for
> the first 1 or 2 hours or so, and then we can see the
> Tomcat 5.0.28 Process taking lot of memory and
> ultimately we are getting either an
> OutOfMemoryException or The Tomcat process stalls!
> Our Question is:
> 1. Is Tomcat 5.0.28 having a memory problem?
Search Bugzilla (http://issues.apache.org). We have tomcat 5.0.25 and
28 in a high traffic site (approx. 100 requests per server per second)
and not having any memory problems.
> 2. If so, what about other versions of Tomcat?
Probably the same, unless you'd like to try the new garbage collector
in jdk1.5 and test it with 5.5.12
> 3. Is this memory problem somehow related to Thread
> and/or ThreadLocal Usage?
Are you sure your code is actually freeing the objects? If you keep a
reference to the object somewhere, you'd never have your gc utilize
them. How much memory do you give tomcat/jvm at startup? Have your
tried a verbose mode for gc (or simply print out memory stats all 10
minutes) to see if it's a continous leak, or something cause it "out
of nowhere" by chance? Are you creating new Threads? File handles? You
must know that OutOfMemoryError in java can mean nearly anything.
> 4. Any work around for this.
Besides, I don't like your solution, and would advice you to rewrite
it in more conventional way, there is a simple workaround, if you can
afford to loose some of your requests -> use SoftReferences for
holding your data, they are guaranteed to be freed before an
OutOfMemory can occur.
> Thankx in advance
> Binildas C. A.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]