activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r967645 - in /websites/production/activemq/content: cache/main.pageCache topologies.html version-5-topologies.html
Date Sat, 03 Oct 2015 18:21:43 GMT
Author: buildbot
Date: Sat Oct  3 18:21:43 2015
New Revision: 967645

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/topologies.html
    websites/production/activemq/content/version-5-topologies.html

Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/activemq/content/topologies.html
==============================================================================
--- websites/production/activemq/content/topologies.html (original)
+++ websites/production/activemq/content/topologies.html Sat Oct  3 18:21:43 2015
@@ -81,84 +81,22 @@
   <tbody>
         <tr>
         <td valign="top" width="100%">
-<div class="wiki-content maincontent"><p>ActiveMQ supports a wide range of different
deployment topologies as well as <a shape="rect" href="uri-protocols.html">protocols</a>
&amp; wire formats. The following diagram shows a federated network of brokers with a
few different kinds of topology.</p>
-
-<p><a shape="rect" class="external-link" href="http://activemq.org/BrokerTopology.pdf"
rel="nofollow"><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image"
src="topologies.data/BrokerTopology-1.png"></span></a></p>
-
-<p>Which topology you choose is up to you. We'll now describe a few of these protocols
in a little more detail.</p>
-
-<h2 id="Topologies-InVM">In VM</h2>
-
-<p>A useful option when unit testing is to limit JMS communication to within a single
JVM. For this use the protocol</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-vm://localhost
+<div class="wiki-content maincontent"><p>ActiveMQ supports a wide range of different
deployment topologies as well as <a shape="rect" href="uri-protocols.html">protocols</a>
&amp; wire formats. The following diagram shows a federated network of brokers with a
few different kinds of topology.</p><p><a shape="rect" class="external-link"
href="http://activemq.org/BrokerTopology.pdf" rel="nofollow"><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image" src="topologies.data/BrokerTopology-1.png"></span></a></p><p>Which
topology you choose is up to you. We'll now describe a few of these protocols in a little
more detail.</p><h2 id="Topologies-InVM">In VM</h2><p>A useful option
when unit testing is to limit JMS communication to within a single JVM. For this use the protocol</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">vm://localhost
 </pre>
-</div></div>
-<p>You can segment the VM protocol to different groups - e.g. if you want to have logically
different JMS networks within the same JVM, you can group networks using different URIs. e.g.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-vm://localhost/foo
+</div></div><p>You can segment the VM protocol to different groups - e.g.
if you want to have logically different JMS networks within the same JVM, you can group networks
using different URIs. e.g.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">vm://localhost/foo
 </pre>
-</div></div>
-<p>This will ensure that different segments do not interfere with one another. Though
typically we use unique topic and queue destinations so that all traffic can coexist happily
on the same logical network.</p>
-
-<h2 id="Topologies-Client-Server">Client-Server</h2>
-
-<p>This is probably the most efficient and fastest solution for large numbers of clients
requiring a diverse range of communication options from publish / subscribe to queue based
communication. Typically the clients will connect with a Message Broker using a protocol,
typically TCP or SSL but this could be NIO or other protocols.</p>
-
-<p>We can load balance clients across brokers and provide broker failover so that we
have a logical cluster of brokers with <a shape="rect" href="ha.html">HA</a>.</p>
-
-<p>e.g.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-tcp://somehost:port
+</div></div><p>This will ensure that different segments do not interfere
with one another. Though typically we use unique topic and queue destinations so that all
traffic can coexist happily on the same logical network.</p><h2 id="Topologies-Client-Server">Client-Server</h2><p>This
is probably the most efficient and fastest solution for large numbers of clients requiring
a diverse range of communication options from publish / subscribe to queue based communication.
Typically the clients will connect with a Message Broker using a protocol, typically TCP or
SSL but this could be NIO or other protocols.</p><p>We can load balance clients
across brokers and provide broker failover so that we have a logical cluster of brokers with
<a shape="rect" href="ha.html">HA</a>.</p><p>e.g.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">tcp://somehost:port
 </pre>
-</div></div>
-<p>Or for SSL</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-ssl://somehost:port
+</div></div><p>Or for SSL</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">ssl://somehost:port
 </pre>
-</div></div>
-<p>You can use <a shape="rect" href="discovery.html">Discovery</a> to find
the brokers available that you can connect to which makes it easier to seamlessly connect
to a cluster of brokers.</p>
-
-<h2 id="Topologies-EmbeddedBroker">Embedded Broker</h2>
-
-<p>This is logically equivalent to Client-Server but some (or all) clients contain
a locally embedded broker. So communcation between the client and server (broker) are all
within the same JVM and so do not use real networking - though brokers may communicate with
other brokers or clients connected to it.</p>
-
-<p>This can avoid the extra hop required to go from producer to broker to consumer
- which is a great optimisation for RMI / RPC style situations, where you want the performance
benefits (reduced latency) of point to point networking but with the scalabilty of a flexible
messaging fabric.</p>
-
-<p>Embedded Brokers can also simplify deployment options as well, its one less process
to run.</p>
-
-<p>Another use case for embedded brokers is to provide store and forward isolation
from each service - so that the remote brokers can fail quite happily without affecting the
service with the embedded broker. e.g. the entire network could fail, but a service could
continue publishing messages to its embedded broker.</p>
-
-<p>You can find out how to <a shape="rect" href="how-do-i-embed-a-broker-inside-a-connection.html">configure
an embedded broker here</a></p>
-
-<h2 id="Topologies-PeertoPeer">Peer to Peer</h2>
-
-<p>This allows peer based clusters to be created where there is no server - just clients
connecting together.<br clear="none">
-There are various ways to implement a peer to peer JMS network. One easy way is just to use
a multicast transport for communication; then all nodes on the same multicast address will
receive all messages and the local embedded message broker will route messages to the necessary
MessageConsumers.</p>
-
-<p>We currently have 3 choices for multicast protocols</p>
-<ul><li>multicast</li><li>jgroups: uses the JGroups library to implement
reliable multicast</li><li>jrms: uses Sun's JRMS library to implement reliable
multicast</li></ul>
-
-
-<p>Multicast is great in development though often you might want to disable this feature
in production and have well known servers fixed on specific machines. Often socket based communication
(using pointcast) is much faster &amp; better for heavy-lifting - particularly on Java
- so we tend to recommend to use multicast mostly for discovery and use TCP / SSL for your
heavy duty messaging.</p>
-
-<p>Often we can use the peer to peer topology as a bootstrap to create a cluster of
clients &amp; brokers and then autodeploy servers into the cluster for a true grid style
network.</p>
-
-<p>So you can get the effect of a peer based network using <a shape="rect" href="discovery.html">Discovery</a>
together with either stand alone Brokers or using embedded brokers.</p>
-
-<h3 id="Topologies-JXTA">JXTA</h3>
-
-<p>We have a JXTA transport which will use the full JXTA stack for negotiating NAT
and across firewalls and so forth for creating a true peer based JMS network.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-jxta://hostname:port
+</div></div><p>You can use <a shape="rect" href="discovery.html">Discovery</a>
to find the brokers available that you can connect to which makes it easier to seamlessly
connect to a cluster of brokers.</p><h2 id="Topologies-EmbeddedBroker">Embedded
Broker</h2><p>This is logically equivalent to Client-Server but some (or all)
clients contain a locally embedded broker. So communcation between the client and server (broker)
are all within the same JVM and so do not use real networking - though brokers may communicate
with other brokers or clients connected to it.</p><p>This can avoid the extra
hop required to go from producer to broker to consumer - which is a great optimisation for
RMI / RPC style situations, where you want the performance benefits (reduced latency) of point
to point networking but with the scalabilty of a flexible messaging fabric.</p><p>Embedded
Brokers can also simplify deployment options as well, its one less process to run.</p><p>Another
use case for embedded bro
 kers is to provide store and forward isolation from each service - so that the remote brokers
