We are seeing a case with a JMS provider (that shall remain nameless) where prior to the ServerSessionPool being able to be recycled as the result of a provider failure, a ServerSession is being removed from the pool. As a result, the pool can never be cleared as there are outstanding Sessions and as such the cleanup code waits indefinitely for these resources to be returned. At this point, no forward progress can be made and the pool itself can never be recycled.
While this particular issue cropped up in the JMSContainerInvoker, similar logic exists in the JMS/JCA adapter. While I am loathe to provide a configuration option to wait for an interval and then just 'bail out', I am not sure how we can move forward on this as the JMS provider is similarly unwilling to make modifications with the underlying ConnectionConsumer.
