tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor I. Tovstopyat-Nelip" <itov...@euch4e.chem.emory.edu>
Subject RE: help - Tomcat/Linux deployment
Date Mon, 13 Jan 2003 16:11:03 GMT
Yoav, thanks a lot for your response.

Let me describe my situation more clear as I see it now.

It's definitely not DBCP, DBCP works fine.

This morning again the server was running but it couldn't serve my
request. This time I copied the exception which I will paste later.

The number of threads is not growing. There are 25 threads after the start
and the amount stays the same. It still bothers me that 'ps' shows that
each thread consumes about 6MB memory which seems to be too much but maybe
that information is not really adequate.

I'm trying to read the exception stack which I do not understand
completely, but this is what it looks like to me:

   Http11 connector tries to pass the request to a service but cannot
   allocate a thread from a thread pool.

Can anybody understand what really goes on and how to deal with it?

Please take a look at the exception stack a couple of lines down.

Thank you.
Igor TN

--------- exception stack ----------------------------

javax.servlet.ServletException: Communication link failure:
java.io.IOException
  at pro.servlets.LoginServlet.doPost(Unknown Source)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
  at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
  at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
  at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396)
  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
  at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
  at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
  at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
  at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
  at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
  at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
  at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405)
  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380)
  at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508)
  at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533)
  at java.lang.Thread.run(Thread.java:536)

------- end of exception stack ---------------

On Mon, 13 Jan 2003, Shapira, Yoav wrote:

> Howdy,
> I can't help much with DBCP, but I noticed your other thread was
> hijacked with a "how did you get DBCP to work? ..." question ;)
>
> I did want to comment on something else:
>
> >Also, immediately after I start Tomcat on Linux I see a lot (26) of
> java
> >processes running. As I understand, they are Tomcat internal threads
> >launched as OS processes, because Linux JVMs (I tried both SUN's and
> >IBM's) use "green", not native threads.
>
> Be careful interpreting the Linux ps/vmstat command output with regards
> to JVM memory consumption and thread usage.  More information on this
> issue is available in the list archives, so you may want to search
> there.
>
> Tomcat by default will record that it's starting a new request
> processing thread in its log.  So you can look there and see how many
> request processing threads tomcat has running.  There are only a few
> threads on top of that (main, finalizer, timer, etc, the standard JVM
> threads).
>
> >Now, as the time goes by, the number of these threads/processes grows,
> and
>
> Do you create any threads in your app?  If so, be careful to close them
> appropriately.
>
> >when I try next morning to login, the server cannot create extra
> processes
> >needed to fulfill the client's request, because on Linux/UNIX the
> number
> >of user processes is limited.
>
> Typically DBCP will not try to create extra threads after its
> initialization and definitely not after pool fulfillment.
>
> >Can anybody tell me if I understand this right, and what might be a
> >workaround?
>
> A three-pronged approach:
>
> - See if you can increase the number of user processes via something
> like ulimit on Solaris,
> - Make sure you don't create extra threads, run tomcat with the minimum
> number of threads you can afford (this depends on how many concurrent
> users you need to support)
> - Run your application in the development environment, where everything
> works, for a prolonged period of time (> 1 day) and see if the same
> error repeats.
>
> Post more information once you have it, and I'm sure we'll be able to
> offer more help ;)
>
> Yoav Shapira
> Millennium ChemInformatics
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message