3.0.6 vs 3.0.7 CachedConnectionManager Problem

[ggottardi]

Hi,

just upgraded you JBoss to 3.0.7 from 3.0.6.

We use oracle 8.1.7 with orale's thin jdbc driver and the oracle-service.xml file until 3.06 withou any problem.

After the move every access to the pool causes this exception:
========================================================
16:13:24,428 INFO [LocalTxConnectionManager$LocalConnectionEventListener] throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown connection2! org.jboss.resource.adapter.jdbc.WrappedConnection@1df5c7
at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:274)
at org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener.connectionClosed(LocalTxConnectionManager.java:371)
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:280)
at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:97)
at com.oqibo.ormap.uti.DataSource.close(DataSource.java:82)
at com.oqibo.persistentlayer.svc.PSPersistentService.releaseDataSource(PSPersistentService.java:143)
at com.oqibo.persistentlayer.svc.PSChartSettingsManagement.getChartSettings(PSChartSettingsManagement.java:64)
at com.oqibo.persistentlayer.facade.PersistentFacadeLocal.getChartSettings(PersistentFacadeLocal.java:1437)
at com.oqibo.party.svc.BSUserManagement.login(BSUserManagement.java:207)
at com.oqibo.party.facade.PartyFacadeBean.login(PartyFacadeBean.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:98)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContainerInvoker.java:301)
at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:83)
at $Proxy132.login(Unknown Source)
at com.oqibo.party.facade.proxy.PartyFacadeBeanProxy.login(PartyFacadeBeanProxy.java:94)
at com.oqibo.websignalengine.manager.LogonMgrAction.callBusiness(LogonMgrAction.java:159)
at com.oqibo.websignalengine.manager.LogonMgrAction.manage(LogonMgrAction.java:102)
at com.oqibo.weblib.util.ActionManager.doPerform(ActionManager.java:102)
at com.oqibo.weblib.util.Action.perform(Action.java:86)
at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1787)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:509)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
16:13:24,889 INFO [CachedConnectionManager] Successfully closed a connection for you. Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection@74b10b
java.lang.Exception: Stack Trace
at org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:357)
at org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:98)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContainerInvoker.java:301)
at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:83)
at $Proxy132.login(Unknown Source)
at com.oqibo.party.facade.proxy.PartyFacadeBeanProxy.login(PartyFacadeBeanProxy.java:94)
at com.oqibo.websignalengine.manager.LogonMgrAction.callBusiness(LogonMgrAction.java:159)
at com.oqibo.websignalengine.manager.LogonMgrAction.manage(LogonMgrAction.java:102)
at com.oqibo.weblib.util.ActionManager.doPerform(ActionManager.java:102)
at com.oqibo.weblib.util.Action.perform(Action.java:86)
at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1787)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:509)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
========================================================

