qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ai...@apache.org
Subject svn commit: r650447 [2/17] - in /incubator/qpid/branches/forrest-site: ./ classes/ conf/ content/ content/xdocs/ content/xdocs/3rd Party Libraries_attachments/ content/xdocs/Acknowledgment_attachments/ content/xdocs/Developer Pages_attachments/ content...
Date Tue, 22 Apr 2008 11:59:37 GMT
Added: incubator/qpid/branches/forrest-site/content/xdocs/BindingURLFormat.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/BindingURLFormat.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/BindingURLFormat.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/BindingURLFormat.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,100 @@
+<html>
+    <head>
+        <title>Apache Qpid : BindingURLFormat</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : BindingURLFormat
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Feb 18, 2008 by <font color="#0050B2">aidan</font>.
+				    </div>
+
+				    <div class="preformatted"><div class="preformattedContent">
+<pre>&lt;Exchange Class&gt;://&lt;Exchange Name&gt;/[&lt;Destination&gt;]/[&lt;Queue&gt;][?&lt;option&gt;='&lt;value&gt;'[&amp;&lt;option&gt;='&lt;value&gt;']]
+</pre>
+</div></div>
+
+<p>This URL format is used for two purposes in the code base. The broker uses this in the XML configuration file to create and bind queues at broker startup. It is also used by the client as a destination.</p>
+
+<p>This format was used because it allows an explicit description of exchange and queue relationship.</p>
+
+<p>The Exchange Class is not normally required for client connection as clients only publish to a named exchange however if exchanges are being dynamically instantiated it will be required. The class is required for the server to instantiate an exchange.</p>
+
+<p>There are a number of options that are currently defined:</p>
+<table class='confluenceTable'><tbody>
+<tr>
+<th class='confluenceTh'>Option</th>
+<th class='confluenceTh'>type</th>
+<th class='confluenceTh'>Description</th>
+</tr>
+<tr>
+<td class='confluenceTd'>exclusive</td>
+<td class='confluenceTd'> boolean</td>
+<td class='confluenceTd'>Is this an exclusive connection</td>
+</tr>
+<tr>
+<td class='confluenceTd'>autodelete</td>
+<td class='confluenceTd'> boolean</td>
+<td class='confluenceTd'>Should this queue be deleted on client disconnection</td>
+</tr>
+<tr>
+<td class='confluenceTd'>durable</td>
+<td class='confluenceTd'>boolean</td>
+<td class='confluenceTd'>Create a durable queue</td>
+</tr>
+<tr>
+<td class='confluenceTd'>clientid</td>
+<td class='confluenceTd'>string</td>
+<td class='confluenceTd'>Use the following client id</td>
+</tr>
+<tr>
+<td class='confluenceTd'>subscription</td>
+<td class='confluenceTd'>boolean</td>
+<td class='confluenceTd'>Create a subscription to this destination</td>
+</tr>
+<tr>
+<td class='confluenceTd'>routingkey</td>
+<td class='confluenceTd'>string</td>
+<td class='confluenceTd'>Use this value as the routing key</td>
+</tr>
+</tbody></table>
+
+<p>Using these options in conjunction with the Binding URL format should allow future expansion as new and custom exchange types are created.</p>
+
+<p>The URL format requires <b>that at least one</b> Queue or routingkey option be present on the URL.</p>
+
+<p>The routingkey would be used to encode a topic as shown in the examples section below.</p>
+
+<h4><a name="BindingURLFormat-Examples"></a>Examples </h4>
+<div class="preformatted"><div class="preformattedContent">
+<pre>direct://amq.direct/SimpleQueue
+direct://amq.direct/UnusuallyBoundQueue?routingkey='/queue'
+topic://amq.topic?routingkey='stocks.#'
+topic://amq.topic?routingkey='stocks.nyse.ibm'
+</pre>
+</div></div>
+
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/BindingURLFormat.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/Build .NET Client.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Build%20.NET%20Client.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Build .NET Client.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Build .NET Client.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,58 @@
+<html>
+    <head>
+        <title>Apache Qpid : Build .NET Client</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Build .NET Client
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Aug 02, 2007 by <font color="#0050B2">ritchiem</font>.
+				    </div>
+
+				    <h2><a name="Build.NETClient-BuildingClient"></a>Building Client</h2>
+
+<p>Generate framing from /Qpid.Common/amqp.xml specificiation file:</p>
+
+<p>  $ build-framing</p>
+
+<p>Alternatively, just switch to /Qpid.Common and run "ant" there.</p>
+
+<p>You can build from Visual Studio 2005 normally. Alternatively, you<br/>
+can build debug releases for any supported framework from the <br/>
+command line using Nant:</p>
+
+<p>To build .NET 2.0 executables (to bin/net-2.0):</p>
+
+<p>  $ build-dotnet20</p>
+
+<p>To build .NET 1.1 executables (to bin/net-1.1):</p>
+
+<p>  $ build-dotnet11</p>
+
+<p>To build for Mono on Linux (to bin/mono-2.0):</p>
+
+<p>  $ build-mono</p>
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/Build .NET Client.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/Building.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Building.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Building.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Building.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,99 @@
+<html>
+    <head>
+        <title>Apache Qpid : Building</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Building
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Apr 14, 2008 by <font color="#0050B2">cctrieloff</font>.
+				    </div>
+
+				    <h2><a name="Building-JavaBuildingPages"></a>Java Building Pages</h2>
+
+<p>Developer Information</p>
+
+<ul>
+	<li><a href="Qpid Java Build How To.html" title="Qpid Java Build How To">Build How To</a></li>
+	<li><a href="Qpid Developer Documentation.html" title="Qpid Developer Documentation">Qpid Developer Documentation</a></li>
+	<li><a href="Java Coding Standards.html" title="Java Coding Standards">Coding Standards</a></li>
+	<li><a href="Multiple AMQP Version Support.html" title="Multiple AMQP Version Support">AMQP Version Handling</a></li>
+	<li><a href="URL Formats.html" title="URL Formats">URL format for Connections and Binding</a></li>
+	<li><a href="Java Unit Tests with InVM Broker.html" title="Java Unit Tests with InVM Broker">Creating Java unit tests with InVM broker</a></li>
+</ul>
+
+
+<p>Performance Testing</p>
+
+<ul>
+	<li><a href="Qpid IBM JMS Performance Test Results.html" title="Qpid IBM JMS Performance Test Results">IBM JMS Performance Test Results</a></li>
+</ul>
+
+
+<p>Management Interfaces</p>
+
+<ul>
+	<li><a href="Qpid Management Features.html" title="Qpid Management Features">Management Features</a></li>
+	<li><a href="JMX Management Console.html" title="JMX Management Console">Management Console</a></li>
+</ul>
+
+
+<h2><a name="Building-CBuildingPages"></a>C++ Building Pages</h2>
+
+<p>Developer Information</p>
+
+<ul>
+	<li><a href="Qpid Cpp Build How To.html" title="Qpid Cpp Build How To">Build How To get it going</a></li>
+	<li><a href="PythonBrokerTest.html" title="PythonBrokerTest">The Pyhton test suite</a></li>
+	<li><a href="Qpid 'C++' Documentation.html" title="Qpid 'C++' Documentation">C++ Coding Standard, Design notes etc</a></li>
+</ul>
+
+
+
+<p>Performance Testing</p>
+
+<ul>
+	<li><a href="Performance Testing for C++.html" title="Performance Testing for C++">Performance Testing for C++</a></li>
+</ul>
+
+
+<p>Management Interfaces</p>
+
+<ul>
+	<li><a href="RASC.html" title="RASC">Running &amp; Administration and getting started</a> for the C++ Broker</li>
+	<li><a href="MgmtC++.html" title="MgmtC++">Managing</a> the C++ Broker</li>
+</ul>
+
+
+
+<h2><a name="Building-PythonandRubyobviouslydon%27tneedbuilding."></a>Python and Ruby obviously don't need building.</h2>
+
+<h2><a name="Building-.NETBuildingPages"></a>.NET Building Pages</h2>
+
+<p>.NET can be built under MONO, or on a Windows .NET platform</p>
+
+
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/Building.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/Cluster Design Note.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Cluster%20Design%20Note.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Cluster Design Note.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Cluster Design Note.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,671 @@
+<html>
+    <head>
+        <title>Apache Qpid : Cluster Design Note</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Cluster Design Note
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Apr 20, 2007 by <font color="#0050B2">aconway</font>.
+				    </div>
+
+				    <hr />
+
+<div>
+<ul>
+  <li><a href='#ClusterDesignNote-Overview'>Overview</a>
+<ul>
+  <li><a href='#ClusterDesignNote-Clientsiderequirements'>Client side requirements</a></li>
+  <li><a href='#ClusterDesignNote-Clusterprotocols'>Cluster protocols</a></li>
+  <li><a href='#ClusterDesignNote-Sessions'>Sessions</a></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-TypesofstateWehavetoconsiderseveralkindsofstate%3A'>Types of state We have to consider several kinds of state:</a>
+<ul>
+  <li>
+<ul>
+  <li><a href='#ClusterDesignNote-TheClusterMap%3AMembershipandWiring'>The Cluster Map: Membership and  Wiring</a></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-ProxiesandQueueContent'>Proxies and Queue Content</a>
+<ul>
+  <li><a href='#ClusterDesignNote-FragmentedSharedQueues'>Fragmented Shared Queues</a></li>
+</ul></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-SessionState'>Session State</a>
+<ul>
+  <li><a href='#ClusterDesignNote-Inflightcommands'>In-flight commands</a></li>
+  <li><a href='#ClusterDesignNote-Resumingachannel'>Resuming a channel</a></li>
+  <li><a href='#ClusterDesignNote-Replicatingsessionstate.'>Replicating session state.</a></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-MappingofAMQPcommandstoreplicationmechanisms'>Mapping of AMQP commands  to replication mechanisms</a>
+<ul>
+  <li><a href='#ClusterDesignNote-queue.declare%2Fbind%2Fdelete%2Cexchange.declare%2Fdelete'>queue.declare/bind/delete, exchange.declare/delete</a></li>
+  <li><a href='#ClusterDesignNote-message.transfer%2Fbasic.publish%28clienttobroker%29'>message.transfer/basic.publish (client to broker)</a></li>
+  <li><a href='#ClusterDesignNote-message.transfer%28brokertoclient%29%2Cmessage.deliver'>message.transfer(broker to client), message.deliver</a></li>
+  <li><a href='#ClusterDesignNote-message.consume%2Fbasic.consume'>message.consume/basic.consume</a></li>
+  <li><a href='#ClusterDesignNote-basic.ack%2Fmessage.ok%28fromclient%29'>basic.ack/message.ok(from client)</a></li>
+  <li><a href='#ClusterDesignNote-basic.ack%2Fmessage.ok%28frombroker%29'>basic.ack/message.ok(from broker)</a></li>
+  <li><a href='#ClusterDesignNote-basic.reject%2Fmessage.reject'>basic.reject / message.reject</a></li>
+  <li><a href='#ClusterDesignNote-reference.open%2Fapppend%2Fclose%28clienttobroker%29'>reference.open/apppend/close (client to broker)</a></li>
+  <li><a href='#ClusterDesignNote-reference.open%2Fapppend%2Fclose%28brokertoclient%29'>reference.open/apppend/close (broker to client) **</a></li>
+  <li><a href='#ClusterDesignNote-Allcommands'>All commands</a></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-ClientBrokerProtocol'>Client-Broker Protocol</a></li>
+  <li><a href='#ClusterDesignNote-BrokerBrokerProtocol'>Broker-Broker Protocol</a></li>
+  <li><a href='#ClusterDesignNote-PersistenceandRecovery'>Persistence and Recovery</a>
+<ul>
+  <li><a href='#ClusterDesignNote-Competingfailuremodes%3A'>Competing failure modes:</a></li>
+  <li><a href='#ClusterDesignNote-Persistenceoverview'>Persistence overview</a></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-Journals'>Journals</a>
+<ul>
+  <li><a href='#ClusterDesignNote-Overview'>Overview</a></li>
+  <li><a href='#ClusterDesignNote-Useofjournals'>Use of journals</a></li>
+  <li><a href='#ClusterDesignNote-Whataboutdisklessreliability%3F'>What about diskless reliability?</a></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-Virtualsynchrony'>Virtual synchrony</a></li>
+  <li><a href='#ClusterDesignNote-Configuration'>Configuration</a>
+<ul>
+  <li><a href='#ClusterDesignNote-SimplifyingpatternsPossiblewaystoconfigureacluster%3A'>Simplifying patterns Possible ways to configure a cluster:</a></li>
+  <li><a href='#ClusterDesignNote-Dynamicclusterconfiguration'>Dynamic cluster configuration</a></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-Transactions'>Transactions</a>
+<ul>
+  <li><a href='#ClusterDesignNote-Localtransactions'>Local transactions</a></li>
+  <li><a href='#ClusterDesignNote-DistributedTransactions'>Distributed Transactions</a></li>
+</ul></li>
+  <li><a href='#ClusterDesignNote-OpenQuestions'>Open Questions</a></li>
+</ul></div>
+
+<hr />
+
+
+<h1><a name="ClusterDesignNote-Overview"></a>Overview</h1>
+
+<p>A Qpid <em>cluster</em> is a "virtual AMQP broker" distributed over multiple processes on multiple hosts. The cluster can continues to provide service in the event of failures of its members.</p>
+
+<p>Reliability guarantees depend on configuration, there may be configurable trade-offs between reliability and performance or hardware requirements.</p>
+
+<p>Clustering is <em>transparent</em> to clients. Cluster clients are standard AMQP clients and use the cluster via the AMQP protocol like a standard broker. If a client is disconnected unexpectedly it can fail-over transparently to another member.</p>
+
+<p>We want to address two major scenarios:</p>
+<ul>
+	<li>Cluster backed by high-performance SAN storage.</li>
+	<li>Cluster with only unshared local storage on each node.</li>
+</ul>
+
+
+<h2><a name="ClusterDesignNote-Clientsiderequirements"></a>Client side requirements</h2>
+
+<p><em>Transparent failover</em>: the <em>failover manager</em> component of the Qpid client libraries provides a <em>virtual AMQP connection</em>. Client applications send and receive AMQP commands as if conducting an uninterrupted conversation with a single broker.</p>
+
+<p>In reality the virtual connection may be a series of real network connections to different cluster members. The failover manager negotiates re-connection and state synchronization, but failover commands <em>do not appear</em> on the virtual connection.</p>
+
+<p>Imagine an AMQP conversation as a paper tape. The real conversation may be multiple strips of torn tape. Near the tears are failover commands that the client never sees. The failover manager cuts off the ragged edges and glues pieces together into a single tape that looks like an uninterrupted conversation with a single broker.</p>
+
+<p>The failover manager must present a virtual conversation consistent with the failed conversations that <em>could have happened</em> with a single broker. It does not have to exactly duplicate the timing or ordering of the real conversations.</p>
+
+
+<h2><a name="ClusterDesignNote-Clusterprotocols"></a>Cluster protocols</h2>
+
+<p>We will use two types of protocol to synchronize the cluster:</p>
+<ul>
+	<li>Virtual synchrony: Open AIS, CPG etc.</li>
+	<li>Point-to-point: AMQP (with proprietary extensions) over TCP.</li>
+</ul>
+
+
+<p>We will use two persistence approaches:</p>
+<ul>
+	<li>GFS shared storage.</li>
+	<li>Local unshared disk storage on a node.</li>
+</ul>
+
+
+<p>The first cluster implementation will be entirely virtual synchrony and GFS: the SAN scenario.</p>
+
+<p>Next iteration will support the local store only scenario but still replicate via EVS.</p>
+
+<p>Subsequent optimization iterations will use primary-backup replication and proxies to increase througput by reducing multicast packets appearing on all switch ports. Cluster membership and exchange wiring will remain on EVS.</p>
+
+<p>At all stages of development there will be concrete performance tests and measurements to ensure we are really optimizing.</p>
+
+<p>Initially we will use AMQP 0-9 WIP protocol using field tables and message headers to pass additional cluster info. At some point we will migrate to 0-10 which is expected to have all the features needed for clustering.</p>
+
+
+<h2><a name="ClusterDesignNote-Sessions"></a>Sessions</h2>
+
+<p>A <em>session</em> identifies a client-broker relationship that can outlive a single connection. It will be formalized in AMQPO 0-10.</p>
+
+<p><em>Orderly closure</em> of a connection by either peer ends the session.  On Unexpected disconnect the session remains viable for some timeout period allowing the client can reconnect to the cluster and resume.</p>
+
+<p>Events in the AMQP.0-8 spec that are triggered by closing a connection (e.g. deleting auto-delete queues) are instead trigged by the closure (or timeout) of a session.</p>
+
+
+
+<h1><a name="ClusterDesignNote-TypesofstateWehavetoconsiderseveralkindsofstate%3A"></a>Types of state We have to consider several kinds of state:</h1>
+
+<ul>
+	<li><em>Cluster Membership</em>: Active cluster members (nodes) and data about them.</li>
+	<li><em>AMQP Wiring</em>: Names and properties of queues, exchanges and bindings.</li>
+	<li><em>AMQP Content</em>: Data in messages on queues.</li>
+	<li><em>Session</em>: Conversation with a single client, including references.</li>
+</ul>
+
+
+<p>Data must be replicated and stored such that:</p>
+<ul>
+	<li>A client knows which node(s) can be used for failover.</li>
+	<li>After a failover, the client can continue its session uninterruped.</li>
+	<li>No acknowledged messages or commands are lost.</li>
+	<li>No messges or commands are applied twice.</li>
+</ul>
+
+
+
+<p>Cluster membership, wiring and session identities are low volume, and will be replicated using virtual synchrony so the entire cluster has a consistent picture.</p>
+
+<p>Queue content is high volume so it is replicated point-to-point using primary-backup to avoid flooding the network.</p>
+
+<p>Session state is potentially high volume and only relevant to a single client, so it is also replicated point-to-point.</p>
+
+<p>How to choose the number and location of backup nodes for a given queue or session is an open question. Note that the choice is independent for every queue and session in principle, but in practice they will probably be grouped in some way.</p>
+
+<h3><a name="ClusterDesignNote-TheClusterMap%3AMembershipandWiring"></a>The Cluster Map: Membership and  Wiring</h3>
+
+<p>Membership, wiring and session changes are low volume. They are replicated to entire cluster symmetrically using EVS.</p>
+
+<p>Wiring inclues</p>
+<ul>
+	<li>exchange names and properties</li>
+	<li>queue names, properties and bindings.</li>
+</ul>
+
+
+<p>Membership data includes:</p>
+<ul>
+	<li>address of each node</li>
+	<li>state of health of each node</li>
+	<li>primary/backup for each queue/exchange</li>
+	<li>session names, primary/backup for each session.</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-ProxiesandQueueContent"></a>Proxies and Queue Content</h2>
+
+<p>For primary-backup replication each queue has a primary and backup node.  Other nodes act as proxies to the primary. The client is unaware of the distinction, it sees an identical picture regardless of what node it connects to.</p>
+
+<p>Note a single cluster member may have a mix of primary, backup and proxy queues.</p>
+
+<p><b>TODO</b>: Ordering issues with proxys and put-back messages (reject, transaction rollback) or selectors.</p>
+
+<h3><a name="ClusterDesignNote-FragmentedSharedQueues"></a>Fragmented Shared Queues</h3>
+
+<p>A shared queue has reduced ordering requirements and increased distribution requirements. <em>Fragmenting</em> a shared queue is a special type of replication. The queue is broken into a set of disjoint sub-queues each on a separate node to distribute load.</p>
+
+<p>Each fragment (sub-queue) content is replicated to backups just like a normal queue, independently of the other fragments.</p>
+
+<p>The fragments collaberate to create the appearance of a single queue. Fragments store incomging messges in the local queue, and serve local consumers from the local queue whenever possible. When a fragment does not have messages to satisfy its consumers it consumes messages from other fragments in the group. Proxies to a fragmented queue will consume from the "nearest" fragment if possible.</p>
+
+<p><b>TODO</b>: Proxies can play a more active role. Ordering guarantees, we can provide "same producer to same consumer preserves order" since messages from the same producer always go on the same fragment queue. May break down in the presence of failover unless we remember which fragment received messges from the client and proxy to the same one on the failover replica.</p>
+
+
+
+
+<h1><a name="ClusterDesignNote-SessionState"></a>Session State</h1>
+
+<p>Session state includes:</p>
+<ul>
+	<li>open channels, channel attributes (qos, transactions etc.).</li>
+	<li>active consumers.</li>
+	<li>open references.</li>
+	<li>completed command history.</li>
+	<li>commands in flight.</li>
+	<li>open transactions</li>
+	<li>exclusive/private queues.</li>
+</ul>
+
+
+<p>The broker a client is connected to is the session primary, one or more other brokers are session backup. On failure of the primary the client fails-over to a backup as described below.</p>
+
+<p>The client can also fail over to a non-backup node which retrieves session state from the backup.</p>
+
+<p>The primary-backup protocol must guarantee that the backup has sufficient data to resume at all times without becoming a synchronous bottleneck.</p>
+
+<h2><a name="ClusterDesignNote-Inflightcommands"></a>In-flight commands</h2>
+
+<p>Both peers must store sent commands for possible resend and received commands to detect possible duplicates in a failover.</p>
+
+<p>To keep session size finite a peer can:</p>
+<ul>
+	<li>forget sent commands when we know the other peer has received them.</li>
+	<li>forget received commands when we know the other peer will not resend them.</li>
+</ul>
+
+
+<p>An algorithm to achieve this:</p>
+
+<p>self_received(r): <blockquote><p>if r.is_response: peer_received(sentr.responds\_to\_id) for s in sent0..r.process\_mark: peer_received(s)</p></blockquote></p>
+
+<p>peer_received(s): <blockquote><p>sent.erase(s)			# forget s but also... # Peer will never resend commands &lt;= s.process_mark. for r in received0..s.process\_mark received.erase(r)</p></blockquote></p>
+
+<p>The weakest rules for interop between peers A and B are:</p>
+
+<ul>
+	<li>A MAY forget a sent command when A knows B received it.</li>
+	<li>A MUST NOT re-send a command after <em>B could know that</em> A knows B received it.</li>
+	<li>A MUST remember received commands till A knows that B knows A received it.</li>
+</ul>
+
+
+<p>Or in protocol terms:</p>
+
+<ul>
+	<li>A MAY forget sent command N when it receives a response to N.</li>
+	<li>A MUST NOT resend N after sending a response to a response to N.</li>
+	<li>A MUST remember received command N until it has both sent M responding to N <em>and</em> received a response to M.</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-Resumingachannel"></a>Resuming a channel</h2>
+
+<p>When a channel is first opened, the broker provides a session-id. If there is a failure, the client can connect to the session backup broker and resume the channel as follows (sync code is just for illustration)</p>
+
+<p><em>TODO does it matter if the new channel number is different from the old?</em></p>
+
+<ol>
+	<li>Client client_resume: <blockquote><p>send(command=channel_resume, command_id=0, session_id=resume_id, process_mark=pre_crash_process_mark) ok = receive(command=channel_ok) self_received(ok) # Clean up to peers process mark. resend() continue_session_as_normal()</p></blockquote></li>
+</ol>
+
+
+<ol>
+	<li>Both sides resend(): <blockquote><ol>
+	<li>Resend in-flight messages. for s in sent: # Careful not to respond to a command we haven't received yet. if s.is_response: until(received.contains(s.resonds_to_id)): self_received(receive()) send(s);   # Original command ids and process_mark</li>
+</ol>
+</blockquote></li>
+</ol>
+
+
+<ol>
+	<li>Broker broker_received_channel_resume(r): <blockquote><p>session=sessionsr.session\_id self_received(r) # Up to date with peers process mark. send(command=channel_ok, command_id=0, process_mark=session.process_mark) resend() continue_session_as_normal()</p></blockquote></li>
+</ol>
+
+
+
+<h2><a name="ClusterDesignNote-Replicatingsessionstate."></a>Replicating session state.</h2>
+
+<p><em>TODO: Need to minimize primary synchronously waiting on backup, while ensuring that the primary always knows that the backup is in a state that satisfies the clients expectations for failover. See recent email thread betwween me &amp; gordon</em></p>
+
+
+
+
+<h1><a name="ClusterDesignNote-MappingofAMQPcommandstoreplicationmechanisms"></a>Mapping of AMQP commands  to replication mechanisms</h1>
+
+<h2><a name="ClusterDesignNote-queue.declare%2Fbind%2Fdelete%2Cexchange.declare%2Fdelete"></a>queue.declare/bind/delete, exchange.declare/delete</h2>
+
+<p>Update cluster map.  Local broker creates the initial queue as primary and establishes a backup.</p>
+
+<p><em>Private queue</em>: backed up on the <em>session backup</em>.</p>
+
+<p><em>Shared queue</em>: local primary queue is the first <em>primary fragment</em>. Other brokers that receive publishes for the queue can proxy to this fragment or create their own local fragment (<em>TODO: How do we decide?</em>) Consumes are always served from the local fragment if possible, otherwise proxied to another fragment <em>(TODO: load balancing algorithms to choose the appropriate fragment)</em></p>
+
+
+<h2><a name="ClusterDesignNote-message.transfer%2Fbasic.publish%28clienttobroker%29"></a>message.transfer/basic.publish (client to broker)</h2>
+
+<p>Local broker evaluates the binding to determine which queue(s) receive the message.</p>
+<ul>
+	<li>primary queues: update local queue, replicate to backup.</li>
+	<li>proxy queues: forward to primary<br/>
+(When the proxy is also a backup we can optimize out the replication step.)</li>
+</ul>
+
+
+<p>If the message is delivered to more than one proxy queue on the same node, we just relay the message once. Brokers must be able to differentiate between normal message transfer and proxy/replication transfer so that when the evaluate the binding they only apply the message to local primary/backup queues respectively, and don't attempt to re-forward messages.</p>
+
+<p><em>TODO: there are a few options</em>:</p>
+<ul>
+	<li>Use custom backup/proxy exchanges and pass an explicit list of queues to receive the message in the header table.</li>
+	<li>Use normal AQMP commands over a marked connectin/channel</li>
+	<li>Introduce new cluster commands.</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-message.transfer%28brokertoclient%29%2Cmessage.deliver"></a>message.transfer(broker to client), message.deliver</h2>
+
+<ul>
+	<li>primary: replicate deliver to backup(s) deliver to client.</li>
+	<li>proxy: pass through to client.</li>
+</ul>
+
+
+<p>Before sending a message to a client, the primary must be sure that the session backup 'knows' about the delivery; i.e. in the event of primary failure the backup knows about unacked messages and will be able to handle an ack or reject for it, resend or requeue it.</p>
+
+<p>If we can define a clear and deterministic algorithm for message dispatch, and if we replicate all 'inputs' in order then that should be sufficient.</p>
+
+<p>Selectors slightly complicate the picture, as do multiple consumers and flow control particularly for shared queues where the consumers could be from different sessions.</p>
+
+<p>In the case of an exclusive or private queue all the inputs come from a single session. If all session requests are handled serially on both primary and backup then dispatch should be deterministic; if separate threads were used to process separate queues that would be lost as the allocation of delivery tags would be dependent on the interleaving of those threads.</p>
+
+<p>One way of avoiding the need for deterministic dispatch would be for the primary to send a message to the backup(s) to indicate an allocation before the deliver is sent to the client. This could inform the backup of the queue in question, the message id and the delivery tag/request id. The big drawback is that it requires a round-trip to the backup before each deliver and would really affect throughput.</p>
+
+<p>This looks like an area that needs some specific focus. Can we convince ourselves of a clear and deterministic dispatch algorithm, are thereother solutions that would avoid requiring this without too much synchronicity?</p>
+
+
+
+<h2><a name="ClusterDesignNote-message.consume%2Fbasic.consume"></a>message.consume/basic.consume</h2>
+<ul>
+	<li>proxy: forward consume. No replication, client will re-establish consumers.</li>
+	<li>primary: register consumer.</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-basic.ack%2Fmessage.ok%28fromclient%29"></a>basic.ack/message.ok(from client)</h2>
+<ul>
+	<li>proxy: forward</li>
+	<li>primary: mark message processed, replicate to backups.</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-basic.ack%2Fmessage.ok%28frombroker%29"></a>basic.ack/message.ok(from broker)</h2>
+<ul>
+	<li>proxy: forward to client</li>
+	<li>client: mark message processed.</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-basic.reject%2Fmessage.reject"></a>basic.reject / message.reject</h2>
+
+<p>Similar to the processing of basic.ack. However here the message might be requeued or might be moved to a dead letter queue. Ignoring the dead letter queue in the first instance, the backup would merely cancel the effect of the basic.allocate on receiving the basic.reject.</p>
+
+
+<h2><a name="ClusterDesignNote-reference.open%2Fapppend%2Fclose%28clienttobroker%29"></a>reference.open/apppend/close (client to broker)</h2>
+<ul>
+	<li>proxy: replicate to session backup, forward to primary.</li>
+	<li>primary: process.</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-reference.open%2Fapppend%2Fclose%28brokertoclient%29"></a>reference.open/apppend/close (broker to client) **</h2>
+<ul>
+	<li>primary: send open/append/close.</li>
+	<li>proxy: replicate to session backup, forward to client.</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-Allcommands"></a>All commands</h2>
+<ul>
+	<li>proxy replicates required command history to session backup.</li>
+</ul>
+
+
+
+
+<h1><a name="ClusterDesignNote-ClientBrokerProtocol"></a>Client-Broker Protocol</h1>
+
+<p>Normal AMQP with the following extensions.</p>
+
+<p>Initial connection:</p>
+<ul>
+	<li>Pass session name as 0-9 connection identifier or via arguments table.</li>
+	<li>Broker provides list of failover replicas in arguments table.</li>
+</ul>
+
+
+<p>During connection:</p>
+<ul>
+	<li>Client can subscribe to a special "cluster exchange" for messages carrying updates to failover candidates.</li>
+</ul>
+
+
+<p>On failure:</p>
+<ul>
+	<li>client chooses failover node randomly from most recent list.</li>
+	<li>cluster list my identify "preferred" failover candidates.</li>
+</ul>
+
+
+<p>On re-connect:</p>
+<ul>
+	<li>0-9 resume command identifies session.</li>
+	<li>Client rebuilds conversational state.</li>
+	<li>opens channels</li>
+	<li>creates consumers</li>
+	<li>establishes</li>
+	<li>replays unacknowledeged commands and continues session.</li>
+</ul>
+
+
+<p>Note: the client sends conversational state data in messages to a special system exchange. We cant simply use standard AMQP to rebuild channel state, as we will end up with channels with a different command numbering from the interrupted session. For transparency we also want to distinguish reconnection from resumed "normal" operation.</p>
+
+<p>At this point the session can continue.</p>
+
+
+<h1><a name="ClusterDesignNote-BrokerBrokerProtocol"></a>Broker-Broker Protocol</h1>
+
+<p>Broker-broker communication uses extended AMQP over specially identified connections and channels (identified in the connection negotiation argument table.)</p>
+
+<p><b>EVS</b>: First implementation is entirely EVS, all members have a common shared picture of the entire cluster contents.</p>
+
+<p><b>Proxying</b>: acting as a proxy, a broker forwards commands from client to primary and vice versa. The proxy is as transparent and stateless as possible. A proxy must renumer channels and commands since a single incoming connection may be proxied to more than one outbound connection, so it does need to keep some state. This state is part of the session state replicated to the session backup.</p>
+
+<p><b>Queue/fragment replication</b>: Depends on whether AMQP or GFS is used to replicate content.</p>
+
+<p><b>AMQP</b>: For enqueue use AMQP transfer command to transfer content to backup(s). For dequeue use AMQP get command to indicate message removed - no data is transferfed for get over a replication channel.</p>
+
+<p><em>TODO</em>: this use of get is strained, it starts to look like we may need a separate replication class of commands.</p>
+
+<p><b>GFS</b>: Queue state is updated in journal files. On failover, the backup reconstruct queue state from the journal.</p>
+
+<p><b>Session replication</b>: The broker must replicate a command (and get confirmation it was replicated) before responding. For async clients this can be done in a pair of asynchronous streams, i.e. we don't have to wait for a response to command A before we forward command B.</p>
+
+<p>Session data is replicated via AMQP on special connections. Primary forwards all outgoing requests and incoming responses to the session backup. Backup can track the primary request/response tables and retransmit messages.</p>
+
+<p><em><b>TODO</b></em>: 0-9 references force us to have heavy session backup, because message data on a reference is not associated with any queue and therefore can't be backed up in a queue backup. If references are removed in 0-10 revisit the need for session backups, we may be able to comress session data enough to store it in the cluster map.</p>
+
+
+<h1><a name="ClusterDesignNote-PersistenceandRecovery"></a>Persistence and Recovery</h1>
+
+<h2><a name="ClusterDesignNote-Competingfailuremodes%3A"></a>Competing failure modes:</h2>
+
+<p><b>Tibco</b>: fast when running clean but performance over time has GC "spikes" Single journal for all queues. "holes" in log have to be garbage collected to re-use the log. 1 slow consumer affects everyone because it causes fragmentation of the log.</p>
+
+<p><b>MQ</b>: write to journal, write journal to DB, read from DB. Consistent &amp; reliable but slow.</p>
+
+<p><b>Street homegrown solutions</b>: transient MQ with home grown persistence. Can we get more design details for these solutions?</p>
+
+
+
+<h2><a name="ClusterDesignNote-Persistenceoverview"></a>Persistence overview</h2>
+
+<p>There are 3 reasons to persist a message:</p>
+
+<p><b>Durable messages</b>: must be stored to disk across broker shutdowns or failures.</p>
+<ul>
+	<li>stored when received.</li>
+	<li>read during start-up.</li>
+	<li>must be removed after deliver.</li>
+</ul>
+
+
+<p><b>Reliability</b>: recover after a crash.</p>
+<ul>
+	<li>stored when received.</li>
+	<li>read during crash recovery.</li>
+	<li>must be removed after delivery.</li>
+</ul>
+
+
+<p><b>Flow-to-disk</b>: to reduce memory use for full queues.</p>
+<ul>
+	<li>stored when memory gets tight.</li>
+	<li>read when delivered.</li>
+	<li>must be removed after delivery.</li>
+</ul>
+
+
+
+<p>Durable and reliable cases are very similar: storage time is performance-critical (blocks response to sender) but reading is not and cleanup can be done by an async thread or process.</p>
+
+<p>For flow-to-disk, when queues are full, both store and reading are critical.</p>
+
+<p>So it looks like the same solution will work for durable and reliable.</p>
+
+<p>Flow-to-disk has different requirements but it would be desirable to re-use some or all of the durable/reliable solution. In particular if flow-to-disk is combined with durable/reliablle it would be wasteful to write the message to disk a second time - instead it would seem better to keep an in-memory index that allows messages to be read quickly from the reliable/durable store.</p>
+
+<p>We also need to persist <b>wiring</b> (Queues/Exchanges/Bindings), but this is much less performance critical. The entire wiring model is held in memory so wiring is only read at startup, and updates are low volume and not performance-critical. A simple database should suffice.</p>
+
+
+
+<h1><a name="ClusterDesignNote-Journals"></a>Journals</h1>
+
+<h2><a name="ClusterDesignNote-Overview"></a>Overview</h2>
+
+<p>A journal is a sequential record of actions taken (e.g. messages enqueued, responses sent.) sufficient to reconstruct the state of the journalled entity (e.g. queue) in the case of failure and recovery.</p>
+
+
+<p><b>TODO</b>: <em>Journal indexing, async journal (thruput vs. latency), journal as common API for backups and disk store?</em></p>
+
+<p><em><b>TODO</b></em>: <em>Windows for error in journalling - how to make disk update and network ack atomic?  How do other technologies handle it?</em></p>
+
+<p><em><b>TODO</b></em>: <em>References strike again: where do they go in a journal-per-queue?</em></p>
+
+<p><em><b>TODO</b></em>: <em>Journal per broker pros/cons</em></p>
+
+
+<h2><a name="ClusterDesignNote-Useofjournals"></a>Use of journals</h2>
+
+<p>For reliability and durability we will use</p>
+<ul>
+	<li>Queue journal (per queue) records enqueue/dequeues and acknowledgements.</li>
+	<li>Session journal (per session) records references in progress</li>
+</ul>
+
+
+<p>The broker writes enqueue and dequeue records to the end of the active journal file. When the file reaches a fixed size it starts a new one.</p>
+
+<p>A cleanup agent (thread or process) removes, recycles or compacts journal files that have no live (undelivered) messages. (References complicate the book-keeping a little but don't alter the conceptual model.)</p>
+
+<p>Recovery or restart reconstructs the queue contents from the enqueue/dequeue records in the journal.</p>
+
+<p>Flow-to-disk can re-use the journal framework, with a simple extension: the broker keeps an in-memory index of live messages in the journal.</p>
+
+<p>If flow-to-disk is combined with reliability then messages are automatically journalled on arrival, so flow-to-disk can simply delete them from memory and use the in-memory index to read them for delivery.</p>
+
+<p>Without reliability flow-to-disk is similar except that messages are only journalled if memory gets tight.</p>
+
+<p><b>Disk thrashing</b>: Why do we think skipping disk heads around between multiple journals will be better than seeking up and down a single journal? Are we assuming that we only need to optimize the case where long sequences of traffic tend to be for the same queue?</p>
+
+<p><b>No write on fast consume</b>: Optimization - if we can deliver (and get ack) faster than we write then no need to write. How does this interact with HA?</p>
+
+<p><b>Async journalling</b>: writing to client, writing to journal, acks from client, acks from journal are separate async streams? So if we get client ack before the journalling stream has written the journal we cancel the write? But what kind of ack info do we need? Need a diagram of interactions, failure points and responses at each point. Start simple and optimize, but dont rule out optimizations.</p>
+
+
+<h2><a name="ClusterDesignNote-Whataboutdisklessreliability%3F"></a>What about diskless reliability?</h2>
+
+<p>Is memory+network replication with no disk a viable option for high-speed transient message flow? May be faster, but can't support durable messages/persistent queues. We will lose messages in total failure or multiple failures where all backups fail, but we can survive single failures and will run a lot faster than diskful.</p>
+
+
+
+
+<h1><a name="ClusterDesignNote-Virtualsynchrony"></a>Virtual synchrony</h1>
+
+<p><b>TODO</b>: Wiring &amp; membership via virtual synchrony</p>
+
+<p><b>TODO</b>: journaling, speed. Will file-per-q really help with disk burnout?</p>
+
+
+<h1><a name="ClusterDesignNote-Configuration"></a>Configuration</h1>
+
+<h2><a name="ClusterDesignNote-SimplifyingpatternsPossiblewaystoconfigureacluster%3A"></a>Simplifying patterns Possible ways to configure a cluster:</h2>
+<ul>
+	<li>Virtual hosts as units of replication.</li>
+	<li>Backup rings: all primary components in a broker use the same backup broker and vice-versa. Backups form rings.</li>
+	<li>Broker component rinks: all the components <em>except sessions</em> have the same backup broker. Session backups are chosen at random so a brokers load will be distributed rather than all falling on its backup.</li>
+	<li>Disk management issues?</li>
+	<li>Shared storage issues?</li>
+</ul>
+
+
+
+<h2><a name="ClusterDesignNote-Dynamicclusterconfiguration"></a>Dynamic cluster configuration</h2>
+<ul>
+	<li>Failover: the primary use case.</li>
+	<li>Add node: backup, proxy, primary case?</li>
+	<li>Redirect clients from loaded broker (pretend failure)</li>
+	<li>Move queue primary from loaded broker/closer to consumers?</li>
+	<li>Re-start after failover.</li>
+</ul>
+
+
+<p><b>Issue:</b> unit of failover/redirect is connection/channel but "working set" of queues and exchanges is unrelated. Use virtual host as unit for failover/relocation? It's also a queue namespace...</p>
+
+<p>If a queue moves we have to redirect its <em>consumers</em>, can't redirect entire channels! Channels in the same session may move between connections. Or rather we depend on broker to proxy?</p>
+
+<p>Backups: chained backups rather than multi-backup? Ring backup? What about split brain, elections, quorums etc.</p>
+
+<p>Should new backups acquire state from primary, from disk or possibly both? Depends on GFS/SAN vs. commodity hw?</p>
+
+
+
+<h1><a name="ClusterDesignNote-Transactions"></a>Transactions</h1>
+
+<h2><a name="ClusterDesignNote-Localtransactions"></a>Local transactions</h2>
+
+<p>AMQP offers local and distributed transactions, however in a cluster a local transaction could involve queues that are distributed across several nodes.</p>
+
+<p><em><b>TODO</b></em>: This complicates the model of a proxy as a simple forwarder. You cannot simply forward a local transaction involving queues on two separate primary brokers, the proxy has to be aware of the transaction.</p>
+
+<p><em><b>TODO</b></em> Can we use point-to-point local transactions or do we have to turn this into a dtx? If dtx, who co-ordinates? Is every broker potentially a transaction co-ordinator?</p>
+
+<p><em><b>TODO</b></em>: For distributed transactions, will the primary broker and its backups act as a single clustered resource manager for the resource set, or will a failure of one broker abort the transaction?</p>
+
+
+<h2><a name="ClusterDesignNote-DistributedTransactions"></a>Distributed Transactions</h2>
+
+<p>The prepare needs to be replicated so that if one node fails before completion another node can honour the guarantee to be able to commit or abort. It is also possibe that the work of a transaction is distributed across more than one node anyway.</p>
+
+<p>I think broadcasting all dtx commands over the group communication protocol seems like the most likely way to handle this.</p>
+
+<p>The session in which the commands are initiated needs to be replicated also to allow clean resumption on failover.</p>
+
+
+
+
+<h1><a name="ClusterDesignNote-OpenQuestions"></a>Open Questions</h1>
+
+<p>Issues: double failure in backup ring: A -&gt; B -&gt; C. Simultaneous failure of A and B. C doesn't have the replica data to take over for A.</p>
+
+<p>Java/C++ interworking - is there a requirement? Fail over from C++ to Java? Common persistence formats?</p>
+
+
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/Cluster Design Note.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/ClusteringAndFederation.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/ClusteringAndFederation.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/ClusteringAndFederation.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/ClusteringAndFederation.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,135 @@
+<html>
+    <head>
+        <title>Apache Qpid : ClusteringAndFederation</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : ClusteringAndFederation
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Oct 19, 2006 by <font color="#0050B2">mmccorma</font>.
+				    </div>
+
+				    <h1><a name="ClusteringAndFederation-ClusteringAndFederation"></a>Clustering And Federation</h1>
+
+<p>Each diagram below depicts a distributed network of exchanges and queues. The following notation is used in all diagrams:</p>
+<ul>
+	<li>M: message</li>
+	<li>E: exchange</li>
+	<li>Q: queue</li>
+</ul>
+
+
+<h2><a name="ClusteringAndFederation-Multicast"></a>Multicast</h2>
+
+<div class="preformatted"><div class="preformattedContent">
+<pre>                     M1...Mn
+                   +--------&gt; Q
+                   |
+                   | M1...Mn
+ M1...Mn ---&gt; E----+--------&gt; Q
+                   |
+                   | M1...Mn
+                   +--------&gt; Q
+</pre>
+</div></div>
+
+<p>Queue contents are duplicated across all queues. For this scenario PGM<br/>
+would be ideal between E and Q, or even directly between E and<br/>
+consumers.</p>
+
+<h2><a name="ClusteringAndFederation-LoadBalancing"></a>Load Balancing </h2>
+
+<div class="preformatted"><div class="preformattedContent">
+<pre>                     M1
+                   +--------&gt; Q
+                   |
+                   | ...
+ M1...Mn ---&gt; E----+--------&gt; Q
+                   |
+                   | Mn
+                   +--------&gt; Q
+</pre>
+</div></div>
+
+<p>No ordering is guaranteed accross different queues. A naive<br/>
+implementation could just be an exchange doing round-robin routing or<br/>
+any algorithm of choice. A more complicated exchange could have flow<br/>
+control between each queue and the exchange.</p>
+
+<h2><a name="ClusteringAndFederation-MultipleExchanges"></a>Multiple Exchanges </h2>
+
+<div class="preformatted"><div class="preformattedContent">
+<pre> M? ---&gt; E1-----+              +-----&gt; Q1
+                |              |
+                | (n*m arrows) |
+ M? ---&gt; E2-----+--------------+-----&gt; Q2
+                |              |
+                |              |
+ M? ---&gt; En-----+              +-----&gt; Qm
+</pre>
+</div></div>
+
+<p>Both the Load Balancing and Multicast scenarios can be extended by<br/>
+adding multiple exchange nodes wired into the same (or an overlapping)<br/>
+set of queues. One virtual mega exchange (with relaxed ordering<br/>
+semantics) could be created by segmenting client connections between<br/>
+exchanges. This could be done using a number of strategies, e.g.<br/>
+round-robin dns, name mangling, redirects.</p>
+
+<p>The topologies described above could in theory be use in a variety of<br/>
+scenarios ranging from an an isolated high speed subnet with<br/>
+identically configured nodes to a loosely coupled WAN with separately<br/>
+administered nodes. In fact a single network could include exchanges<br/>
+bound to local queues, remote queues available on an isolated high<br/>
+speed subnet, and remote destinations (exchange or queue) available<br/>
+over WAN/internet. In the last case the exchange may be requred to<br/>
+queue messages routed to the remote destination if the WAN/internet<br/>
+link is down.</p>
+
+<p>In the terminology I've been using, a cluster is a set of machines<br/>
+sharing the same software and configuration, and generally connected<br/>
+via an isolated high speed subnet. A federation on the other hand<br/>
+consists of distinctly configured machines individually wired<br/>
+together. Both clustering and federation <b>could</b> share a common<br/>
+protocol for message delivery. This could possibly even be used for<br/>
+multicast if it were a simple stateless store-and-forward protocol.<br/>
+(Note the "store" in "store-and-forward" can mean both store on disk<br/>
+and store in memory.)</p>
+
+<p>With this model the key distinction between a cluster and a federation<br/>
+is that all the nodes in a cluster are managed as a single unit, e.g.<br/>
+one place to start/stop/add/remove/etc. Because of this the nodes in a<br/>
+cluster have to pass control messages to each other distinct from the<br/>
+general message traffic. These control messages need to be isolated<br/>
+from the general message traffic (e.g. on their own subnet). This<br/>
+could be done using JGroups and OpenAIS for Java and C++ respectively.</p>
+
+<p>This document doesn't directly address fault tolerance, but it is<br/>
+assumed that any node/broker that contains state can be configured to<br/>
+have a passive counterpart that supports two methodologies for<br/>
+failover. Broker swapout based on virtual IP, or client reconnect to a<br/>
+backup IP.</p>
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/ClusteringAndFederation.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/ClusteringHA.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/ClusteringHA.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/ClusteringHA.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/ClusteringHA.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,66 @@
+<html>
+    <head>
+        <title>Apache Qpid : ClusteringHA</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : ClusteringHA
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Sep 25, 2007 by <font color="#0050B2">aconway</font>.
+				    </div>
+
+				    <h2><a name="ClusteringHA-Definitions"></a>Definitions </h2>
+
+<p>The topic is being broken up into three sections:</p>
+
+<ul>
+	<li>Federation (a set of distributed exchanges and queues, seperately managed and wired together)</li>
+	<li>Clustering (a set of distributed exchanges and queues managed as a single entity)</li>
+	<li>HA / Fault tolarance (the ability for exchanges and queues, clustered, federated, or isolated to replicated important state to a backup (failover partner))</li>
+	<li>Failover (the ability for a client to reconnect to the failover partner)</li>
+</ul>
+
+
+<h2><a name="ClusteringHA-Requirements%2FUseCases"></a>Requirements/Use Cases </h2>
+
+<ul>
+	<li><a href="Reliability Requirements.html" title="Reliability Requirements">Reliability Requirements</a></li>
+	<li><a href="ClusteringAndFederation.html" title="ClusteringAndFederation">ClusteringAndFederation</a></li>
+</ul>
+
+
+<h2><a name="ClusteringHA-Designnotes"></a>Design notes </h2>
+<ul>
+	<li><a href="Cluster Design Note.html" title="Cluster Design Note">Cluster Design Note</a> - primary/backup pairing, transaction logging.</li>
+</ul>
+
+
+<p>Historical</p>
+<ul>
+	<li><a href="Old Clustering Design Note.html" title="Old Clustering Design Note">Old Clustering Design Note</a></li>
+</ul>
+
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/ClusteringHA.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/Configure ACLs.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Configure%20ACLs.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Configure ACLs.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Configure ACLs.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,40 @@
+<html>
+    <head>
+        <title>Apache Qpid : Configure ACLs</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Configure ACLs
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Apr 08, 2008 by <font color="#0050B2">ritchiem</font>.
+				    </div>
+
+				    <h2><a name="ConfigureACLs-ConfigureACLs"></a>Configure ACLs</h2>
+
+<p>This page will be completed shortly with details on how to configure ACLs on the M2.1 broker.</p>
+
+<p>TBC</p>
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/Configure ACLs.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/Configure Java Qpid to use a SSL connection..html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Configure%20Java%20Qpid%20to%20use%20a%20SSL%20connection..html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Configure Java Qpid to use a SSL connection..html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Configure Java Qpid to use a SSL connection..html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,64 @@
+<html>
+    <head>
+        <title>Apache Qpid : Configure Java Qpid to use a SSL connection.</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Configure Java Qpid to use a SSL connection.
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Dec 05, 2007 by <font color="#0050B2">ritchiem</font>.
+				    </div>
+
+				    <h2><a name="ConfigureJavaQpidtouseaSSLconnection.-UsingSSLconnectionwithQpidJava."></a>Using SSL connection with Qpid Java.</h2>
+
+<p>This section will show how to use SSL to enable secure connections between a Java client and broker.</p>
+
+
+<h2><a name="ConfigureJavaQpidtouseaSSLconnection.-Setup"></a>Setup</h2>
+
+<h3><a name="ConfigureJavaQpidtouseaSSLconnection.-BrokerSetup"></a>Broker Setup</h3>
+
+<p>The broker configuration file (config.xml) needs to be updated to include the SSL keystore location details.</p>
+<div class="code" style="border-style: solid; "><div class="codeHeader" style="border-bottom-style: solid; "><b>Additions required to Connector Section</b></div><div class="codeContent">
+<pre class="code-java">&lt;ssl&gt;
+    &lt;enabled&gt;<span class="code-keyword">true</span>&lt;/enabled&gt;
+    &lt;sslOnly&gt;<span class="code-keyword">true</span>&lt;/sslOnly&gt;
+    &lt;keystorePath&gt;/path/to/keystore.ks&lt;/keystorePath&gt;
+    &lt;keystorePassword&gt;keystorepass&lt;/keystorePassword&gt;
+&lt;/ssl&gt;</pre>
+</div></div>
+
+<p>The sslOnly option is included here for completeness however this will disable the unencrypted port and leave only the SSL port listening for connections.</p>
+
+
+<h3><a name="ConfigureJavaQpidtouseaSSLconnection.-ClientSetup"></a>Client Setup</h3>
+
+<p>The best place to start looking is class <em>SSLConfiguration</em> this is provided to the connection during creation however there is currently no example that demonstrates its use.</p>
+
+<h2><a name="ConfigureJavaQpidtouseaSSLconnection.-Performingtheconnection."></a>Performing the connection.</h2>
+
+
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/Configure Java Qpid to use a SSL connection..html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/Configure the Broker via config.xml.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Configure%20the%20Broker%20via%20config.xml.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Configure the Broker via config.xml.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Configure the Broker via config.xml.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,51 @@
+<html>
+    <head>
+        <title>Apache Qpid : Configure the Broker via config.xml</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Configure the Broker via config.xml
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Apr 08, 2008 by <font color="#0050B2">ritchiem</font>.
+				    </div>
+
+				    <h2><a name="ConfiguretheBrokerviaconfig.xml-Brokerconfig.xmlOverview"></a>Broker config.xml Overview</h2>
+
+<p>The broker config.xml file which is shipped in the etc directory of any Qpid binary distribution details various options and configuration for the Java Qpid broker implementation.</p>
+
+<p>In tandem with the virtualhosts.xml file, the config.xml file allows you to control much of the deployment detail for your Qpid broker in a flexible fashion. </p>
+
+<p>Note that you can pass the config.xml you wish to use for your broker instance to the broker using the -c command line option. In turn, you can specify the paths for the broker password file and virtualhosts.xml files in your config.xml for simplicity.</p>
+
+<p>For more information about command line configuration options please see <a href="http://cwiki.apache.org/confluence/display/qpid/Qpid+Design+-+Configuration" title="Visit page outside Confluence">Qpid Design - Configuration</a>.</p>
+
+<h2><a name="ConfiguretheBrokerviaconfig.xml-QpidVersion"></a>Qpid Version</h2>
+
+<p>The config format has changed between versions here you can find the configuration details on a per version basis.</p>
+
+<p><a href="M2 - config.xml.html" title="M2 - config.xml">M2 &#45; config.xml</a><br/>
+<a href="M2.1 - config.xml.html" title="M2.1 - config.xml">M2.1 &#45; config.xml</a></p>
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Added: incubator/qpid/branches/forrest-site/content/xdocs/Configure the Virtual Hosts via virtualhosts.xml.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Configure%20the%20Virtual%20Hosts%20via%20virtualhosts.xml.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Configure the Virtual Hosts via virtualhosts.xml.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Configure the Virtual Hosts via virtualhosts.xml.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,113 @@
+<html>
+    <head>
+        <title>Apache Qpid : Configure the Virtual Hosts via virtualhosts.xml</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Configure the Virtual Hosts via virtualhosts.xml
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Apr 06, 2007 by <font color="#0050B2">mmccorma</font>.
+				    </div>
+
+				    <h2><a name="ConfiguretheVirtualHostsviavirtualhosts.xml-virtualhosts.xmlOverview"></a>virtualhosts.xml Overview</h2>
+
+<p>This configuration file contains details of all queues and topics, and associated properties, to be created on broker startup. These details are configured on a per virtual host basis.</p>
+
+<p>Note that if you do not add details of a queue or topic you intend to use to this file, you must first create a consumer on a queue/topic before you can publish to it using Qpid. </p>
+
+<p>Thus most application deployments need a virtualhosts.xml file with at least some minimal detail.</p>
+
+<h3><a name="ConfiguretheVirtualHostsviavirtualhosts.xml-XMLFormatwithComments"></a>XML Format with Comments</h3>
+
+<p>The virtualhosts.xml which currently ships as part of the Qpid distribution is really targeted at development use, and supports various artifacts commonly used by the Qpid development team.</p>
+
+<p>As a result, it is reasonably complex. In the example XML below, I have tried to simplify one example virtual host setup which is possibly more useful for new users of Qpid or development teams looking to simply make use of the Qpid broker in their deployment.</p>
+
+<p>I have also added some inline comments on each section, which should give some extra information on the purpose of the various elements.</p>
+
+<div class="preformatted"><div class="preformattedContent">
+<pre>
+&lt;virtualhosts&gt;
+    &lt;!-- Sets the default virtual host for connections which do not specify a vh --&gt;
+    &lt;default&gt;localhost&lt;/default&gt;
+    &lt;!-- Define a virtual host and all it's config --&gt;
+    &lt;virtualhost&gt;
+        &lt;name&gt;localhost&lt;/name&gt;
+        &lt;localhost&gt;    
+            &lt;!-- Define the types of additional AMQP exchange available for this vh --&gt;   
+            &lt;!-- Always get amq.direct (for queues) and amq.topic (for topics) by default --&gt;     
+            &lt;exchanges&gt;
+                &lt;!-- Example of declaring an additional exchanges type for developer use only --&gt;
+                &lt;exchange&gt;
+                    &lt;type&gt;direct&lt;/type&gt;
+                    &lt;name&gt;test.direct&lt;/name&gt;
+                    &lt;durable&gt;true&lt;/durable&gt;
+                &lt;/exchange&gt;
+            &lt;/exchanges&gt;
+             
+            &lt;!-- Define the set of queues to be created at broker startup --&gt;
+            &lt;queues&gt;
+                &lt;!-- The properties configured here will be applied as defaults to all --&gt;
+                &lt;!-- queues subsequently defined unless explicitly overridden --&gt;
+                &lt;exchange&gt;amq.direct&lt;/exchange&gt;
+                &lt;!-- Set threshold values for queue monitor alerting to log --&gt; 
+                &lt;maximumQueueDepth&gt;4235264&lt;/maximumQueueDepth&gt;  &lt;!-- 4Mb --&gt;
+                &lt;maximumMessageSize&gt;2117632&lt;/maximumMessageSize&gt; &lt;!-- 2Mb --&gt;
+                &lt;maximumMessageAge&gt;600000&lt;/maximumMessageAge&gt;  &lt;!-- 10 mins --&gt;
+
+                &lt;!-- Define a queue with all default settings --&gt;   
+                &lt;queue&gt;
+                    &lt;name&gt;ping&lt;/name&gt;
+                &lt;/queue&gt;
+                &lt;!-- Example definitions of queues with overriden settings --&gt;
+                &lt;queue&gt;
+                    &lt;name&gt;test-queue&lt;/name&gt;
+                    &lt;test-queue&gt;
+                        &lt;exchange&gt;test.direct&lt;/exchange&gt;
+                        &lt;durable&gt;true&lt;/durable&gt;
+                    &lt;/test-queue&gt;
+                &lt;/queue&gt;
+                &lt;queue&gt;
+                    &lt;name&gt;test-ping&lt;/name&gt;
+                    &lt;test-ping&gt;
+                        &lt;exchange&gt;test.direct&lt;/exchange&gt;
+                    &lt;/test-ping&gt;
+                &lt;/queue&gt;
+            &lt;/queues&gt;
+        &lt;/localhost&gt;
+    &lt;/virtualhost&gt;
+&lt;/virtualhosts&gt;
+</pre>
+</div></div>
+
+
+<h3><a name="ConfiguretheVirtualHostsviavirtualhosts.xml-Usingyourownvirtualhosts.xml"></a>Using your own virtualhosts.xml</h3>
+
+<p>Note that the config.xml file shipped as an example (or developer default) in the Qpid distribution contains an element which defines the path to the virtualhosts.xml. </p>
+
+<p>When using your own virtualhosts.xml you must edit this path to point at the location of your file.</p>
+
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/Configure the Virtual Hosts via virtualhosts.xml.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/Configuring Qpid Management Console.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Configuring%20Qpid%20Management%20Console.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Configuring Qpid Management Console.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Configuring Qpid Management Console.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,105 @@
+<html>
+    <head>
+        <title>Apache Qpid : Configuring Qpid Management Console</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Configuring Qpid Management Console
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Jun 29, 2007 by <font color="#0050B2">ritchiem</font>.
+				    </div>
+
+				    <h2><a name="ConfiguringQpidManagementConsole-ConfiguringQpidManagementConsole"></a>Configuring Qpid Management Console</h2>
+
+<p>QPID&nbsp;has a management interface that exposes . By default the management interface is enabled but it can also be disabled by modifying the management element in config.xml.</p>
+
+<p>When starting the broker, the following system properties need to be set by setting the environment variable QPID_OPTS:</p>
+<div class="panel"><div class="panelContent">
+<p>QPID_OPTS="-Dcom.sun.management.jmxremote &#45;Dcom.sun.management.jmxremote.port=8999 &#45;Dcom.sun.management.jmxremote.authenticate=false &#45;Dcom.sun.management.jmxremote.ssl=false"</p>
+</div></div>
+
+<p>Note that you should only use these settings for non-production systems. For production deployments you should use authentication !</p>
+
+<p>You can find out more about the features exposed by the Qpid JMS interfaces <a href="https://confluence.uk.jpmorgan.com/confluence/display/IBTAMQ/QPID+Management+Features" title="Visit page outside Confluence">here</a>.</p>
+
+<h2><a name="ConfiguringQpidManagementConsole-UsingEclipseRCP"></a>Using Eclipse RCP</h2>
+
+
+<h3><a name="ConfiguringQpidManagementConsole-InstallingtheQpidManagementConsole%28eclipseRCP%29"></a>Installing the Qpid Management Console (eclipse RCP)</h3>
+
+<p>Unzip the management eclipse plugin zip for windows in a dir (eg C:/). A&nbsp;dir with name qpidmc (eg C:/qpidmc) will get created.</p>
+
+<p>To run the RCP from command prompt, set the environment variable QPIDMC_HOME to installation dir (eg. QPIDMC_HOME=C:/qpidmc)&nbsp; and include $QPIDMC_HOME/bin in your PATH.</p>
+
+<h3><a name="ConfiguringQpidManagementConsole-RunningtheQpidManagementConsole%28eclipseRCP%29"></a>Running the Qpid Management Console (eclipse RCP)</h3>
+
+<p>To run this application on windows, run any of these scripts&#45;</p>
+
+<p>qpidmc.bat (windows command prompt)</p>
+
+<p>qpidmc.sh&nbsp; (cygwin)&nbsp;</p>
+
+<p>For running on unix, use the scritps for particular windowing system<br/>
+qpidmc_&lt;windowing system&gt;.sh (eg. qpidmc_motif.sh)</p>
+
+<h3><a name="ConfiguringQpidManagementConsole-UsingtheQpidManagementConsole%28eclipseRCP%29"></a>Using the Qpid Management Console (eclipse RCP)</h3>
+
+<p>Please see <span class="error">&#91;attachment |^Qpid_Management_Console.doc&#93;</span>&nbsp;for using this Eclipse RCP.&nbsp; Attchment contains some of the screenshots of Qpid Management Console (Eclipse RCP) .</p>
+
+<h2><a name="ConfiguringQpidManagementConsole-UsingJConsole"></a>Using JConsole</h2>
+
+<p>JConsole is a management tool that comes with the Java Runtime Environment and provides a very simple view of managed beans. It requires no special configuration to be used with QPID.</p>
+
+<p>To attach to a running&nbsp;broker simply enter the host and port details on the JConsole connect dialog. The port should be the same as the one specified in the system property <tt>com.sun.management.jmxremote.port</tt>.</p>
+
+<p>Once you are connected expand the tree nodes marked "org.apache".</p>
+
+<p>Please see attachment for some of the&nbsp;<span class="error">&#91;screenshots|^Qpid_using_jconsole.doc&#93;</span> of using jconsole for Qpid.</p>
+
+<h2><a name="ConfiguringQpidManagementConsole-UsingHermesJMS"></a>Using HermesJMS</h2>
+
+<p>HermesJMS also offers integration with the Qpid management interfaces. You can get instructions and more information from <a href="http://wiki.apache.org/qpid/HermesJMS" title="Visit page outside Confluence">http://wiki.apache.org/qpid/HermesJMS</a>.</p>
+
+<h2><a name="ConfiguringQpidManagementConsole-UsingMC4J"></a>Using MC4J</h2>
+
+<p><a href="http://www.mc4j.org" title="Visit page outside Confluence">MC4J</a> is an alternative management tool. It provide a richer "dashboard" that can customise the raw MBeans.</p>
+
+<h4><a name="ConfiguringQpidManagementConsole-Installation"></a>Installation</h4>
+
+<ul>
+	<li>First download and install MC4J for your platform. Version 1.2 beta 9 is the latest version that has been tested.</li>
+	<li>Copy the directory <tt>blaze/java/management/mc4j</tt> into the directory <tt>&lt;MC4J-Installation&gt;/dashboards</tt></li>
+</ul>
+
+
+<h4><a name="ConfiguringQpidManagementConsole-Configuration"></a>Configuration</h4>
+
+<p>You should create a connection the JVM to be managed. Using the <tt>Management-&gt;Create Server Connection</tt> menu option. The connection URL should be of the form: <tt>service:jmx:rmi:///jndi/rmi://localhost:8999/jmxrmi</tt> making the appropriate host and post changes.</p>
+
+<h4><a name="ConfiguringQpidManagementConsole-Operation"></a>Operation</h4>
+
+<p>You can view tabular summaries of the queues, exchanges and connections using the Global Dashboards-&gt;QPID tree view. To drill down on individual beans you can right click on the bean. This will show any available graphs too.</p>
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/Configuring Qpid Management Console.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/qpid/branches/forrest-site/content/xdocs/Connection URL Format.html
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/forrest-site/content/xdocs/Connection%20URL%20Format.html?rev=650447&view=auto
==============================================================================
--- incubator/qpid/branches/forrest-site/content/xdocs/Connection URL Format.html (added)
+++ incubator/qpid/branches/forrest-site/content/xdocs/Connection URL Format.html Tue Apr 22 04:58:44 2008
@@ -0,0 +1,167 @@
+<html>
+    <head>
+        <title>Apache Qpid : Connection URL Format</title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">	    
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="pageheader">
+					    <span class="pagetitle">
+                            Apache Qpid : Connection URL Format
+                                                    </span>
+				    </div>
+				    <div class="pagesubheading">
+					    This page last changed on Apr 02, 2008 by <font color="#0050B2">asimon</font>.
+				    </div>
+
+				    <div class="preformatted"><div class="preformattedContent">
+<pre>amqp://[&lt;user&gt;:&lt;pass&gt;@][&lt;clientid&gt;]&lt;virtualhost&gt;[?&lt;option&gt;='&lt;value&gt;'[&amp;&lt;option&gt;='&lt;value&gt;']]
+</pre>
+</div></div>
+
+<p>The connection url defines the values that are common across the cluster of brokers. The virtual host is second in the list as the AMQP specification demands that it start with a '/' otherwise it be more readable to be swapped with clientid. There is currently only one required option and that is the <b>brokerlist</b> option. In addition the following options are recognised.</p>
+
+<table class='confluenceTable'><tbody>
+<tr>
+<th class='confluenceTh'>Option</th>
+<th class='confluenceTh'>Default</th>
+<th class='confluenceTh'>Description</th>
+</tr>
+<tr>
+<td class='confluenceTd'>ssl</td>
+<td class='confluenceTd'>false</td>
+<td class='confluenceTd'>Set the default for all connections. This can be overridden by the individual broker url.</td>
+</tr>
+<tr>
+<td class='confluenceTd'>brokerlist</td>
+<td class='confluenceTd'>see below</td>
+<td class='confluenceTd'>The list of brokers to use for this connection</td>
+</tr>
+<tr>
+<td class='confluenceTd'>failover</td>
+<td class='confluenceTd'>see below</td>
+<td class='confluenceTd'>The type of failover method to use with the broker list.</td>
+</tr>
+<tr>
+<td class='confluenceTd'>cyclecount</td>
+<td class='confluenceTd'>0</td>
+<td class='confluenceTd'> The number of times to loop through the list of available brokers before failure.</td>
+</tr>
+</tbody></table>
+
+<h4><a name="ConnectionURLFormat-Brokerlistoption"></a>Brokerlist option </h4>
+<div class="preformatted"><div class="preformattedContent">
+<pre>brokerlist='&lt;broker url&gt;[;&lt;broker url&gt;]'
+</pre>
+</div></div>
+
+<p>The broker list defines the various brokers that can be used for this connection. A minimum of one broker url is required additional URLs are semi-colon(';') delimited.</p>
+
+<h4><a name="ConnectionURLFormat-BrokerURLformat"></a>Broker URL format </h4>
+<div class="preformatted"><div class="preformattedContent">
+<pre>&lt;transport&gt;://&lt;host&gt;[:&lt;port&gt;][?&lt;option&gt;='&lt;value&gt;'[&amp;&lt;option&gt;='&lt;value&gt;']]
+</pre>
+</div></div>
+
+<p>There are currently quite a few default values that can be assumed. This was done so that the current client examples would not have to be re-written. The result is if there is no transport, 'tcp' is assumed and the default AMQP port of 5672 is used if no port is specified.</p>
+
+<table class='confluenceTable'><tbody>
+<tr>
+<th class='confluenceTh'>Transport</th>
+</tr>
+<tr>
+<td class='confluenceTd'>tcp</td>
+</tr>
+<tr>
+<td class='confluenceTd'>vm</td>
+</tr>
+</tbody></table>
+
+<p>Currently only 'tcp' and 'vm' transports are supported. Each broker can take have additional options that are specific to that broker. The following are currently implemented options. To add support for further transports the ''client.transportTransportConnection'' class needs updating along with the parsing to handle the transport.</p>
+
+
+<table class='confluenceTable'><tbody>
+<tr>
+<th class='confluenceTh'>Option</th>
+<th class='confluenceTh'>Default</th>
+<th class='confluenceTh'>Description</th>
+</tr>
+<tr>
+<td class='confluenceTd'>retries</td>
+<td class='confluenceTd'>1</td>
+<td class='confluenceTd'> The number of times to retry connection to this Broker</td>
+</tr>
+<tr>
+<td class='confluenceTd'>ssl</td>
+<td class='confluenceTd'>false</td>
+<td class='confluenceTd'>Use ssl on the connection</td>
+</tr>
+<tr>
+<td class='confluenceTd'>connecttimeout</td>
+<td class='confluenceTd'>30000</td>
+<td class='confluenceTd'>How long in (milliseconds) to wait for the connection to succeed</td>
+</tr>
+<tr>
+<td class='confluenceTd'>connectdelay</td>
+<td class='confluenceTd'>none</td>
+<td class='confluenceTd'>How long in (milliseconds) to wait before attempting to reconnect</td>
+</tr>
+</tbody></table>
+
+
+<h4><a name="ConnectionURLFormat-Brokerlistfailoveroption"></a>Brokerlist failover option </h4>
+<div class="preformatted"><div class="preformattedContent">
+<pre>failover='&lt;method&gt;[?&lt;options&gt;]'
+</pre>
+</div></div>
+
+<p>This option controls how failover occurs when presented with a list of brokers. There are only two methods currently implemented but interface <tt>qpid.jms.failover.FailoverMethod</tt> can be used for defining further methods.</p>
+
+<p>Currently implemented failover methods.</p>
+
+<table class='confluenceTable'><tbody>
+<tr>
+<th class='confluenceTh'>Method</th>
+<th class='confluenceTh'>Description</th>
+</tr>
+<tr>
+<td class='confluenceTd'>singlebroker</td>
+<td class='confluenceTd'>This will only use the first broker in the list.</td>
+</tr>
+<tr>
+<td class='confluenceTd'>roundrobin</td>
+<td class='confluenceTd'>This method tries each broker in turn.</td>
+</tr>
+</tbody></table>
+
+<p>The current defaults are naturally to use the 'singlebroker' when only one broker is present and the 'roundrobin' method with multiple brokers. The '''method''' value in the URL may also be any valid class on the classpath that implements the <tt>FailoverMethod</tt> interface.</p>
+
+<h3><a name="ConnectionURLFormat-SampleURLs"></a>Sample URLs </h3>
+<div class="preformatted"><div class="preformattedContent">
+<pre>amqp:///test?brokerlist='localhost'
+amqp:///test?brokerlist='tcp://anotherhost:5684?retries='10''
+amqp://guest:guest@/test?brokerlist='vm://:1;vm://:2'&amp;failover='roundrobin'
+amqp://guest:guest@/test?brokerlist='vm://:1;vm://:2'&amp;cyclecount='20'
+amqp://guest:guest@client/test?ssl='true'&amp;brokerlist='tcp://localhost;tcp://redundant-server:5673?ssl='false''&amp;failover='roundrobin'
+</pre>
+</div></div>
+
+
+				    
+                    			    </td>
+		    </tr>
+	    </table>
+	    <table border="0" cellpadding="0" cellspacing="0" width="100%">
+			<tr>
+				<td height="12" background="border/border_bottom.gif"><img src="border/spacer.gif" width="1" height="1" border="0"/></td>
+			</tr>
+		    <tr>
+			    <td align="center"><font color="grey">Document generated by Confluence on Apr 22, 2008 02:47</font></td>
+		    </tr>
+	    </table>
+    </body>
+</html>
\ No newline at end of file

Propchange: incubator/qpid/branches/forrest-site/content/xdocs/Connection URL Format.html
------------------------------------------------------------------------------
    svn:executable = *



Mime
View raw message