> > * Has anybody have similar symptoms? Could this be a leak in
> > base Turbine (2.1) code?
>
> It's possible.
Ok, we have also just detected that some of the DB operations
take a long time to complete (queries that take over one minute);
when there are more than maxConnections users, this could explain
why some of them just hang in there...
> > * Is there any way to activate some kind of tracing for the
> > connection pool? Something that included stack traces, even
> > with all the verbosity associated, so that it was possible
> > to track down exactly from where those connections are being
> > requested?
>
> You can throw an exception from within the connection pool code, then
> immediately catch the exception and log the stack trace. But I don't
> know how much information this will buy you...
Yes, this was my idea. At least this will let me gather all the places
where the connection pool is being called. Of course, this being open
source, I should be able to find all those places by just looking at
the code...
> If you are using the connection pool directly, have you checked all
> the places where you get connections to make sure they are returned to
> the pool?
I think we covered that already, but we will do another pass. I believe
the standard idiom to use here is the following, right?
try
{
db = TurbineDB.getConnection(dbName);
Connection connection = db.getConnection();
// do something with connection
}
catch (Exception e)
{
// log error: can't get connection
}
finally
{
try
{
TurbineDB.releaseConnection(db);
}
catch(Exception e)
{
// log error: can't release connection
}
}
--
Gonzalo A. Diethelm
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
