Glenn Nielsen wrote:
>
> "Waldhoff, Rodney" wrote:
> >
> > As you probably already know, the NoSuchElementException is telling you the
> > pool has been exhausted (and the "detail" message suggests you've got the
> > pool configured to block for some finite amount of time before giving up).
> > The most probable causes, in my experience:
> >
> > 1. A peak in connection usage, causing the pool to be exhausted "naturally",
> > (e.g,. you've capped the pool at 10 instances, and you suddenly need to use
> > 11 at once).
> >
> > 2. A slow leak, like Michael described:
> >
> > > I suspect that you may have a pool leak. Somewhere
> > > you're borrowing from the pool and not returning it
> > > to the pool. Possibly the return of an object is
> > > not in a finally block and an rare exception causes
> > > it to lose one object.
> >
> > If you can't tie the exception to activity in one way or another, then it's
> > probably the latter. Configurating the pool to "when exahausted, grow"
> > would make the problem go away (at least as long as the database can support
> > the traffic). Setting the pool cap very low will make it happen more
> > frequently, which may make it easier to diagnose and/or determine if the
> > problem has been fixed.
> >
> > Like Michael suggested, look for places where the connection.close() method
> > isn't happenning in a finally block, and that the close call will always
> > execute within that block. (E.g., I sometimes see code like:
> >
> > } finally {
> > resultset.close();
> > statement.close();
> > connection.close();
> > }
> >
> > which won't do what we want if either of the first two lines throws an
> > Exception. I use this idiom:
> >
> > } finally {
> > try { resultset.close(); } catch(Exception e) { }
> > try { statement.close(); } catch(Exception e) { }
> > try { connection.close(); } catch(Exception e) { }
> > }
> >
> > and don't worry about null or anything else.)
> >
>
> I have reviewed the customers JSP pages and found one page
> where they were not wrapping their use of a db connection within a
> try {} block. I have informed them how to fix it.
>
> But this one page does not explain running out of connections in a pool
> with a max of 75 connections. In the logs that page only failed twice
> during the run of Tomcat before it ran out of db connections.
>
The remainder of the pages use the DbTags JSP tag library. I found
one JSP page in use which was not closing the dbTags closeConnection tag
to close the db connection. This page was not frequently used, but
probably explains the slow connection leak.
Thanks for everyones help.
Glenn
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
