Bugs item #773839, was opened at 2003-07-18 20:26 Message generated for change (Comment added) made by janssk1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=773839&group_id=22866
Category: JBossCX Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: gui (janssk1) Assigned to: Adrian Brock (ejort) Summary: Exception handling in JCA adapter Initial Comment: Hello, I have some issues with the exception handling of exceptions thrown by a custom JCA adapter. If an exception occurs during the creation of a managed connection, this is handled correcly (the managed connection is removed from the pool) However, if an exception occurs during retrieval of a handle (getConnection()), the managed connection is not given back to the pool (i think that's a bug). The availbleconnectioncount is decreased but there is not way to release the managed connection since the creation of the handle failed. To prevent this behavior, i am forced to send a 'errorOccured' event before throwing an exception during creation of a handle. But sending this event will destroy the underlying managed connection, which is not exactely what i want. I want the managed connection to be returned to the pool if the getConnection throws an exception. This prevents excessive destroying of (wellbehaved) managed connections. Another issue is related to closing a 'destroyed' connection handle. Suppose a major error occurs on the underlying managed connection during some operation on a handle. According to the spec, i send a notifyError to let the container know that this connection is no longer useable and throw an exception to the user code. This user code will typically notice the exception and close the handle. But then there's an issue: The close operation is called on a handle of a 'destoyed' managed connection. Should i in the close of the handle still send the connectionClosed event ? If i do it, jboss complains (thows an exception) about trying to close a destoyed connection. If i don't, i get the 'please to your own housekeeping' message. I think jboss should *or* automatically close the handle if a fatal error occurs *or* still allow the connectionClosed event to be send. Any comments are highly appreciated.. ---------------------------------------------------------------------- >Comment By: gui (janssk1) Date: 2003-07-22 18:13 Message: Logged In: YES user_id=769377 >For the first problem there are tests in the testsuite for >createManagedConnection and matchManagedConnection >throwing >both Resource and RuntimeExceptions. Neither shows a leak >in the available connections. But as far as i can see, there are no tests covering exceptions thrown during getConnection(). I think if you add test that throws an exception during the creation of a connection handle (not a managed connection), you should see the behavior. If you still don't see the problem in your tests, let me know and i will send you some traces from my setup. By the way, i am quite sure it's not the first assert that fails, since i actually don't have the first assert in my test. I added it here only for clarity. I have a bunch of other test that also use the getAssignedConnectionCount and they do work. About the second problem: which solution do you suggest ? -don't send a connection closed leading to 'do your own housekeeping message' -send a connection closed and catch the exception comming from the listener Are you sure that the cleanup is done correctly in the second case ? Regards Koen. ---------------------------------------------------------------------- Comment By: Adrian Brock (ejort) Date: 2003-07-22 17:13 Message: Logged In: YES user_id=9459 For the first problem there are tests in the testsuite for createManagedConnection and matchManagedConnection throwing both Resource and RuntimeExceptions. Neither shows a leak in the available connections. This might be a stupid question, but are you sure it is not the first assert that fails? The pools are lazily instantiated. You will get no available connections if there are no pools because no previous request for a connection was made. Can you post the results from getAssignedConnectionCount() both before and after the test? Failing that, since you cannot provide example code, perhaps you can provide the log. Enabling TRACE for org.jboss.resource would may help. For the second problem, I see your problem now. The adaptor in the testsuite catches unchecked exceptions thrown by connectionClosed which I is why I wasn't seeing this before. However, it does not seem to correct to me to notify connectionClosed (please return this ManagedConnection to the pool) after you have been told to destroy that ManagedConnection. NOTE: This is not explicitly defined in the spec, I am open to arguments in other directions that do not introduce extra booking in the connection manager under normal operations. Regards, Adrian ---------------------------------------------------------------------- Comment By: gui (janssk1) Date: 2003-07-22 11:43 Message: Logged In: YES user_id=769377 I am using 3.2.2RC1. The first problem is not solved in this release. This is part of our test code that causes a failure: assertEquals(0,getAssignedConnectionCount()); try { AsamTl1ConnectionFactory fact = TestUtil.getConnectionFactory(); try { conn = fact.createConnection(param); fail("expected an exception"); } catch (ResourceException re) { // expected behaviour } } finally { m_log.debug("closing resources"); if (conn != null) { conn.close(); } if (jndi != null) { jndi.close(); } } assertEquals(0,getAssignedConnectionCount()); Note that the actual exception is thrown in the getConnection and no errorOccured event is fired. The last assert fails. The getAssignedConnectionCount is implemented as: Long availableCount = (Long) m_server.getAttribute( m_poolName, "AvailableConnectionCount"); return m_maximumConnectionCount- availableCount.longValue(); --------------------------------- You can find the stacktrace of the second problem below. I think i also know why you don't have the problem in your test. Inside the connectionError of the TestManagedConnection,a try catch block is written around the listener call, hiding all exceptions. testConnectionCommandTimeOut (com.alcatel.ni.adapter.tl1.Tl1AdapterTest) java.lang.IllegalArgumentException: disconnect (ManagedConnection mc: [EMAIL PROTECTED] 14, Object c: [EMAIL PROTECTED] 14) called with unknown managed connection at org.jboss.resource.connectionmanager.BaseConnectionManage r2.unregisterAssociation(BaseConnectionManager2.java:617) at org.jboss.resource.connectionmanager.NoTxConnectionManage r$NoTxConnectionEventListener.connectionClosed (NoTxConnectionManager.java:108) at com.alcatel.ni.adapter.tl1.AsamTl1ManagedConnection.notifyCl osed(AsamTl1ManagedConnection.java:256) at com.alcatel.ni.adapter.tl1.AsamTl1ManagedConnection.close (AsamTl1ManagedConnection.java:169) at com.alcatel.ni.adapter.tl1.Tl1AdapterTest.testConnectionCom mandTimeOut(Tl1AdapterTest.java:542) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at net.sourceforge.junitejb.EJBTestCase.runBare (EJBTestCase.java:133) at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase (EJBTestRunnerBean.java:102) at net.sourceforge.junitejb.EJBTestRunnerBean.run (EJBTestRunnerBean.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.i nvoke(StatelessSessionContainer.java:646) at org.jboss.resource.connectionmanager.CachedConnectionInter ceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:84) at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext (AbstractTxInterceptorBMT.java:144) at org.jboss.ejb.plugins.TxInterceptorBMT.invoke (TxInterceptorBMT.java:62) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invo ke(StatelessSessionInstanceInterceptor.java:72) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:117) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke (ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke (StatelessSessionContainer.java:323) at org.jboss.ejb.Container.invoke (Container.java:673) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke (JRMPInvoker.java:359) at sun.reflect.GeneratedMethodAccessor98.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run (Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall (Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (TCPTransport.java:701) at java.lang.Thread.run(Thread.java:536) ---------------------------------------------------------------------- Comment By: Adrian Brock (ejort) Date: 2003-07-21 03:05 Message: Logged In: YES user_id=9459 Hi, First, which version of jboss are you using? Your first problem sounds like the semaphore leak fixed in 3.0.8/3.2.2RC1 where an unchecked throwable was not handled correctly by the pool. For the second problem, I cannot find the exception you describe in the current source, can you post the stacktrace? I have also added some tests to the testsuite for connection failures that destroys the connection. A subsequent invocation of connectionClosed() does not cause the problems you describe. Perhaps you can compare your resource adapter with the one in the jboss testsuite and explain what changes are required to reproduce your problem? NOTE: My new tests may not appear for 24hrs on the web interface. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jbosstest/src/main/org/jboss/test/jca/adapter/?only_with_tag=Branch_3_2 Regards, Adrian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=773839&group_id=22866 ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development