The application works correctly, but we get some kilometers of logs before any access to the pool (logegd as 'INFO' :-(().

Any suggestion would be VERY appreciated.

Thanks

[davidjencks]

Unfortunately I didn't get a bug fix in for what I think this problem is before 3.0.7 was released. I recommend trying 3.0 from cvs or 3.2.

[sheckler]

Hi, I got the same problem with 3.2.0 release and I am looking for a solution.
Any help appreciated!

Stefan Heckler

[davidjencks]

Do you have a simple way to demonstrate the problem?

[sven.baumgarten]

Hi, I got the same problem with 3.2.0 and 3.0.7. On 3.0.4 (the last releas I used) it works without problems. I use only CMP entity beans and MS SQL Server 2000. So I think the EJB container should open and close connections itself. I don't know when and where I should close any connection?

Sven

[tbauer]

I just upgraded from 3.0.6 to 3.0.7 and am getting the same F@@@ing annoy problem. Am using mysql 4.0.12-max, mysql-connector-java-3.0.7-stable-bin.jar, and java 1.4.1.

David Jenks, this problem has been around for a LONG time! I tried to use 3.2+ MONTHS ago and this problem was there...now it seems it has infected the 3.0.x code base.

Even when you are POSITIVE you are opening and closing all connections properly it spits out REAMS of INFO messages described above....Well, I guess I'm stuck at 3.0.6 until we see a glimmer of hope this has been fixed....or at least allow us to turn in off in one of the /default config files!

[davidjencks]

As I mentioned in my first response, I know that this problem exists in 3.0.7. Please stop complaining about that.

I have run the cmp2 portion of the testsuite for 3.0 and 3.2 cvs and do not find this stack trace at all. I therefore think it is fixed in cvs.

Since I have no way to reproduce this problem, there's not much I can do until I have more information. The best information would be a test case for the test system that demonstrates it.

Do not confuse this stack trace, caused by a jboss bug, with the "closing connection for you" stack trace, which so far has always turned out to be caused by user applications not closing connections.

[pkrydka]

I've had a similar problem with PostgreSql 7.3.2. I'm new to Jboss. Initially I was getting warnings saying: "WARN [WrappedConnection] Closing a statement you left open, please do your own housekeeping", and then eventually an exception was thrown saying that there wasn't enough resources, etc.

After some poking around I found my code not to be closing statements here and there. After fixing that, the problem seemed
to have dissappear.

What concerns me though is that with the above message JBoss seems to be saying that it is closing the open statement, but it seems to run out of them anyway. Does it really close it though? Maybe there's a bug there somewhere, or could this be an issue of the JDBC driver I'm using?

Here's the JDBC sequence that seems to work fine for me:

InitialContext ctx;
DataSource ds;
Connection conn;
Statement st;

ctx = new InitialContext();
ds = (DataSource) ctx.lookup(DatasourceProvider.getDSName());
conn = ds.getConnection();
...
st = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
st.executeUpdate(sql);
...
st.close();
conn.close();
ctx.close();

I noticed that accidentally closing the connection before closing the statement
would cause the problem I'm describing.

I'm not sure how this would apply to EJBs, as my app is not using them, but as far as I can tell, the connection should be opened and closed in the ejbActivate() and ejbPassivate() methods respectively too and I think the above should work.

I was experiencing the issue with Jboss 3.2 (Jetty), Red Hat 8.0, Sun JDK 1.4.1,
Jikes compiler. My datasource xml looks like this (pretty much the sample
with modified parameters), dropped to the deployment directory and accepted
ok:


<local-tx-datasource>
<jndi-name>jdbc/whatevername</jndi-name>
<connection-url>jdbc:postgresql://192.168.0.2:5432/MyProject</connection-url>
<driver-class>org.postgresql.Driver</driver-class>
<user-name>dbuser</user-name>
secret
</local-tx-datasource>


Kind Regards,
-PK

[bvallade]

I have built Jboss 3.0.7 from the latest cvs source and I am getting this same problem, with the "Trying to return an unknown connection2!" which in turn seems to result in "Successfully closed a connection for you. Please close them yourself". It seems like the problem occurs when I have more than one connection checked out from the pool in a transaction and close them in an unknown order. For example, I am able to consistently get the "Trying to return an unknown connection2!" stack trace to appear when executing the following:

try {
InitialContext ctx = getContext();
DataSource datasource = (DataSource) ctx.lookup(jndiName);
Connection conn = null;
try {
Connection con1 = datasource.getConnection();
Connection con2 = datasource.getConnection();
con2.close(); //prints "Trying to return..."
con1.close(); //works fine

con1 = datasource.getConnection();
con2 = datasource.getConnection();

con1.close(); //prints "Trying to return..."
con2.close(); //prints "Trying to return..."

conn = datasource.getConnection();
conn.close(); //prints "Trying to return..."
} catch (SQLException e) {
e.printStackTrace();
}

} catch (NamingException e) {
e.printStackTrace();
}

Also, I am obtaining/closing all connections from within a framework which has been well tested leading me to believe I am closing all my connections. When I stepped through CachedConnectionManager.closeAll(...) I noticed that the WrappedConnections that JBoss was asking me to close had their closed member variable set to true before JBoss called it's closed method. Also, these were the same connections that I had called closed on but had the "Trying to return an unknown connection2!" message appear.

Is there possibly a fix for this that has not been checked into the 3.0 branch? Are their restrictions on getting/returning connections from the pool that I may not be taking into consideration?

Brandon

[davidjencks]

Thank you for the clear example. This should be enough for me to investigate with.

david jencks

[bvallade]

David,
I was just wondering if the example I provided you resulted in the same behavior for you as it does for me. If so, great, I will keep checking for updates, otherwise, any ideas on why I would be seeing that behavior?

Thanks,
Brandon

[tbauer]

I just updated to jboss-3.2.1 and was getting all of those irritating INFO messages until I went into /server/default/deploy/transaction-service.xml and changed the attribute from false to true...the messages dissappeared...I haven't run into any condition YET where I run out of connections, so can't put it into production until I feel comfortable that it's not a problem...I will be at JBoss Bootcamp in SF to get all of my questions/problems answered!!

[tflora]

David and All,

I am also having this problem with 3.2.1 and Oracle 9i 64 bit client oci drivers.

I have done some research and have found the problem. Maybe this will point you to a solution.

Following is a snippet from my log that provides some interesting printLn statements that reveal the reason why the exception is being thrown.

As you can see the registerConnection method registers the connection with the stack object with a hashcode of 36d98810
2004-04-14 15:52:45,086 INFO [STDOUT] [registerConnection] Key: org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@36d98810
2004-04-14 15:52:45,086 INFO [STDOUT] [registerConnection] ConnectionRecord.Connection: org.jboss.resource.adapter.jdbc.WrappedConnection@37efd36
2004-04-14 15:52:45,086 INFO [STDOUT] Connection Opened.


The unregisterMethod first calls the peekMetaAwareObject method to get the last element on the LocalThread objects stack.
2004-04-14 15:52:45,120 INFO [STDOUT] [peekMetaAwareObject] Stack 0 org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@e9576fd
2004-04-14 15:52:45,121 INFO [STDOUT] [peekMetaAwareObject] Stack 1 org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@346df9bc
2004-04-14 15:52:45,121 INFO [STDOUT] [peekMetaAwareObject] Stack 2 this is the last element stack 2.
org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@36d98810

As you can see that the hash code equals the stack element that was used to register the connection above. So in the next couple of lines the unregisterConnection method is able to find and unregister the connection successfully

2004-04-14 15:52:45,121 INFO [STDOUT] [unregisterConnection] Key: org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@36d98810
2004-04-14 15:52:45,121 INFO [STDOUT] [unregisterConnection] ConnectionRecord: org.jboss.resource.adapter.jdbc.WrappedConnection@37efd36
2004-04-14 15:52:45,122 INFO [STDOUT] [unregisterConnection] Connection Object: org.jboss.resource.adapter.jdbc.WrappedConnection@37efd36
2004-04-14 15:52:45,986 INFO [STDOUT] DatabaseBroker: Opening Connection to java:/DM_CAP_APP ... Attempt 1
2004-04-14 15:52:45,987 INFO [STDOUT] [peekMetaAwareObject] Stack 0 org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@e9576fd
2004-04-14 15:52:45,988 INFO [STDOUT] [peekMetaAwareObject] Stack 1 org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@346df9bc
2004-04-14 15:52:45,988 INFO [STDOUT] [peekMetaAwareObject] Stack 2 org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@36d98810

Houston we have a problem! This is where things go wrong. Notice the registerConnection method registers this connection with the stack object with hashcode of 36d98810
2004-04-14 15:52:45,988 INFO [STDOUT] [registerConnection] Key: org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@36d98810
2004-04-14 15:52:45,989 INFO [STDOUT] [registerConnection] ConnectionRecord.Connection: org.jboss.resource.adapter.jdbc.WrappedConnection@4b7c8f7f
2004-04-14 15:52:45,989 INFO [STDOUT] Connection Opened.

But when the unregister method goes to remove it the last stack in the linked list is no longer the same one that the connection was registered with 36d98810
2004-04-14 15:52:46,121 INFO [STDOUT] [peekMetaAwareObject] Stack 0 org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@e9576fd
2004-04-14 15:52:46,121 INFO [STDOUT] [peekMetaAwareObject] Stack 1 org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@346df9bc

What happened to stack 2 the one with hash code of 36d98810? Here in lies the mystery. If you can figure out why the stack element is removed from the link list before the final connection is unregistered I believe you will be able to solve this problem.

2004-04-14 15:52:46,122 INFO [STDOUT] [unregisterConnection] Key: org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@346df9bc
2004-04-14 15:52:46,122 INFO [STDOUT] [unregisterConnection] ConnectionRecord: org.jboss.resource.adapter.jdbc.WrappedConnection@2537e19e
2004-04-14 15:52:46,122 INFO [STDOUT] [unregisterConnection] Connection Object: org.jboss.resource.adapter.jdbc.WrappedConnection@4b7c8f7f
Since the stack that was holding the registered connection is no longer available the peek method returns the wrong stack and a match for the connection is not found causing the method to drop out to the exception call
2004-04-14 15:52:46,128 INFO [org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener] throwable from unregister connection
java.lang.IllegalStateException: Trying to return an unknown connection2! org.jboss.resource.adapter.jdbc.WrappedConnection@4b7c8f7f
at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:285)
at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:550)
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:280)
at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)


I hope this helps in debugging the problem.

I look forward to hearing from you.

Thanks,

[adrian.brock]

And do you see the same thing with 3.2.3?

3.2.1 is nearly a year old - there have been a lot of fixes since then
(including a major reworking of the architecture for performance).

The original problem on this thread was solved by this fix.
http://cvs.sourceforge.net/viewcvs.py/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/CachedConnectionManager.java?r1=1.2.2.10&r2=1.2.2.11

Regards,
Adrian

[tflora]

Adrian,

We have not tried 3.2.3. We are not in a position to upgrade at this time. The code in the CachedConnectionManager is correct according to the example you pointed me to.

{
i.remove();
return;
}
}
throw new IllegalStateException("Trying to return an unknown connection2! " + c);
}

Because the return statement in the loop is never executed this proposed solution still throws the exception. This only happens with Oracle 9i 64 bit client, Java 64 bit, on a Solaris server.

I will attempt to get resources to test 3.2.3 but am hardpressed to upgrade at this time.

Regards,