[
https://issues.apache.org/activemq/browse/AMQ-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Davies resolved AMQ-1581.
-----------------------------
Resolution: Fixed
Fix Version/s: 5.1.0
Fixed by svn revision 619336
> PooledConnections don't initialize correctly when broker not available
> (causes problems with Failover)
> ------------------------------------------------------------------------------------------------------
>
> Key: AMQ-1581
> URL: https://issues.apache.org/activemq/browse/AMQ-1581
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Environment: 5.1-SNAPSHOT
> Reporter: Jason Rosenberg
> Assignee: Rob Davies
> Fix For: 5.1.0
>
> Attachments: ConnectionPool.java, FailoverTransport.java
>
>
> In working with PooledConnections, I've found that there is a timing race
> condition that can occur on the initialization of new ConnectionPool objects.
> The ConnectionPool object adds a custom TransportListener, which implements
> the onException method, in order to be informed when the transport has
> failed, so that it can properly execute its 'expiredCheck' method, and allow
> the PooledConnectionFactory to remove it from the ConnectionPool....
> In the case of using an underlying FailoverTransport, which sets the
> maxReconnectAttempts to something small, such as "2", then it's possible that
> the FailoverTransport could fail prior to the ConnectionPool object
> completing it's own initialization, and thus prior to it's adding it's
> TransportListener to the connection. I would expect there are other
> transports that could also fail immediately and have the same behavior.
> This scenario is readily reproducible in the case where the client is started
> up with no broker available.
> I've found a solution by adding a simple check after the call to
> addTransportListener, to check for any prior transport failed, by calling
> 'connection.isTransportFailed()', and setting the 'hasFailed' flag if true.
> This will update the flag for those cases that did not successfully add the
> transport listener prior to that initial failure.
> Without this fix, the ConnectionPool is unusable, in that the underlying
> connection will never be evicted to from the PooledConnectionFactory....This
> is especially pronounced if the idleTimeout is set to 0, and it never
> recovers.
> Jason
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
