Destroying connection that could not be successfully matched

[daphna]

We are using ConnectionManager.allocateConnection () to retrieve connections from the pool with our implementation of the ManagedConnectionFactory and ConnectionRequestInfo).

Once our code reaches:
InternalManagedConnectionPool.getConnection(Subject subject, ConnectionRequestInfo cri),

there is only one object in the available connection event listeners list (InternalManagedConnectionPool.cls), and it doesn't match the cri we are looking for and therefore we get the:
"Destroying connection that could not be successfully matched: "
warning message:
12:39:40,506 WARN [JBossManagedConnectionPool] Destroying connection that could not be successfully matched: org.jboss.resou
rce.connectionmanager.NoTxConnectionManager$NoTxConnectionEventListener@92b371[state=NORMAL mc=com.cisco.nm.cmp.gjc.GWManaged
Connection@181f366 handles=0 lastUse=1197801580272 permit=false trackByTx=false mcp=org.jboss.resource.connectionmanager.JBos
sManagedConnectionPool$OnePool@1ac0dde context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@c2813e]

We are using Java1.5 & Jboss4.2.0GA

[vickyk]

I need to see the logs to get more details , enable the log tracing for org.jboss.resource.connectionmanager.JBossManagedConnectionPool and attach it here .

try
 {
 Object matchedMC = mcf.matchManagedConnections(Collections.singleton(cl.getManagedConnection()),
 subject, cri);
 if (matchedMC != null)
 {
 if (trace)
 log.trace("supplying ManagedConnection from pool: " + cl);
 cl.grantPermit(true);
 return cl;
 }

 //Match did not succeed but no exception was thrown.
 //Either we have the matching strategy wrong or the
 //connection died while being checked. We need to
 //distinguish these cases, but for now we always
 //destroy the connection.
 log.warn("Destroying connection that could not be successfully matched: " + cl);
 synchronized (cls)
 {
 checkedOut.remove(cl);
 }

The above code is from
http://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_2/connector/src/main/org/jboss/resource/connectionmanager/InternalManagedConnectionPool.java

It is this code which is displaying the warning .
Looks to me the issue with matchManagedConnection implementation of MCF .
Give me more details about the MCF implementation of matchManagedConnection .

[daphna]

Hi Vick,
Thanks for your reply.
It seems that InternalManagedConnectionPool.getConnection() always retrieves the last member of available connections, without trying to find the corret one:

cl = (ConnectionListener) cls.remove(cls.size() - 1);

Does this inplementation expects to find only one member in the list?

Our code for GWManagedConnectionFactory.matchManagedConnections() is as following:
public ManagedConnection matchManagedConnections(Set connectionSet, Subject subject, ConnectionRequestInfo info)
throws ResourceException {

// The contents of connectionSet cannot change during this call, so no need to synchonize the Iterator
Iterator iter = connectionSet.iterator();
boolean found = false;
GWManagedConnection retConnection = null;
while (iter.hasNext() && !found) {
GWManagedConnection mc = (GWManagedConnection) iter.next();
if ((mc != null) && mc.getGWConnectionRequestInfo().equals(info)) {
found = true;
retConnection = mc;
}
}
return retConnection;
}

GWManagedConnection implements ManagedConnection

I will email you the server.log with trace enabled.
Thanks
Daphna

[vickyk]

It seems that InternalManagedConnectionPool.getConnection() always retrieves the last member of available connections, without trying to find the corret one:

No that is not correct , these connections are already matched .

mc.getGWConnectionRequestInfo().equals(info)

This seems to be faling .
Put some logging in the MCF's matchManagedConnection(..) , this method looks incorrect to me .
Have you overridden the equals(..) of GWConnectionRequestInfo ?
Have a look at the implementation of WrappedConnectionrequest.java at
https://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_2/connector/src/main/org/jboss/resource/adapter/jdbc/WrappedConnectionRequestInfo.java
?

[daphnaw]

Hi Vicky,

MCF's matchManagedConnection(..) method receives a single ManagedConnection object (argA), a subject, and a ConnectionRequestInfo object ("argC").

While debugging, I've seen that the ConnectionRequestInfo retrieved from the ManagedConnection ("argA") is different from the ConnectionRequestInfo passed as argument ("argC"); i.e. connections of 2 different users.

Therefore, I don't think the problem is in the GWConnectionRequestInfo.equals() implementation, because the 2 objects don't equal to begin with.

What did you mean by "these connections are already matched " ? Where are they matched? Could this be the problem?

[vickyk]

"daphnaw" wrote:

What did you mean by "these connections are already matched " ? Where are they matched? Could this be the problem?

They are matched before the free connection is taken from the subpool .

// Determine the pool key for this request
 boolean separateNoTx = false;
 if (noTxSeparatePools)
 separateNoTx = clf.isTransactional();
 Object key = getKey(subject, cri, separateNoTx);
 SubPoolContext subPool = getSubPool(key, subject, cri);

 InternalManagedConnectionPool mcp = subPool.getSubPool();

Here is the code
http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss/resource/connectionmanager/JBossManagedConnectionPool.java

The MCF's matchManagedConnection(..) should be implemented properly .

[adrian.brock]

"daphnaw" wrote:

What did you mean by "these connections are already matched " ? Where are they matched? Could this be the problem?

Read the FAQ. In particualr, add

<application-managed-security/>

if your connections are not all equivalent.

[daphna]

adrian wrote:

Read the FAQ. In particualr, add <application-managed-security/>

Sorry for my delayed reply.
Can you please refer me to the exact FAQ?
I haven't found the <application-managed-security/> entry in our application. Where exactly is it added ?

[vickyk]

"daphna" wrote:

Can you please refer me to the exact FAQ?
I haven't found the <application-managed-security/> entry in our application. Where exactly is it added ?

Check this
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigDataSources
http://docs.jboss.org/jbossas/jboss4guide/r5/html/ch7.chapt.html
You have add this in the -ds.xml .

Use search on Jboss site you will get more details .

[adrian.brock]

"daphna" wrote:

Can you please refer me to the exact FAQ?
I haven't found the <application-managed-security/> entry in our application. Where exactly is it added ?

I don't see why I should have to refer to a specific FAQ?
It's called the FAQ because your supposed to read it before posting
frequently repeated questions and wasting peoples time.

For those that aren't lazy and find this post using search,
the link to the overall FAQ (and also provided in the READ THIS FIRST
at the top of the forum) is here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=FAQJBossJCA
and the specific question has the not unsuprising link
http://wiki.jboss.org/wiki/Wiki.jsp?page=StrangePoolingConnectionsDestroyed

[bortx]

Hello,

I have reached this post because I am facing the same problem. I see that in the FAQ it says:

Q: I have strange pooling? Connections that are not matched in my

matchManagedConnections

are destroyed.

A: Yes this is the default/expected behaviour.

I have had a look at the jca 1.5 specification and according to this issue it says the following

If the resource adapter cannot find an acceptable ManagedConnection instance, it
returns a null value. In this case, the application server requests the resource
adapter to create a new connection instance.

So, it does not say anything in particular about this behaviour.

Now I'm gonna explain my use case, on which I consider this is not the expected behaviour:

My resource adapter holds connections, each one have an associated window, so that on a request, and identifier is stored on the window to be removed later when an ACK is received. When a request is made, it may need one or more slots on the window, so I specify a ConnectionRequestInfo with the number of slots needed.

Suppose a request is made which needs 2 slots, and all connections in the pool have 1 free slot. The matchManagedConnections method returns null and application server creates a new Connection that is returned. At this moment, if existing connections are destroyed, their associated window information and actions on ACKs are lost. Other reason for not destroy them is that as they all have 1 slot free, they should be available for other 1 slot requests. Also, they will become available as ACKs come.

I have seen that using <application-managed-security/> not only changes this behaviour, as application must implement all connection pooling task. In my case a new connection is created on each request, so I suppose that no connection management is performed by jboss. In my opinion, I consider that this behaviour should be configurable on a policy property, so you can use all jboss services in your resource adapter as matchManagedConnections method and choose what to do with no matching connections.

I only want to explain my point of view in order to contribute on improving this amazing project. Thanks a lot!

Borja

[vicky.kak]

"bortx" wrote:

I have seen that using <application-managed-security/> not only changes this behaviour, as application must implement all connection pooling task. In my case a new connection is created on each request, so I suppose that no connection management is performed by jboss.

I need to see your code , the PoolByCri should handle things for you which is configured by <application-managed-security> setting .
If you passing the ConnectionRequestInfo with the appropriate number of windows slot the Jboss pooling mechinish should be able to create multiple pools ie one pool of Connections with one window slot AND second pool of Connections with two window slot.

Speak in terms of the code ;)

[cmastrantono]

Hi everyone, I'm having a similar problem that the one is described above... could you guys give a look at it ?

http://community.jboss.org/thread/167971

Best regards!

Cristian

[utiao]

Add the node into *-ds.xml under <no-tx-connection-factory> node.

<application-managed-security/>