Bugs item #773839, was opened at 2003-07-18 18:26
Message generated for change (Comment added) made by ejort
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: Adrian Brock (ejort)
Date: 2003-07-22 15: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 09: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 01: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
