app vendor telling porkies?

[jim]

We are having a major problem with a web application we are using.
Every 3 - 4 days the app is reporting a connection error - No more
connections available in pool - and has to be rebooted. The problem
only appears on web pages that access the database so I presumed that
it was a database pool connection issue. However, the app vendor
insists that the error message (see below) relates to a HTTP
connection pool problem. However, when the problem occurs the site
still serves any page that does not connect to the database??

What the vendor is saying is that since the servlet class has nothing
to do with DB connections but everything to do with HTTP connections,
they think our error has to do with HTTP connections to Tomcat. Can
anybody shed any light on this at all? This problem has been going on
months now and the vendor keeps trying to pass the buck.

Many thanks in advance!

jim


2004-07-14 14:47:15 StandardWrapperValve[jsp]: Servlet.service() for
servlet jsp threw exception
org.apache.jasper.JasperException: No more connections available in
pool.
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:254)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
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:256)
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:2415)
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:171)
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:594)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
----- Root Cause -----
javax.servlet.ServletException: No more connections available in pool.
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:536)
at org.apache.jsp.taskListXML_jsp._jspService(taskListXML_jsp.java:543)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
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:256)
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:2415)
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:171)
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:594)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)

 

[Tor Iver Wilhelmsen]

2004-07-14 14:47:15 StandardWrapperValve[jsp]: Servlet.service() for
servlet jsp threw exception
org.apache.jasper.JasperException: No more connections available in
pool.

This does indeed sound like a servlet instance pool problem; However,

javax.servlet.ServletException: No more connections available in pool.
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:536)
at org.apache.jsp.taskListXML_jsp._jspService(taskListXML_jsp.java:543)

it seems to have gotten to this line in your JSP; try looking at the
auto-generated java source file to see what statement that actually
causes the exception on line 543. If you cannot find the source, try
running jspc manually on the file; remember to use jspc from the same
Jasper version as the runtime system uses.

(This is yet another case of a problem where an exception is caught
lower down and "rethrown" as a different exception, keeping the
message but little other context. Apparently, handlePageException()
doesn't set the exception as a "root cause" in the exception it
throws.)

By the way, is it the JDBC vendor or the web app container vendor who
made the statement?

 

[Oscar kind]

We are having a major problem with a web application we are using.
Every 3 - 4 days the app is reporting a connection error - No more
connections available in pool - and has to be rebooted. The problem
only appears on web pages that access the database so I presumed that
it was a database pool connection issue. However, the app vendor
insists that the error message (see below) relates to a HTTP
connection pool problem. However, when the problem occurs the site
still serves any page that does not connect to the database??

The most likely explanation is that the database connection pool runs out
of connections. Increasing the size of the connection pool should help,
but then again may not.

What the vendor is saying is that since the servlet class has nothing
to do with DB connections but everything to do with HTTP connections,
they think our error has to do with HTTP connections to Tomcat. Can
anybody shed any light on this at all? This problem has been going on
months now and the vendor keeps trying to pass the buck.

If Tomcat cannot handle the load, it's because there is no thread
capable of listening to client. In that case, the browser will time out.
This works the same as a normal http server.

2004-07-14 14:47:15 StandardWrapperValve[jsp]: Servlet.service() for
servlet jsp threw exception
org.apache.jasper.JasperException: No more connections available in
pool.
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:254)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) [...]
----- Root Cause -----
javax.servlet.ServletException: No more connections available in pool.
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:536)
at org.apache.jsp.taskListXML_jsp._jspService(taskListXML_jsp.java:543)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)

The exceptions here, JasperException and ServletException, are only the
end of the chain. The ServletExeption is not the root cause, but merely
the cause of the JasperException. It is mislabeled.

Is there a log that displays the real root cause? If not, the developers
should really start logging this. I frequently find the real root cause
(or first useful cause anyway) to be the third or fourth exception in the
chain, and that isn't displayed by Tomcat.

I'm just guessing now, but I think you'll find an SQLException (or some
vendor-specific subclass) as the root cause.

 

[Murray]

org.apache.jasper.JasperException: No more connections available in
pool.

I have seen that exact error message thrown as an SQLException i.e. database
connection pool problem. The fact that it only affects pages that access the
database also seems to back this up. It's a pretty easy bug to introduce
into your code .. a simple forgotten connection.close() statement or bad
exception handling can cause a resource leak that will eventually bring your
app to a grinding halt.

As Tor said, you'll need to look at the generated source code to pinpoint
the problem though.

 

[Chris Smith]

Is there a log that displays the real root cause? If not, the developers
should really start logging this. I frequently find the real root cause
(or first useful cause anyway) to be the third or fourth exception in the
chain, and that isn't displayed by Tomcat.

Indeed, it looks like someone wrote:

throw new ServletException(e.getMessage());

when they should have written:

throw new ServletException(e);

Because of that, there's not enough information reported to diagnose the
problem from this error message. It is clear, though, that it's
something on that page that's failing; not something in the web
container logic to get to that page. That makes database connections
more likely, in my mind, than HTTP connections.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[jim]

Thanks to all who've replied. I think you've pretty much confirmed
what I was thinking - that its a database issue. We have extended the
app with our own code which it is designed for. The vendor has
instructed us that to return connections back to the pool, in our
code, we should use connection.freeConnection("cn", con); *and not*
con.close(); Does this sound right? Incidently, we have another
version of the same app on development servers and this has never
experienced the problem. Oh well, time to go back to the vendor.

Thanks all.

 

[Chris Smith]

Thanks to all who've replied. I think you've pretty much confirmed
what I was thinking - that its a database issue. We have extended the
app with our own code which it is designed for. The vendor has
instructed us that to return connections back to the pool, in our
code, we should use connection.freeConnection("cn", con); *and not*
con.close(); Does this sound right?

It sounds right for very old (almost said "obsolete") implementations of
JDBC connection pooling. If you're using anything related to modern
connection pooling, though, then you ought to just close your
connections. It's up to you to decide which is the case.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation