You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Ron Pressler (JIRA)" <ji...@apache.org> on 2007/09/17 15:10:22 UTC
[jira] Created: (AMQ-1388) Make NetworkConnectors two-sided
Make NetworkConnectors two-sided
--------------------------------
Key: AMQ-1388
URL: https://issues.apache.org/activemq/browse/AMQ-1388
Project: ActiveMQ
Issue Type: Improvement
Reporter: Ron Pressler
Consider the following scenario:
Several machines communicate using topics, using a hub-and-spoke topography, but instead of having all messages go through a central broker, each machine has an embedded vm broker to enable efficient intra-machine communication.
This is a common architecture.
Currently, to support such an architecture, if we want to allow dynamic addition of machines, we need to configure both a network connector on each machine to connect to the central hub, a tcp transport connector on the hub (to allow remote connections), as well as a multicast discovery on the central hub and a tcp connector on each machine to allow the hub to connect back to it.
This is redundant, because the network connector from the vm broker to the central hub should suffice to deliver messages in both directions, thus also making the discovery unnecessary and the connections easier to maintain and monitor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AMQ-1388) Make NetworkConnectors two-sided
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-1388:
-------------------------------
Assignee: Rob Davies
> Make NetworkConnectors two-sided
> --------------------------------
>
> Key: AMQ-1388
> URL: https://issues.apache.org/activemq/browse/AMQ-1388
> Project: ActiveMQ
> Issue Type: Improvement
> Reporter: Ron Pressler
> Assignee: Rob Davies
>
> Consider the following scenario:
> Several machines communicate using topics, using a hub-and-spoke topography, but instead of having all messages go through a central broker, each machine has an embedded vm broker to enable efficient intra-machine communication.
> This is a common architecture.
> Currently, to support such an architecture, if we want to allow dynamic addition of machines, we need to configure both a network connector on each machine to connect to the central hub, a tcp transport connector on the hub (to allow remote connections), as well as a multicast discovery on the central hub and a tcp connector on each machine to allow the hub to connect back to it.
> This is redundant, because the network connector from the vm broker to the central hub should suffice to deliver messages in both directions, thus also making the discovery unnecessary and the connections easier to maintain and monitor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-1388) Make NetworkConnectors two-sided
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1388.
-----------------------------
Resolution: Duplicate
This is a duplicate of https://issues.apache.org/activemq/browse/AMQ-920
And is now fixed in 5.0 - set the duplex property on the network connector to true - see:
http://activemq.apache.org/networks-of-brokers.html
> Make NetworkConnectors two-sided
> --------------------------------
>
> Key: AMQ-1388
> URL: https://issues.apache.org/activemq/browse/AMQ-1388
> Project: ActiveMQ
> Issue Type: Improvement
> Reporter: Ron Pressler
> Assignee: Rob Davies
>
> Consider the following scenario:
> Several machines communicate using topics, using a hub-and-spoke topography, but instead of having all messages go through a central broker, each machine has an embedded vm broker to enable efficient intra-machine communication.
> This is a common architecture.
> Currently, to support such an architecture, if we want to allow dynamic addition of machines, we need to configure both a network connector on each machine to connect to the central hub, a tcp transport connector on the hub (to allow remote connections), as well as a multicast discovery on the central hub and a tcp connector on each machine to allow the hub to connect back to it.
> This is redundant, because the network connector from the vm broker to the central hub should suffice to deliver messages in both directions, thus also making the discovery unnecessary and the connections easier to maintain and monitor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-1388) Make NetworkConnectors two-sided
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies updated AMQ-1388:
----------------------------
Fix Version/s: 5.0.0
> Make NetworkConnectors two-sided
> --------------------------------
>
> Key: AMQ-1388
> URL: https://issues.apache.org/activemq/browse/AMQ-1388
> Project: ActiveMQ
> Issue Type: Improvement
> Reporter: Ron Pressler
> Assignee: Rob Davies
> Fix For: 5.0.0
>
>
> Consider the following scenario:
> Several machines communicate using topics, using a hub-and-spoke topography, but instead of having all messages go through a central broker, each machine has an embedded vm broker to enable efficient intra-machine communication.
> This is a common architecture.
> Currently, to support such an architecture, if we want to allow dynamic addition of machines, we need to configure both a network connector on each machine to connect to the central hub, a tcp transport connector on the hub (to allow remote connections), as well as a multicast discovery on the central hub and a tcp connector on each machine to allow the hub to connect back to it.
> This is redundant, because the network connector from the vm broker to the central hub should suffice to deliver messages in both directions, thus also making the discovery unnecessary and the connections easier to maintain and monitor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.