2005/9/30, Kevin Wilson <[EMAIL PROTECTED]>:
> The app uses it own form of connection pooling (it's an old app). It creates
> 5 connections at startup and stores those in a vector called 'available' for
> later usage. As a connection is needed it removes one from the 'available'
> vector and places that connection in a vector called 'inuse'. The connection
> is then placed back (recycled) in the 'available' vector when the app is
> done with it. It doesn't use tomcat's pooling.
>
> As demand requires new connections are created on the fly and stored but
> there is a marker that is checked when the connection is recycled. If the
> number of available connections is higher than that marker then the recycled
> connection is terminated. Although the app is telling the connection to
> close and nullify they end up just hanging around and never truly terminate.
>
> The jvm has a maximum limit of open files it can handle. As soon as we get
> over 1000 open connections the "Too Many Open Files" error is thrown and
> users can't connect until the context is restarted.
>
> With all that said, any ideas on how I can remedy this? Is all I need to do
> is turn auto connect off?
I rather suspect you have a connection leak (similar to memory leak)
in your application, i.e. connections are opened but not closed again
because *if* they would be closed you wouldn't see such a high number
of connections.
What to do? First, I'd probably get rid of the inuse vector. That
may well the instance that keeps referencing connections that are no
longer used elsewhere. You might also want to replace your connection
pool by a readymade (from apache for example, if I'm not mistaken
there's even on in tomcat). I'd check all places that get connections
from the pool whether they actually return them under all conditions.
The best to do this is via finally blocks because they ensure that the
connection is returned under all conditions:
Connection conn = getConnection();
try {
// use conn
}
finally {
returnConnection( conn );
}
Kind regards
robert
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
