Bugs item #773074, was opened at 2003-07-17 15:47 Message generated for change (Settings changed) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=773074&group_id=22866
Category: JBossCX Group: v3.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: gui (janssk1) >Assigned to: Adrian Brock (ejort) Summary: Non spec compliant behavior of matchManagedConnections Initial Comment: the current (3.2.1 and CVS) implementation of InternalManagedConnectionPool does not match the JCA specification 1.0. The Spec. specifies that : "If the application server finds no matching ManagedConnection instance that can best handle this connection request, or if the candidate set is empty, the application server calls the ManagedConnectionFactory.createManagedConnection method." In the implementation of JBoss the behaviour is different. If the matchManagedConnection returns null (no match found) the implementation will destroy the managed connection. This is probably related to the comment made in the code: " //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. " In our case the matchManagedConnection is rather important because one managed connection cannot be replaced by another one. ---------------------------------------------------------------------- Comment By: Adrian Brock (ejort) Date: 2003-07-22 22:35 Message: Logged In: YES user_id=9459 Hi, The spec says the CRI is not intended for server connection parameters. You should be deploying an adapter for each gateway. Your assumption is correct. If you pool by application, each user will get their own pool. Regards, Adrian ---------------------------------------------------------------------- Comment By: gui (janssk1) Date: 2003-07-21 21:14 Message: Logged In: YES user_id=769377 After some code surfing, i found out that jboss does already some 'matching' depending on the criteria specified in the desciptor. It seems that a connection pool can consist of a set of internalmanagedconnectionpools. Interesting. So if i change the pool criteria to "ByApplication", a different internal pool will be created for each different cri. But this also means that the maxpool size counts per cri and not globally. If i set a maxpool of 5 and 1000 users try to get a connection to with different cris, the will all succeed leading to 1000 concurrent connection to my EIS. Is this a correct assumption ? BY the way, the current implementation of our match function does not do a simple equals on the cri's. Our cri actually consist of two parts. the first part describes which 'gateway' which have to connect to (this is a TCP connection) . this information is used in our current match method. So we pool connections to different gateways. The second part of the cri contains some 'account' information that we use in the 'getConnection()' method to do some lightwight authentication. So we cannot directly use and the "ByApplication" criteria. ---------------------------------------------------------------------- Comment By: David Jencks (d_jencks) Date: 2003-07-18 14:31 Message: Logged In: YES user_id=60525 I'd appreciate some more detail. If you have pooling set up "ByApplication" only cri's that are "equal" according to the equals method will be supplied as candidates to the match method. Can you explain what different behavior you need? I think that if relying on "equals" for cri and subject is not sufficient to assure matching then we need another pooling implementation that supplies all connections in the pool to the match method. I'm somewhat worried about concurrency with such an implementation. Thanks david jencks ---------------------------------------------------------------------- Comment By: gui (janssk1) Date: 2003-07-18 07:47 Message: Logged In: YES user_id=769377 In our case, only connectionrequest info is used for matching. The problem is that jboss is to eager to destroy non matched connections. It might well be that a connection that does not match for one request *does* match for another one. So instead of always dropping the non matched connection, it might be wiser to keep it, unless the pool is full or something. KR, Koen. ---------------------------------------------------------------------- Comment By: David Jencks (d_jencks) Date: 2003-07-17 16:45 Message: Logged In: YES user_id=60525 Can you please explain the criteria you need to use for matching ManagedConnections? For most adapters, the combination of Subject and ConnectionRequestInfo has been sufficient to ensure correct matching. I think there may be some circumstances where this is not sufficient but I'd like more information before writing another pooling implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=773074&group_id=22866 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
