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.)
- Rod
