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: Accepted
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 22:32
Message:
Logged In: YES
user_id=9459
Ok, the cognitive dissonance has cleared :-)
Yes, the problem is not in the pool but in the connection
manager.
It represents a leak of the managed connection when it is
retrieved from the pool but
ManagedConnection.getConnection() fails.
I will also fix it so that when the connectionErrorOccurred
notification
occurs, it tidies up the handles in both
the connection manager and the cached connection manager.
I also need to fix our jdbc resource adapters so they don't
try to notify
of a close after the mcs have been destroyed. This is just an
excercise in reducing the noise on the logs. It should not cause
any errors.
Some further investigation is required to determine whether the
transaction semantics are correct in the TxConnectionManagers.
I suspect this case is already catered for with the failure to
prepare/commit the resources causing a rollback, but it needs
testing.
Regards,
Adrian
----------------------------------------------------------------------
Comment By: gui (janssk1)
Date: 2003-07-22 16: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 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
