ManagedConnectionPool / Lost connections / Bad connection re
marcma Apr 19, 2004 6:20 AMHi All.
We have some serious problems with the current jboss jca
implementation which results in a non HA JBoss environment.
HA and database auto-recovery are crucial for us so no matter
of what kind of help -- it is appreciated very much.
Here the setting.
JBoss 3.2.3 / JBoss 3.2.4RC1 (same problem), Sybase 12, Jconn2 (5.5)
Here what happens.
Let's say we have a minpool size of 5, a maxpool size of 30 and an idle-timeout of 3 minutes configured in the ds.xml.
When the database goes down or hangs, lots of JZ0C0 exceptions are thrown. The SybaseExceptionSorter returns isFatal=true and the connection is removed from the pool acknowledged by an exception (Exception destroying ManagedConnection: JZ0C0 Connection already closed) The ConnectionCount than shows -5 while connectionCreatedCount shows 5 and ConnectionDestroyedCount shows 10. Funny ManagedConnectionPool. I don't get the point in destroying more than creating. Anyway, the database tool says there are no more connections left open from JBoss. After the IdleRemover enters the scene the exact amount of removed connections is recreated + a new pool. In case we kill all connections we get exactly twice as many connections as minsize of the pool. That makes 10. 10 is the amount of connections needed to get back to 5 (from -5). 5 is the value for the ConnectionCount which equals the minsize of the pool. An that es exactly the amount of connections that the jmx-console says that the pool manages. So we have 10 connections reported by the database tool and 5 connections reported by the jmx-console. That makes 5 lost connections. We can figure out that those 5 connections are never used by jboss again. As a side effect the Value of AvailableConnectionCount is wrong too.
The ArrayIndexOutOfBounceException (Bug #885095) ist no problem anymore due to usage of an ArrayList instead of an Array. Though the counting algorithm seems to be messed up a little bit, as it is still not right.
If the database hangs long enough we reach the limit of maxsize=30 which we can see in our database tool. Funny, because the pool says it only has 5 connections at a time. And than out of a sudden the ManagedConnectionFactory passes by with a shutdown message.
And that's the point that blows me off.
Now here the one-mill$-question(s):
Is this bahaviour intended and expected?
Is the attribute ConnectionCount an on-demand calculation of an mbean
or is it a concrete element internally responsible for the housekeeping of the pool?
If so, the problem might disappear if the counting algorithm will be sorted. Right?
In case I am right, when will be the soonest you can fix this problem?
Here is another interesting behaviour that is probably related to the above one. Same setting again. Now we flush the pool with the corresponding mbean operation. The pool says it ownes 0 connections. All other values seem to be ok as well. The database tool says that all of the connections are still open. Wow? JBoss in fact did not destroy any of the connections though we are 100% sure that there cannot be any checked out connections by the application. Than after a new request by the application or a run of the IdleRemove, which ever comes first, the pool is recerated with 5 connections. The database tool says there are 10 connections opened by jboss. Hmmm. What happens here? No matter how long we wait the amount of connections never decreases. So what about flush. Is this behaviour expected?
In all cases there are most definitely no left open connections by the application. It is not the jdbc driver as we testet others with the same result. It is not the application as we can undeploy it with no effect on the pool. We have tested the application under bes 5.2.x with no problems regarding the behaviour mentioned above. The database tool is called whodo which is based on the sybase internal tables and stored procedures. Absolutely reliable.
Anybody with similar problems? Or even better with a solution?
Cheers
Marc
BTW:
jboss-ds_1_0.dtd -> no-tx-separate-pool is not a #PCDATA field.
It is an empty field. Presence means true. Absence means false.
That's a bit confusing in the documentation.