[JBoss-dev] [ jboss-Bugs-1073564 ] CachedConnectionManager - inUseConnections not correct
Bugs item #1073564, was opened at 2004-11-26 06:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Purush Rudrakshala (prudrakshala) Assigned to: Nobody/Anonymous (nobody) Summary: CachedConnectionManager - inUseConnections not correct Initial Comment: Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 For CachedConnectionManager service debug option is enabled to monitor connections. true Using jmx-console, if we look at the "inUseCount" property. The number displayed is not consitent with the underlying connection pool. "listInUseConnections" shows stack traces for connections that have been closed long back. It take a long time for the "inUseCount" to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-1073564 ] CachedConnectionManager - inUseConnections not correct
Bugs item #1073564, was opened at 2004-11-26 06:39 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 Category: JBossServer Group: v3.2 Status: Open >Resolution: Postponed Priority: 5 Submitted By: Purush Rudrakshala (prudrakshala) >Assigned to: Adrian Brock (ejort) Summary: CachedConnectionManager - inUseConnections not correct Initial Comment: Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 For CachedConnectionManager service debug option is enabled to monitor connections. true Using jmx-console, if we look at the "inUseCount" property. The number displayed is not consitent with the underlying connection pool. "listInUseConnections" shows stack traces for connections that have been closed long back. It take a long time for the "inUseCount" to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- >Comment By: Adrian Brock (ejort) Date: 2004-11-29 17:25 Message: Logged In: YES user_id=9459 Please provide an example that reproduces the problem, or the logging as described here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=46931 The stacktraces of the unclosed connection might also be useful, don't you think? The two counts are actually different. The pool shows ManagedConnections, e.g. org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnetion the CCM (CachedConnectionManager) shows connection handles org.jboss.resource.adapter.jdbc.WrappedConnection as seen by the applications. Were the connections shown in the CCM linked to ManagedConnections that were closed due to an error rather than a user request to close them? Did you receive an unclosed connection warning for these connections or are these not requested from the ejb layer? The stacktrace should show this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-1073564 ] CachedConnectionManager - inUseConnections not correct
Bugs item #1073564, was opened at 2004-11-26 06:39 Message generated for change (Comment added) made by prudrakshala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: Postponed Priority: 5 Submitted By: Purush Rudrakshala (prudrakshala) Assigned to: Adrian Brock (ejort) Summary: CachedConnectionManager - inUseConnections not correct Initial Comment: Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 For CachedConnectionManager service debug option is enabled to monitor connections. true Using jmx-console, if we look at the "inUseCount" property. The number displayed is not consitent with the underlying connection pool. "listInUseConnections" shows stack traces for connections that have been closed long back. It take a long time for the "inUseCount" to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- >Comment By: Purush Rudrakshala (prudrakshala) Date: 2004-11-30 02:06 Message: Logged In: YES user_id=1150762 I will try to re-produce this with a test case using sample database. There are no unclosed connection warnings or any errors. Based on the CCMs stack trace for listInUseConnections, I checked the code to make sure the connections are closed properly in finally block. These are not happing in EJB layers. POJO calls to JDBC directly from HTTP requests. -- Comment By: Adrian Brock (ejort) Date: 2004-11-29 17:25 Message: Logged In: YES user_id=9459 Please provide an example that reproduces the problem, or the logging as described here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=46931 The stacktraces of the unclosed connection might also be useful, don't you think? The two counts are actually different. The pool shows ManagedConnections, e.g. org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnetion the CCM (CachedConnectionManager) shows connection handles org.jboss.resource.adapter.jdbc.WrappedConnection as seen by the applications. Were the connections shown in the CCM linked to ManagedConnections that were closed due to an error rather than a user request to close them? Did you receive an unclosed connection warning for these connections or are these not requested from the ejb layer? The stacktrace should show this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-1073564 ] CachedConnectionManager - inUseConnections not correct
Bugs item #1073564, was opened at 2004-11-26 06:39 Message generated for change (Settings changed) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 Category: JBossServer Group: v3.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Purush Rudrakshala (prudrakshala) Assigned to: Adrian Brock (ejort) Summary: CachedConnectionManager - inUseConnections not correct Initial Comment: Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 For CachedConnectionManager service debug option is enabled to monitor connections. true Using jmx-console, if we look at the "inUseCount" property. The number displayed is not consitent with the underlying connection pool. "listInUseConnections" shows stack traces for connections that have been closed long back. It take a long time for the "inUseCount" to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- >Comment By: Adrian Brock (ejort) Date: 2004-11-30 14:29 Message: Logged In: YES user_id=9459 Try configuring the CCM valve configured for Tomcat. It is commented out by default. The setting true is useless for web applications without it. See deploy/jbossweb-tomcat50.sar/server.xml (at the bottom). If you try it with JBoss4, the valve also includes checks for unfinished user transactions. I'm closing to close this, since it looks a misconfiguration of the debug settings. Please reopen if you still have a problem after adding the valve. -- Comment By: Purush Rudrakshala (prudrakshala) Date: 2004-11-30 02:06 Message: Logged In: YES user_id=1150762 I will try to re-produce this with a test case using sample database. There are no unclosed connection warnings or any errors. Based on the CCMs stack trace for listInUseConnections, I checked the code to make sure the connections are closed properly in finally block. These are not happing in EJB layers. POJO calls to JDBC directly from HTTP requests. -- Comment By: Adrian Brock (ejort) Date: 2004-11-29 17:25 Message: Logged In: YES user_id=9459 Please provide an example that reproduces the problem, or the logging as described here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=46931 The stacktraces of the unclosed connection might also be useful, don't you think? The two counts are actually different. The pool shows ManagedConnections, e.g. org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnetion the CCM (CachedConnectionManager) shows connection handles org.jboss.resource.adapter.jdbc.WrappedConnection as seen by the applications. Were the connections shown in the CCM linked to ManagedConnections that were closed due to an error rather than a user request to close them? Did you receive an unclosed connection warning for these connections or are these not requested from the ejb layer? The stacktrace should show this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-1073564 ] CachedConnectionManager - inUseConnections not correct
Bugs item #1073564, was opened at 2004-11-26 06:39 Message generated for change (Comment added) made by prudrakshala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 >Category: JBossCX Group: v3.2 >Status: Open >Resolution: None Priority: 5 Submitted By: Purush Rudrakshala (prudrakshala) Assigned to: Adrian Brock (ejort) Summary: CachedConnectionManager - inUseConnections not correct Initial Comment: Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 For CachedConnectionManager service debug option is enabled to monitor connections. true Using jmx-console, if we look at the "inUseCount" property. The number displayed is not consitent with the underlying connection pool. "listInUseConnections" shows stack traces for connections that have been closed long back. It take a long time for the "inUseCount" to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- >Comment By: Purush Rudrakshala (prudrakshala) Date: 2004-12-02 09:39 Message: Logged In: YES user_id=1150762 The CCM valve in Tomcat server.xml was already enabled also. If you have a test web app with connection pools, you might be able to re-produce this in JMX console. I am currently travelling and it will take me a few days to produce a test case. Why do you say CCM Mbean "Debug" attribute is useless for web applications? I could see listInUseConnections even without CCM valve in tomcat server.xml. -- Comment By: Adrian Brock (ejort) Date: 2004-11-30 14:29 Message: Logged In: YES user_id=9459 Try configuring the CCM valve configured for Tomcat. It is commented out by default. The setting true is useless for web applications without it. See deploy/jbossweb-tomcat50.sar/server.xml (at the bottom). If you try it with JBoss4, the valve also includes checks for unfinished user transactions. I'm closing to close this, since it looks a misconfiguration of the debug settings. Please reopen if you still have a problem after adding the valve. -- Comment By: Purush Rudrakshala (prudrakshala) Date: 2004-11-30 02:06 Message: Logged In: YES user_id=1150762 I will try to re-produce this with a test case using sample database. There are no unclosed connection warnings or any errors. Based on the CCMs stack trace for listInUseConnections, I checked the code to make sure the connections are closed properly in finally block. These are not happing in EJB layers. POJO calls to JDBC directly from HTTP requests. -- Comment By: Adrian Brock (ejort) Date: 2004-11-29 17:25 Message: Logged In: YES user_id=9459 Please provide an example that reproduces the problem, or the logging as described here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=46931 The stacktraces of the unclosed connection might also be useful, don't you think? The two counts are actually different. The pool shows ManagedConnections, e.g. org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnetion the CCM (CachedConnectionManager) shows connection handles org.jboss.resource.adapter.jdbc.WrappedConnection as seen by the applications. Were the connections shown in the CCM linked to ManagedConnections that were closed due to an error rather than a user request to close them? Did you receive an unclosed connection warning for these connections or are these not requested from the ejb layer? The stacktrace should show this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-1073564 ] CachedConnectionManager - inUseConnections not correct
Bugs item #1073564, was opened at 2004-11-26 06:39 Message generated for change (Comment added) made by prudrakshala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Purush Rudrakshala (prudrakshala) Assigned to: Adrian Brock (ejort) Summary: CachedConnectionManager - inUseConnections not correct Initial Comment: Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 For CachedConnectionManager service debug option is enabled to monitor connections. true Using jmx-console, if we look at the "inUseCount" property. The number displayed is not consitent with the underlying connection pool. "listInUseConnections" shows stack traces for connections that have been closed long back. It take a long time for the "inUseCount" to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- >Comment By: Purush Rudrakshala (prudrakshala) Date: 2004-12-03 02:25 Message: Logged In: YES user_id=1150762 I am attaching test.jsp that reproduces this problem. After running the test.jsp few times, please look at CCM "inUseConnections" count and run "listInUseConnections" operation. In my tests, I see as follows: [EMAIL PROTECTED]: STACKTRACE at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:319) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:525) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:887) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102) at org.apache.jsp.test_jsp._jspService(test_jsp.java:58) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process
[JBoss-dev] [ jboss-Bugs-1073564 ] CachedConnectionManager - inUseConnections not correct
Bugs item #1073564, was opened at 2004-11-25 22:39 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Purush Rudrakshala (prudrakshala) Assigned to: Adrian Brock (ejort) Summary: CachedConnectionManager - inUseConnections not correct Initial Comment: Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 For CachedConnectionManager service debug option is enabled to monitor connections. true Using jmx-console, if we look at the "inUseCount" property. The number displayed is not consitent with the underlying connection pool. "listInUseConnections" shows stack traces for connections that have been closed long back. It take a long time for the "inUseCount" to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- >Comment By: Scott M Stark (starksm) Date: 2004-12-05 17:19 Message: Logged In: YES user_id=175228 This is being tracked via the following jira issue: http://jira.jboss.com/jira/browse/JBAS-31 -- Comment By: Purush Rudrakshala (prudrakshala) Date: 2004-12-02 18:25 Message: Logged In: YES user_id=1150762 I am attaching test.jsp that reproduces this problem. After running the test.jsp few times, please look at CCM "inUseConnections" count and run "listInUseConnections" operation. In my tests, I see as follows: [EMAIL PROTECTED]: STACKTRACE at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:319) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:525) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:887) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102) at org.apache.jsp.test_jsp._jspService(test_jsp.java:58) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPip
[JBoss-dev] [ jboss-Bugs-1073564 ] CachedConnectionManager - inUseConnections not correct
Bugs item #1073564, was opened at 2004-11-25 22:39 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1073564&group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Purush Rudrakshala (prudrakshala) Assigned to: Adrian Brock (ejort) Summary: CachedConnectionManager - inUseConnections not correct Initial Comment: Environment: Windows XP SP2, JDK 1.4.2_05, JBoss 3.2.6 For CachedConnectionManager service debug option is enabled to monitor connections. true Using jmx-console, if we look at the "inUseCount" property. The number displayed is not consitent with the underlying connection pool. "listInUseConnections" shows stack traces for connections that have been closed long back. It take a long time for the "inUseCount" to drop down, but never drops to 0 even after the connection pools correctly show inUseCount as 0. -- Comment By: Scott M Stark (starksm) Date: 2004-12-29 12:52 Message: Logged In: YES user_id=175228 All issues have been moved to http://jira.jboss.com. Existing issues have been moved. New issues will be closed with this canned reponse. -- Comment By: Scott M Stark (starksm) Date: 2004-12-05 17:19 Message: Logged In: YES user_id=175228 This is being tracked via the following jira issue: http://jira.jboss.com/jira/browse/JBAS-31 -- Comment By: Purush Rudrakshala (prudrakshala) Date: 2004-12-02 18:25 Message: Logged In: YES user_id=1150762 I am attaching test.jsp that reproduces this problem. After running the test.jsp few times, please look at CCM "inUseConnections" count and run "listInUseConnections" operation. In my tests, I see as follows: [EMAIL PROTECTED]: STACKTRACE at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:319) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:525) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:887) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102) at org.apache.jsp.test_jsp._jspService(test_jsp.java:58) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.
