Subject | Re: Help locate a connection leak... |
---|---|
Author | Roman Rokytskyy |
Post date | 2004-05-05T20:26:29Z |
Hi,
very different from connection pooling in 1.5. It seems to have some
problems, at least some test cases fail. Till now it was assumed that
these failures are caused by incorrectly designed test case. Probably not.
Are you able to compile JayBird from CVS (or in the worst case take
1.5 RC2)? Its new connection pool seems to be more stable than the
previous one. Also it prevents statement handle leaks as described in
you previous post. However it might be less tolerant to the "bugs" in
the application code, but it will also try to point to the place where
the problem happened (for example, when you try to use a closed
connection, you get two stack traces - one where the connection was
closed and one where the incorrect access happened).
A hint: now class name is called
org.firebirdsql.pool.FBWrappingDataSource. Also check document called
connection_pool.html for configuration details (docs/ directory in
distribution, client-java/src/etc in CVS).
Roman
> I am using 1.0.1. The FBWrappingDataSource reports...I cannot either confirm or deny this. Connection pooling in 1.0.1 is
>
> getConnectionCount()=31
> getIdleTimeout()=60000
> getIdleTimeoutMinutes()=1
> getMinSize()=0
> getMaxSize()=150
> getBlockingTimeout()=5000
>
> The connectionCount property matches exactly that as reported by
> netstat. However the number of connections in the pool continues to
> grow until it reaches the maxSize(takes about 3 days or so) and then
> subsequent connections fail with 'No Managed Connections Available'
> exception.
>
> Are there any circumstances under which a connection that has been
> returned to the pool is not reusable?
very different from connection pooling in 1.5. It seems to have some
problems, at least some test cases fail. Till now it was assumed that
these failures are caused by incorrectly designed test case. Probably not.
Are you able to compile JayBird from CVS (or in the worst case take
1.5 RC2)? Its new connection pool seems to be more stable than the
previous one. Also it prevents statement handle leaks as described in
you previous post. However it might be less tolerant to the "bugs" in
the application code, but it will also try to point to the place where
the problem happened (for example, when you try to use a closed
connection, you get two stack traces - one where the connection was
closed and one where the incorrect access happened).
A hint: now class name is called
org.firebirdsql.pool.FBWrappingDataSource. Also check document called
connection_pool.html for configuration details (docs/ directory in
distribution, client-java/src/etc in CVS).
Roman