You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Andreas Kuhtz (JIRA)" <ji...@apache.org> on 2008/06/05 13:29:00 UTC
[jira] Created: (AMQ-1771) Failover transport should always signal
resume of transport
Failover transport should always signal resume of transport
-----------------------------------------------------------
Key: AMQ-1771
URL: https://issues.apache.org/activemq/browse/AMQ-1771
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 5.1.0
Environment: WinXP, JDK5
Reporter: Andreas Kuhtz
Fix For: 5.2.0
Attachments: amq-failover.patch
The FailoverTransport does currently not signal the initial resume of the transport (due to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know if the connection is successfully connected or not.
The attached patch adds a sleep (copied from the failure processing part some lines below) that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AMQ-1771) Failover transport should always signal
resume of transport
Posted by "Andreas Kuhtz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Kuhtz reopened AMQ-1771:
--------------------------------
There is another timing issue because the reconnect task is triggered via the {{FailoverTransport.add(URI u[])}} method before the connection is configured (see {{ActiveMConnectionFactory.createActiveMQConnection(...)}}) and therefore the transport listener is not set.
The attached patch (amq-failover-reconnect.patch) checks if the transport is started and does not call {{reconnect()}} because the {{start()}} will do it later after the connection is configured.
> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>
> Key: AMQ-1771
> URL: https://issues.apache.org/activemq/browse/AMQ-1771
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.1.0
> Environment: WinXP, JDK5
> Reporter: Andreas Kuhtz
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: amq-failover-reconnect.patch, amq-failover.patch
>
>
> The FailoverTransport does currently not signal the initial resume of the transport (due to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know if the connection is successfully connected or not.
> The attached patch adds a sleep (copied from the failure processing part some lines below) that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (AMQ-1771) Failover transport should
always signal resume of transport
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43267#action_43267 ]
rajdavies edited comment on AMQ-1771 at 6/5/08 11:12 AM:
----------------------------------------------------------
Fixed by SVN revision 663680 and 663691
was (Author: rajdavies):
Fixed by SVN revision 663680
> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>
> Key: AMQ-1771
> URL: https://issues.apache.org/activemq/browse/AMQ-1771
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.1.0
> Environment: WinXP, JDK5
> Reporter: Andreas Kuhtz
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: amq-failover.patch
>
>
> The FailoverTransport does currently not signal the initial resume of the transport (due to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know if the connection is successfully connected or not.
> The attached patch adds a sleep (copied from the failure processing part some lines below) that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AMQ-1771) Failover transport should always signal
resume of transport
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-1771:
-------------------------------
Assignee: Rob Davies
> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>
> Key: AMQ-1771
> URL: https://issues.apache.org/activemq/browse/AMQ-1771
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.1.0
> Environment: WinXP, JDK5
> Reporter: Andreas Kuhtz
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: amq-failover.patch
>
>
> The FailoverTransport does currently not signal the initial resume of the transport (due to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know if the connection is successfully connected or not.
> The attached patch adds a sleep (copied from the failure processing part some lines below) that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-1771) Failover transport should always signal
resume of transport
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1771.
-----------------------------
Resolution: Fixed
Fixed by revision 666893
> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>
> Key: AMQ-1771
> URL: https://issues.apache.org/activemq/browse/AMQ-1771
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.1.0
> Environment: WinXP, JDK5
> Reporter: Andreas Kuhtz
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: amq-failover-reconnect.patch, amq-failover.patch
>
>
> The FailoverTransport does currently not signal the initial resume of the transport (due to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know if the connection is successfully connected or not.
> The attached patch adds a sleep (copied from the failure processing part some lines below) that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-1771) Failover transport should always signal
resume of transport
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1771.
-----------------------------
Resolution: Fixed
Fixed by SVN revision 663680
> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>
> Key: AMQ-1771
> URL: https://issues.apache.org/activemq/browse/AMQ-1771
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.1.0
> Environment: WinXP, JDK5
> Reporter: Andreas Kuhtz
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: amq-failover.patch
>
>
> The FailoverTransport does currently not signal the initial resume of the transport (due to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know if the connection is successfully connected or not.
> The attached patch adds a sleep (copied from the failure processing part some lines below) that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-1771) Failover transport should always
signal resume of transport
Posted by "Jan Bartel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43612#action_43612 ]
Jan Bartel commented on AMQ-1771:
---------------------------------
Hi Rob,
A jetty hightide user has posted me the following problem description, which I think may be fixed by the patches above, but I'm not entirely sure - could you confirm for me if that's the case?
Here's the problem as it was reported:
"ActiveMQConnection
—————————
The Main thread is stuck waiting for ActiveMQConnection.brokerInfoReceived CountDownLatch in the ActiveMQConnection.waitForBrokerInfo() method. The brokerInfoReceived latch is released when the ActiveMQConnection.onCommand().processBrokerInfo() Listner event is received.
FailoverTransport
————————-
When the FailoverTransport is instantiated it immediately attempts to connect to the brokers. On successful connection to the broker it calls the Listener, if one is attached.
The processBrokerInfo command from the broker is sent to the listener, in this case the ActiveMQConnection which releases the latch.
The sequence of wiring the connection to the transport is as follows...
- ActiveMQConnectionFactory.createActiveMQConnection() creates the transport, then creates the ActiveMQConnection(transport)
- The ActiveMQConnection constructor calls transport.setTransportListener(this) which attaches the connection listener to the transport
- Finally the factory calls start() on the transport
The problem is the FailoverTransport starts to connect doReconnect() at construction time using its own thread. On successful connection to the broker it notifies using the listener but only if the listener is set. The race condition occurs on the main thread to attach the listener to the FailoverTransport before the FailoverTransport connects. If the FailoverTransport connects and the listener is not connected, notification messages are lost.."
ta muchly,
Jan
> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>
> Key: AMQ-1771
> URL: https://issues.apache.org/activemq/browse/AMQ-1771
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.1.0
> Environment: WinXP, JDK5
> Reporter: Andreas Kuhtz
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: amq-failover-reconnect.patch, amq-failover.patch
>
>
> The FailoverTransport does currently not signal the initial resume of the transport (due to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know if the connection is successfully connected or not.
> The attached patch adds a sleep (copied from the failure processing part some lines below) that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-1771) Failover transport should always signal
resume of transport
Posted by "Andreas Kuhtz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Kuhtz updated AMQ-1771:
-------------------------------
Attachment: amq-failover-reconnect.patch
> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>
> Key: AMQ-1771
> URL: https://issues.apache.org/activemq/browse/AMQ-1771
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.1.0
> Environment: WinXP, JDK5
> Reporter: Andreas Kuhtz
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: amq-failover-reconnect.patch, amq-failover.patch
>
>
> The FailoverTransport does currently not signal the initial resume of the transport (due to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know if the connection is successfully connected or not.
> The attached patch adds a sleep (copied from the failure processing part some lines below) that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.