You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Francisco Borges <fr...@x-hive.com> on 2007/07/09 17:13:13 UTC
allocating Connection using ConnectionRequestInfo: failure testing
Hello,
I have some code that uses ConnectionRequestInfo objects to get
connections, and also some tests for it. They all work on JBoss, but on
Geronimo1.2, things don't *fail* as I expect.
Namely, I expected that when asking for a connection using an invalid
ConnectionRequestInfo, to get an "javax.resource.spi.SecurityException"
thrown, or at least an "javax.resource.ResourceException":
http://geronimo.apache.org/api/org/apache/geronimo/connector/outbound/AbstractConnectionManager.html
Is this expectation wrong? If so, how should I check for a failed request?
I've tried deploying the connection both with <match-one/> and
<match-all/>:
======
<outbound-resourceadapter>
<connection-definition>
[.....]
<connectionmanager>
<xa-transaction>
<transaction-caching/>
</xa-transaction>
<single-pool>
<min-size>0</min-size>
<match-one/>
</single-pool>
</connectionmanager>
[....]
</outbound-resourceadapter>
======
But on both cases, I get no exceptions.
Comments & hints are heartily welcome,
Cheers,
--
Francisco Borges
Re: allocating Connection using ConnectionRequestInfo: failure testing
Posted by Francisco Borges <fr...@x-hive.com>.
On Monday 09 July 2007, David Jencks wrote:
> I imagine problems with your connection factory would be easy for you
> and impossible for us to figure out, so I'll assume the problem is
> after that.
>
> Can you do some debugging or logging and check that your CRI is
> getting to the MCF
Short answer: CRI does not make to the MCF. See below.
> javax.resource.spi.ManagedConnection createManagedConnection
> (javax.security.auth.Subject subject,
> javax.resource.spi.ConnectionRequestInfo connectionRequestInfo)
> throws javax.resource.ResourceException;
>
> javax.resource.spi.ManagedConnection matchManagedConnections
> (java.util.Set set, javax.security.auth.Subject subject,
> javax.resource.spi.ConnectionRequestInfo connectionRequestInfo)
> throws javax.resource.ResourceException;
>
> methods as expected and that your MCF is throwing an exception? This
> would help a lot in investigating what is going on.
Set up of my test is:
Pass CRI with the wrong values (unexisting DB, unexisting user etc) to
import javax.resource.cci.Connection;
import javax.resource.spi.ConnectionRequestInfo;
[...]
(Connection)connectionManager.allocateConnection(xhiveManagedConnectionFactory,
(ConnectionRequestInfo) connectionSpec);
========
JBoss (4.2.0) will:
1. Call
class ManagedConnectionFactory {
ManagedConnection matchManagedConnections(
java.util.Set set,
javax.security.auth.Subject subject,
javax.resource.spi.ConnectionRequestInfo connectionRequestInfo)
throws ResourceException
Which fails to match, deletes an unmatched connection, and returns null;
2. Call
Class ManagedConnectionFactory {
ManagedConnection createManagedConnection(Subject, ConnectionRequestInfo)
Where an exception is thrown due to the wrong parameters.
=========
On Geronimo, the code never reaches neither createManagedConnection nor
matchManagedConnections, and I get the pre-existing (valid) connection
back.
Could Geronimo be using the pool with <select-one-assume-match/>
despite the fact that I have <match-all/> in the pool configuration at
geronimo-ra.xml?
Is there somewhere else, in my code, I should be looking at?
> BTW I think you want match-all if you want to use one pool, unless
> the match method can change the CRI info in an existing connection.
> The idea behind multiple pools is that you can divide the connections
> up by the match criteria so that matches will always succeed and you
> only need to supply one MC to match. Otherwise match is likely to
> fail with distinct CRIs and the pool will start killing connections
> for you.
Thank you for pointing this out.
I was using "match-all" but started trying different things, to see if the
problem was not at the pool deployment. As getting the valid connection
back, made me think Geronimo was somehow using looked as if the pool
I decided to use single-pool based on the "tip" at the pool configuration
here
<http://chariotsolutions.com/geronimo/geronimo-1.1/connector-plan.html>,
I guess I need to ask people which is the typical usage case.
Thanks a lot for the attention and insightful comments,
Cheers,
--
Francisco Borges
Re: allocating Connection using ConnectionRequestInfo: failure testing
Posted by David Jencks <da...@yahoo.com>.
On Jul 9, 2007, at 11:13 AM, Francisco Borges wrote:
> Hello,
>
> I have some code that uses ConnectionRequestInfo objects to get
> connections, and also some tests for it. They all work on JBoss,
> but on
> Geronimo1.2, things don't *fail* as I expect.
>
> Namely, I expected that when asking for a connection using an invalid
> ConnectionRequestInfo, to get an
> "javax.resource.spi.SecurityException"
> thrown, or at least an "javax.resource.ResourceException":
>
> http://geronimo.apache.org/api/org/apache/geronimo/connector/
> outbound/AbstractConnectionManager.html
>
> Is this expectation wrong? If so, how should I check for a failed
> request?
Geronimo has no way to determine if a CRI is valid or not, so I
presume that either your connection factory or
ManagedConnectionFactory should be throwing the exception you expect.
I imagine problems with your connection factory would be easy for you
and impossible for us to figure out, so I'll assume the problem is
after that.
Can you do some debugging or logging and check that your CRI is
getting to the MCF
javax.resource.spi.ManagedConnection createManagedConnection
(javax.security.auth.Subject subject,
javax.resource.spi.ConnectionRequestInfo connectionRequestInfo)
throws javax.resource.ResourceException;
javax.resource.spi.ManagedConnection matchManagedConnections
(java.util.Set set, javax.security.auth.Subject subject,
javax.resource.spi.ConnectionRequestInfo connectionRequestInfo)
throws javax.resource.ResourceException;
methods as expected and that your MCF is throwing an exception? This
would help a lot in investigating what is going on.
BTW I think you want match-all if you want to use one pool, unless
the match method can change the CRI info in an existing connection.
The idea behind multiple pools is that you can divide the connections
up by the match criteria so that matches will always succeed and you
only need to supply one MC to match. Otherwise match is likely to
fail with distinct CRIs and the pool will start killing connections
for you.
Thanks!
david jencks
>
> I've tried deploying the connection both with <match-one/> and
> <match-all/>:
>
> ======
> <outbound-resourceadapter>
> <connection-definition>
> [.....]
> <connectionmanager>
> <xa-transaction>
> <transaction-caching/>
> </xa-transaction>
> <single-pool>
> <min-size>0</min-size>
> <match-one/>
> </single-pool>
> </connectionmanager>
> [....]
> </outbound-resourceadapter>
> ======
>
> But on both cases, I get no exceptions.
>
> Comments & hints are heartily welcome,
> Cheers,
> --
> Francisco Borges