06
Oct
08

matchManagedConnections short tip

Be aware that the container may send invalid connections to the matchManagedConnections method and if you happen to return any of the invalid connections it’ll give it back to the application. This check is important since connectionErrorOccurred is only safe to be called while connection is in use. Some containers have optimizations that deny you from calling while connection is not in use by the application (more exactly while in the pool).

So even if your ManagedConnectionFactory implements the interface ValidatingManagedConnectionFactory you should also check for invalid connections during the selection of a matching connection inside matchManagedConnections method.
The getInvalidConnections method usually is called after one connection has been detected as invalid (after a valid call to connectionErrorOccurred) or by a container timer thread (on WebSphere this timeout is specified in the reap time parameter).

Advertisements

9 Responses to “matchManagedConnections short tip”


  1. 1 Dan
    November 17, 2008 at 1:32 pm

    When does WebSphere call getInvalidConnections?

  2. November 17, 2008 at 2:07 pm

    Dan,

    As I have noticed during some debugs, it is triggered when there is a failing connection and I suppose (this I have not seen in fact but I guess it does) when the “Reap time” timeout of the connection pool gets elapsed.
    Are you implementing a connector to be run on WAS as well? I am facing some difficulties on connection invalidation as well and I’d like to exchange some ideas. It seems like the CONNECTION_ERROR event is not removing the connection from the pool (or at least getInvalidConnections gets triggered but there are dangling connections in the pool).

    regards,
    Rafael

  3. 3 Dan
    November 17, 2008 at 2:40 pm

    Hi Rafael,

    Yes I am implementing a connector on WAS. My problem is if the third party system never releases the connection, my connection in WAS stays opened and eventually the connection pool is full. My idea was to use the getInvalidConnection to remove these long running connections. This method never appears to be called in my case (even with reap time exceeded), possibly because the connection is still marked as in use.

    What is your problem? You are marking connections as invalid but they are not being cleaned up correctly?

  4. November 17, 2008 at 3:03 pm

    Hi Dan!

    But is the connection release to pool related with the life cycle of the connection with the legacy system? I guess it is only related in the case of a fault. In a normal scenario of usage you use the connection and call some method that is supposed to be a close, I say supposed cause you don’t really close the connection you trigger a CONNECTION_CLOSED event on the JCA Managed Connection and the (in WAS) PoolManager takes care of putting it back to the pool and marking it as available for use in the next method call. Another scenario is when you use lazy associatable connections, this way you can have the handle forever in the bean (have it created on ejbCreate for example) and never formally released, then, the container takes care of dissociating the physical connection at the end of the call and reassociating at the next call. But for this you need to enable an option called “Manage cached handles” in the “Advanced connection factory” menu and also your Managed connection needs to be aware of this improvement (check if the ConnectionManager being passed is assignable from LazyAssociatableConnectionManager (http://www.ibm.com/developerworks/java/library/j-jca1/).

    Now let me explain my problem, my physical connections extends a Thread object cause they need to check for “pings” from the legacy system (legacy system sends a packet I need to reply them asap. It could have been a Work to be used with the WorkManager but I chose to make it simple). Sometimes the legacy system may go down and the connection gets closed so I need to send a CONNECTION_ERROR_OCCURRED event to signal that this connection is no longer usable. As I know that only one connection may get dropped due to TCP/IP issues, I am using the “FailingConnectionOnly” Purge Policy, so, only this connection should get dropped. Problem is, I guess, somehow that I am facing a race condition inside my pool or something alike. When the whole pool fails (all the connections get an IOException and trigger a CONNECTION_ERROR_OCCURRED) one by one they are throwing the events and concurrently the first one triggers a getInvalidConnection on WAS side. Strangely enough, some of the connections does not get removed from the pool and next time my EJB calls a getConnection I get a connection in an “Invalid_state”.

  5. 5 Dan
    November 18, 2008 at 6:27 pm

    Hi Rafaelri,

    Are you saying that WAS will not handle the CONNECTION_ERROR_OCCURRED event per connection but per adapter?

    It is possible that this is the reason for the different purge policies. Do things work correctly with the “entirePool” purge policy?

    Dan

  6. November 19, 2008 at 3:01 pm

    Hi Dan!

    No. I was saying that I am facing a strange behaviour with the “FailingConnectionOnly” purge policy. Instead of removing the failing connection from the pool it is leaving it there in the pool in a dangling state. And yes, that’s the reason WAS offers 2 purge policies. EntirePool will clean up the whole pool in case a connection fails and, as I have noticed during debugging, FailingConnectionOnly should remove the failing connection but still it’d trigger the getInvalidConnections on this pool to check if there are more failing connections.

    regards,

  7. November 22, 2008 at 3:59 pm

    Dan,

    I tried with EntirePool and got the same weird behaviour. Seems like the inactive ManagedConnection is being put back in the pool and after WAS tries to get it back from there and reuse. Today I’ve tested my FooConnector (I did a simple test to mimify the problem) on JBoss and it worked fine. On monday I’ll do some tests on Weblogic as well (tried on friday but WL makes it really hard) so I can certify that it is WAS related and file a PMR. Also I’ll try to apply the latest (19) fixpack. Since I am still running with 17. Do you have any tips for applying FP19? I tried but it seems like there are some not-so-trivial pre-reqs. UpdateInstaller wasn’t willing to let me apply them.

    regards.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


ClustrMaps

Blog Stats

  • 358,409 hits since aug'08

%d bloggers like this: