activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Davies (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AMQ-1581) PooledConnections don't initialize correctly when broker not available (causes problems with Failover)
Date Thu, 07 Feb 2008 10:03:38 GMT

     [ 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.


Mime
View raw message