can fail quite happily without affecting the service with the embedded broker. e.g. the entire
network could fail, but a service could continue publishing messages to its embedded broker.</p><p>You
can find out how to <a shape="rect" href="how-do-i-embed-a-broker-inside-a-connection.html">configure
an embedded broker here</a></p><h2 id="Topologies-PeertoPeer">Peer to Peer</h2><p>This
allows peer based clusters to be created where there is no server - just clients connecting
together.<br clear="none"> There are various ways to implement a peer to peer JMS network.
One easy way is just to use a multicast transport for communication; then all nodes on the
same multicast address will receive all messages and the local embedded message broker will
route messages to the necessary MessageConsumers.</p><p>We currently have 3 choices
for multicast protocols</p><ul><li>multicast</li><li>jgroups:
uses
  the JGroups library to implement reliable multicast</li><li>jrms: uses Sun's
JRMS library to implement reliable multicast</li></ul><p>Multicast is great
in development though often you might want to disable this feature in production and have
well known servers fixed on specific machines. Often socket based communication (using pointcast)
is much faster &amp; better for heavy-lifting - particularly on Java - so we tend to recommend
to use multicast mostly for discovery and use TCP / SSL for your heavy duty messaging.</p><p>Often
we can use the peer to peer topology as a bootstrap to create a cluster of clients &amp;
brokers and then autodeploy servers into the cluster for a true grid style network.</p><p>So
you can get the effect of a peer based network using <a shape="rect" href="discovery.html">Discovery</a>
together with either stand alone Brokers or using embedded brokers.</p><h3 id="Topologies-JXTA">JXTA</h3><p>We
have a JXTA transport which will use the full JXTA stack for ne
 gotiating NAT and across firewalls and so forth for creating a true peer based JMS network.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">jxta://hostname:port
 </pre>
-</div></div>
-<p>Currently you need to run one server which everyone connects to via JXTA. We've
not yet created a pure peer network with JXTA</p></div>
+</div></div><p>Currently you need to run one server which everyone connects
to via JXTA. We've not yet created a pure peer network with JXTA</p></div>
         </td>
         <td valign="top">
           <div class="navigation">

Modified: websites/production/activemq/content/version-5-topologies.html
==============================================================================
--- websites/production/activemq/content/version-5-topologies.html (original)
+++ websites/production/activemq/content/version-5-topologies.html Sat Oct  3 18:21:43 2015
@@ -82,84 +82,22 @@
   <tbody>
         <tr>
         <td valign="top" width="100%">
-<div class="wiki-content maincontent"><p>ActiveMQ supports a wide range of different
deployment topologies as well as <a shape="rect" href="uri-protocols.html">protocols</a>
&amp; wire formats. The following diagram shows a federated network of brokers with a
few different kinds of topology.
-
-</p><p><a shape="rect" class="external-link" href="http://activemq.org/BrokerTopology.pdf"
rel="nofollow"><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image"
src="version-5-topologies.data/BrokerTopology-1.png"></span></a></p>
-
-<p>Which topology you choose is up to you. We'll now describe a few of these protocols
in a little more detail.</p>
-
-<h2 id="Version5Topologies-InVM">In VM</h2>
-
-<p>A useful option when unit testing is to limit JMS communication to within a single
JVM. For this use the protocol</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-vm://localhost
+<div class="wiki-content maincontent"><p>ActiveMQ supports a wide range of different
deployment topologies as well as <a shape="rect" href="uri-protocols.html">protocols</a>
&amp; wire formats. The following diagram shows a federated network of brokers with a
few different kinds of topology.</p><p><a shape="rect" class="external-link"
href="http://activemq.org/BrokerTopology.pdf" rel="nofollow"><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image" src="version-5-topologies.data/BrokerTopology-1.png"></span></a></p><p>Which
topology you choose is up to you. We'll now describe a few of these protocols in a little
more detail.</p><h2 id="Version5Topologies-InVM">In VM</h2><p>A useful
option when unit testing is to limit JMS communication to within a single JVM. For this use
the protocol</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">vm://localhost
 </pre>
