You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Jason Rosenberg (JIRA)" <ji...@apache.org> on 2008/02/06 17:52:36 UTC
[jira] Created: (AMQ-1581) PooledConnections don't initialize
correctly when broker not available (causes problems with Failover)
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
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.
[jira] Updated: (AMQ-1581) PooledConnections don't initialize
correctly when broker not available (causes problems with Failover)
Posted by "Jason Rosenberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Rosenberg updated AMQ-1581:
---------------------------------
Attachment: FailoverTransport.java
ConnectionPool.java
I've included a patch built against a recent 5.1-SNAPSHOT source (svn rev 618082)
The file ConnectionPool.java, contains part of my fix for this issue.
The file FailoverTransport.java, includes fixes for 4 issues, including part of my fix for this issue.
The other issues that this patch includes fixes for are:
AMQ-1116
AMQ-1575
AMQ-1577
AMQ-1581
I've added comments in the code that clearly indicate which sections apply to which issue, so you can easily take edit to include only the fixes you want specifically.
Jason
> 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
> 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.
[jira] Resolved: (AMQ-1581) PooledConnections don't initialize
correctly when broker not available (causes problems with Failover)
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (AMQ-1581) PooledConnections don't initialize
correctly when broker not available (causes problems with Failover)
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-1581:
-------------------------------
Assignee: Rob Davies
> 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
> 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.