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/02 23:28:36 UTC
[jira] Created: (AMQ-1575) FailoverTransport with
MaxReconnectAttempts set does not recover quickly, when used with
ConnectionPooling....
FailoverTransport with MaxReconnectAttempts set does not recover quickly, when used with ConnectionPooling....
--------------------------------------------------------------------------------------------------------------
Key: AMQ-1575
URL: https://issues.apache.org/activemq/browse/AMQ-1575
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 5.0.0
Environment: 5.1-SNAPSHOT
Reporter: Jason Rosenberg
This entry from the users forum describes the issue (and it includes a reproducible test-case)...See the entry from me dated Dec 06, 2007.....
http://www.nabble.com/Timeout-and-Failover-on-a-queue-to13292887s2354.html#a14215834
I've confirmed that the issue happens with the latest 5.1-SNAPSHOT version, and happens with either jencks AMQPool, or the built-in activeMQ PooledConnections. The problem does not happen if no connection pooling is used.
Basically, it appears that the FailoverTransport is not properly communicating with the TransportListener when brokers return to service.
Another user ('hbuch) has created a patch, implemented for 4.1.1, which seems to solve the problem, which is also referred to in that same thread referred to above....See entry from 'hbuch' dated Dec 05, 2007.....I've verified that that fix seems to work (tested only under 4.1.1 so far)....
Anyway, it seems that this fix should be straightforward to fold back into the source code for 5.1....
Please take a look.
Thanks,
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-1575) FailoverTransport with
MaxReconnectAttempts set does not recover quickly, when used with
ConnectionPooling....
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-1575:
-------------------------------
Assignee: Rob Davies
> FailoverTransport with MaxReconnectAttempts set does not recover quickly, when used with ConnectionPooling....
> --------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-1575
> URL: https://issues.apache.org/activemq/browse/AMQ-1575
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.0.0
> Environment: 5.1-SNAPSHOT
> Reporter: Jason Rosenberg
> Assignee: Rob Davies
> Attachments: ConnectionPool.java, FailoverTransport.java
>
>
> This entry from the users forum describes the issue (and it includes a reproducible test-case)...See the entry from me dated Dec 06, 2007.....
> http://www.nabble.com/Timeout-and-Failover-on-a-queue-to13292887s2354.html#a14215834
> I've confirmed that the issue happens with the latest 5.1-SNAPSHOT version, and happens with either jencks AMQPool, or the built-in activeMQ PooledConnections. The problem does not happen if no connection pooling is used.
> Basically, it appears that the FailoverTransport is not properly communicating with the TransportListener when brokers return to service.
> Another user ('hbuch) has created a patch, implemented for 4.1.1, which seems to solve the problem, which is also referred to in that same thread referred to above....See entry from 'hbuch' dated Dec 05, 2007.....I've verified that that fix seems to work (tested only under 4.1.1 so far)....
> Anyway, it seems that this fix should be straightforward to fold back into the source code for 5.1....
> Please take a look.
> Thanks,
> 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-1575) FailoverTransport with
MaxReconnectAttempts set does not recover quickly, when used with
ConnectionPooling....
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1575.
-----------------------------
Resolution: Fixed
Fix Version/s: 5.1.0
Fixed by svn revision 619336
> FailoverTransport with MaxReconnectAttempts set does not recover quickly, when used with ConnectionPooling....
> --------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-1575
> URL: https://issues.apache.org/activemq/browse/AMQ-1575
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.0.0
> Environment: 5.1-SNAPSHOT
> Reporter: Jason Rosenberg
> Assignee: Rob Davies
> Fix For: 5.1.0
>
> Attachments: ConnectionPool.java, FailoverTransport.java
>
>
> This entry from the users forum describes the issue (and it includes a reproducible test-case)...See the entry from me dated Dec 06, 2007.....
> http://www.nabble.com/Timeout-and-Failover-on-a-queue-to13292887s2354.html#a14215834
> I've confirmed that the issue happens with the latest 5.1-SNAPSHOT version, and happens with either jencks AMQPool, or the built-in activeMQ PooledConnections. The problem does not happen if no connection pooling is used.
> Basically, it appears that the FailoverTransport is not properly communicating with the TransportListener when brokers return to service.
> Another user ('hbuch) has created a patch, implemented for 4.1.1, which seems to solve the problem, which is also referred to in that same thread referred to above....See entry from 'hbuch' dated Dec 05, 2007.....I've verified that that fix seems to work (tested only under 4.1.1 so far)....
> Anyway, it seems that this fix should be straightforward to fold back into the source code for 5.1....
> Please take a look.
> Thanks,
> 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-1575) FailoverTransport with
MaxReconnectAttempts set does not recover quickly, when used with
ConnectionPooling....
Posted by "Jason Rosenberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Rosenberg updated AMQ-1575:
---------------------------------
Attachment: FailoverTransport.java
ConnectionPool.java
I've included a patch built against a recent 5.1-SNAPSHOT source (svn rev 618082)
The file FailoverTransport.java, includes fixes for 4 issues, including hbuch's fix for this issue.
The other issues that this patch includes fixes for are:
AMQ-1116
AMQ-1575
AMQ-1577
AMQ-1581
The file ConnectionPool.java is also needed for the fix for 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
> FailoverTransport with MaxReconnectAttempts set does not recover quickly, when used with ConnectionPooling....
> --------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-1575
> URL: https://issues.apache.org/activemq/browse/AMQ-1575
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.0.0
> Environment: 5.1-SNAPSHOT
> Reporter: Jason Rosenberg
> Attachments: ConnectionPool.java, FailoverTransport.java
>
>
> This entry from the users forum describes the issue (and it includes a reproducible test-case)...See the entry from me dated Dec 06, 2007.....
> http://www.nabble.com/Timeout-and-Failover-on-a-queue-to13292887s2354.html#a14215834
> I've confirmed that the issue happens with the latest 5.1-SNAPSHOT version, and happens with either jencks AMQPool, or the built-in activeMQ PooledConnections. The problem does not happen if no connection pooling is used.
> Basically, it appears that the FailoverTransport is not properly communicating with the TransportListener when brokers return to service.
> Another user ('hbuch) has created a patch, implemented for 4.1.1, which seems to solve the problem, which is also referred to in that same thread referred to above....See entry from 'hbuch' dated Dec 05, 2007.....I've verified that that fix seems to work (tested only under 4.1.1 so far)....
> Anyway, it seems that this fix should be straightforward to fold back into the source code for 5.1....
> Please take a look.
> Thanks,
> Jason
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.