-</div></div>
-<p>You can segment the VM protocol to different groups - e.g. if you want to have logically
different JMS networks within the same JVM, you can group networks using different URIs. e.g.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-vm://localhost/foo
+</div></div><p>You can segment the VM protocol to different groups - e.g.
if you want to have logically different JMS networks within the same JVM, you can group networks
using different URIs. e.g.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">vm://localhost/foo
 </pre>
-</div></div>
-<p>This will ensure that different segments do not interfere with one another. Though
typically we use unique topic and queue destinations so that all traffic can coexist happily
on the same logical network.</p>
-
-<h2 id="Version5Topologies-Client-Server">Client-Server</h2>
-
-<p>This is probably the most efficient and fastest solution for large numbers of clients
requiring a diverse range of communication options from publish / subscribe to queue based
communication. Typically the clients will connect with a Message Broker using a protocol,
typically TCP or SSL but this could be NIO or other protocols.</p>
-
-<p>We can load balance clients across brokers and provide broker failover so that we
have a logical cluster of brokers with <a shape="rect" href="ha.html">HA</a>.</p>
-
-<p>e.g.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-tcp://somehost:port
+</div></div><p>This will ensure that different segments do not interfere
with one another. Though typically we use unique topic and queue destinations so that all
traffic can coexist happily on the same logical network.</p><h2 id="Version5Topologies-Client-Server">Client-Server</h2><p>This
is probably the most efficient and fastest solution for large numbers of clients requiring
a diverse range of communication options from publish / subscribe to queue based communication.
Typically the clients will connect with a Message Broker using a protocol, typically TCP or
SSL but this could be NIO or other protocols.</p><p>We can load balance clients
across brokers and provide broker failover so that we have a logical cluster of brokers with
<a shape="rect" href="ha.html">HA</a>.</p><p>e.g.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">tcp://somehost:port
 </pre>
-</div></div>
-<p>Or for SSL</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-ssl://somehost:port
+</div></div><p>Or for SSL</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">ssl://somehost:port
 </pre>
-</div></div>
-<p>You can use <a shape="rect" href="discovery.html">Discovery</a> to find
the brokers available that you can connect to which makes it easier to seamlessly connect
to a cluster of brokers.</p>
-
-<h2 id="Version5Topologies-EmbeddedBroker">Embedded Broker</h2>
-
-<p>This is logically equivalent to Client-Server but some (or all) clients contain
a locally embedded broker. So communcation between the client and server (broker) are all
within the same JVM and so do not use real networking - though brokers may communicate with
other brokers or clients connected to it.</p>
-
-<p>This can avoid the extra hop required to go from producer to broker to consumer
- which is a great optimisation for RMI / RPC style situations, where you want the performance
benefits (reduced latency) of point to point networking but with the scalabilty of a flexible
messaging fabric.</p>
-
-<p>Embedded Brokers can also simplify deployment options as well, its one less process
to run.</p>
-
-<p>Another use case for embedded brokers is to provide store and forward isolation
from each service - so that the remote brokers can fail quite happily without affecting the
service with the embedded broker. e.g. the entire network could fail, but a service could
continue publishing messages to its embedded broker.</p>
-
-<p>You can find out how to <a shape="rect" href="how-do-i-embed-a-broker-inside-a-connection.html">configure
an embedded broker here</a></p>
-
-<h2 id="Version5Topologies-PeertoPeer">Peer to Peer</h2>
-
-<p>This allows peer based clusters to be created where there is no server - just clients
connecting together.<br clear="none">
-There are various ways to implement a peer to peer JMS network. One easy way is just to use
a multicast transport for communication; then all nodes on the same multicast address will
receive all messages and the local embedded message broker will route messages to the necessary
MessageConsumers.</p>
-
-<p>We currently have 3 choices for multicast protocols</p>
-<ul><li>multicast</li><li>jgroups: uses the JGroups library to implement
reliable multicast</li><li>jrms: uses Sun's JRMS library to implement reliable
multicast</li></ul>
-
-
-<p>Multicast is great in development though often you might want to disable this feature
in production and have well known servers fixed on specific machines. Often socket based communication
(using pointcast) is much faster &amp; better for heavy-lifting - particularly on Java
- so we tend to recommend to use multicast mostly for discovery and use TCP / SSL for your
heavy duty messaging.</p>
-
-<p>Often we can use the peer to peer topology as a bootstrap to create a cluster of
clients &amp; brokers and then autodeploy servers into the cluster for a true grid style
network.</p>
-
-<p>So you can get the effect of a peer based network using <a shape="rect" href="discovery.html">Discovery</a>
together with either stand alone Brokers or using embedded brokers.</p>
-
-<h3 id="Version5Topologies-JXTA">JXTA</h3>
-
-<p>We have a JXTA transport which will use the full JXTA stack for negotiating NAT
and across firewalls and so forth for creating a true peer based JMS network.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
-<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">
-jxta://hostname:port
+</div></div><p>You can use <a shape="rect" href="discovery.html">Discovery</a>
to find the brokers available that you can connect to which makes it easier to seamlessly
connect to a cluster of brokers.</p><h2 id="Version5Topologies-EmbeddedBroker">Embedded
Broker</h2><p>This is logically equivalent to Client-Server but some (or all)
clients contain a locally embedded broker. So communcation between the client and server (broker)
are all within the same JVM and so do not use real networking - though brokers may communicate
with other brokers or clients connected to it.</p><p>This can avoid the extra
hop required to go from producer to broker to consumer - which is a great optimisation for
RMI / RPC style situations, where you want the performance benefits (reduced latency) of point
to point networking but with the scalabilty of a flexible messaging fabric.</p><p>Embedded
Brokers can also simplify deployment options as well, its one less process to run.</p><p>Another
use case for embe
 dded brokers is to provide store and forward isolation from each service - so that the remote
brokers can fail quite happily without affecting the service with the embedded broker. e.g.
the entire network could fail, but a service could continue publishing messages to its embedded
broker.</p><p>You can find out how to <a shape="rect" href="how-do-i-embed-a-broker-inside-a-connection.html">configure
an embedded broker here</a></p><h2 id="Version5Topologies-PeertoPeer">Peer
to Peer</h2><p>This allows peer based clusters to be created where there is no
server - just clients connecting together.<br clear="none"> There are various ways to
implement a peer to peer JMS network. One easy way is just to use a multicast transport for
communication; then all nodes on the same multicast address will receive all messages and
the local embedded message broker will route messages to the necessary MessageConsumers.</p><p>We
currently have 3 choices for multicast protocols</p><ul><li>multicast</li><
 li>jgroups: uses the JGroups library to implement reliable multicast</li><li>jrms:
uses Sun's JRMS library to implement reliable multicast</li></ul><p>Multicast
is great in development though often you might want to disable this feature in production
and have well known servers fixed on specific machines. Often socket based communication (using
pointcast) is much faster &amp; better for heavy-lifting - particularly on Java - so we
tend to recommend to use multicast mostly for discovery and use TCP / SSL for your heavy duty
messaging.</p><p>Often we can use the peer to peer topology as a bootstrap to
create a cluster of clients &amp; brokers and then autodeploy servers into the cluster
for a true grid style network.</p><p>So you can get the effect of a peer based
network using <a shape="rect" href="discovery.html">Discovery</a> together with
either stand alone Brokers or using embedded brokers.</p><h3 id="Version5Topologies-JXTA">JXTA</h3><p>We
have a JXTA transport which will use th
 e full JXTA stack for negotiating NAT and across firewalls and so forth for creating a true
peer based JMS network.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">jxta://hostname:port
 </pre>
-</div></div>
-<p>Currently you need to run one server which everyone connects to via JXTA. We've
not yet created a pure peer network with JXTA</p></div>
+</div></div><p>Currently you need to run one server which everyone connects
to via JXTA. We've not yet created a pure peer network with JXTA</p></div>
         </td>
         <td valign="top">
           <div class="navigation">



Mime
View raw message