qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Qpid > Qpid Network Layer Update 2010
Date Wed, 02 Mar 2011 10:29:00 GMT
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2036/9/21/_/styles/combined.css?spaceKey=qpid&amp;forWysiwyg=true"
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Network+Layer+Update+2010">Qpid
Network Layer Update 2010</a></h2>
    <h4>Page  <b>added</b> by             <a href="https://cwiki.apache.org/confluence/display/~andrew.kennedy">Andrew
    <div class="notificationGreySide">
         <h1><a name="QpidNetworkLayerUpdate2010-Introduction"></a>Introduction</h1>

<p>This page covers analysis and design work for the work to refactor and improve the
network layer code of the Qpid Java client and broker. The purpos this is to rationalise the
network layer interfaces across all AMQP protocol versions, all network transport types and
to allow the same network code to be used in both the client and the broker if required. Additionally,
it allows for future changes to the network code in a manner that is independent of the protocols
or transports. Further improvements to the broker have also be included in the scope of this
work, including making the <tt>ApplicationRegistry</tt> object a singleton, and
collecting broker startup code in a single class to allow various use cases, such as OSGi
modularisation or system testing to be simplified. On the client side, 0-10 <em>VM</em>
protocol support is added, as well as better failover and exception handling in the 0-10 code
paths. In general, the coupling between different parts of the system is reduced and the responsibilities
of individual classes are reduced and better defined. Test coverage is also improved across
all supported AMQP protocols, and many test cases that are currently failing under 0-10 are

<p>A <span class="error">&#91;Presentation|^transport-layer.ppt&#93;</span>
is available describing the status as of September 2010, when the bulk of this work was initiated
and carried out. More recently, in February 2011 the code has been revisited and merged with
the trunk in preparation for being committed as part of the 0.11 development stream and with
the intention of the inclusion in the 0.12 release..</p>

<h2><a name="QpidNetworkLayerUpdate2010-OriginalTransportCode"></a>Original
Transport Code</h2>

<h3><a name="QpidNetworkLayerUpdate2010-08and09Client"></a>0-8 and 0-9 Client</h3>

		<li><tt>ITransportConnection#connect(AMQProtocolhandler, BrokerDetails)</tt>

<h3><a name="QpidNetworkLayerUpdate2010-010Client"></a>0-10 Client</h3>


<h3><a name="QpidNetworkLayerUpdate2010-Broker"></a>Broker</h3>


<h2><a name="QpidNetworkLayerUpdate2010-Design"></a>Design</h2>

<p>New set of interfaces to define a 0-10 (and maybe 1-0 too) transport interface. Note
that this means MINA, Grizzly, NII etc. rather than TCP/IP, UDP, Unix Sockets, Pipes or whatever.
It should be possible to have different underlying transport mechanism, however, so when MINA
is specified, we can further implement the Socket, VmPipe etc. connectors.</p>

<p><span class="error">Unable to render embedded object: File (qpid-transport.png)
not found.</span><br/>
<b>This diagram shows the relationship between various components in the networking
layer of the Qpid broker and client.</b></p>

<h3><a name="QpidNetworkLayerUpdate2010-ClassesandInterfaces"></a>Classes
and Interfaces</h3>

<p><span class="error">Unable to render embedded object: File (networking-classes-orig.png)
not found.</span><br/>
<b>This diagram shows the original Java classes involved in the Qpid networking layer.</b></p>

<p>The intention of the work is to simplify the interface hierarchy, and in particular
get rid of situations such as the <tt>ProtocolEngine_0_10</tt> interface, where
<b>A</b> implements <b>B</b> which extends <b>C</b>, and
also <b>A</b> extends <b>B'</b> which implements <b>C</b>,
this being rather redundant. Additional issues with interfaces include duplicate method declarations,
where a method is defined in interface <b>A</b>, <b>B</b> extends
<b>A</b> but still declares the same method. These should be removed where possible.</p>

<p>Ideally, <tt>ProtocolEngine</tt> will be replaced by <tt>Receiver&lt;ByteBuffer&gt;</tt>
everywhere, and the extra methods moved to a transport layer interface.</p>

<p>I came across the following snippet in <tt>AMQConnectionDelegate_8_0#makeBrokerConnection()</tt>
and wondered what the <em>UseTransportIo</em> property was for:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
   <span class="code-comment">// TODO: use system property thingy <span class="code-keyword">for</span>
<span class="code-keyword">this</span>
</span>   <span class="code-keyword">if</span> (<span class="code-object">System</span>.getProperty(<span
class="code-quote">"UseTransportIo"</span>, <span class="code-quote">"<span
class="code-keyword">false</span>"</span>).equals(<span class="code-quote">"<span
       TransportConnection.getInstance(brokerDetail).connect(_conn._protocolHandler, brokerDetail);
   <span class="code-keyword">else</span>

<p>See <a href="http://svn.apache.org/viewvc?view=revision&amp;revision=684016"
class="external-link" rel="nofollow">viewvc</a> for when the change was made.</p>

<p>As far as I can tell, the code that would be called if this property is set (for
instance <tt>IoTransport.connect_0_9()</tt> and some associated classes that seem
to be 0-9 specific) is not tested, <b>or</b> used, and I have difficulty understanding
the purpose. It looks very much to me like an attempt at another transport layer, but only
implemented for the 0-9 protocol? Interestingly, it uses a <tt>Binding&lt;X,Y&gt;</tt>
object, which also crops up in the <tt>Toy*</tt> classes and their associated

<p><span class="error">Unable to render embedded object: File (networking-classes-deleted.png)
not found.</span><br/>
<b>These are the classes that were either deleted or renamed.</b></p>

<p>The reason for my interest in this is that I am looking at harmonising the transport
mechanisms and introducing a mechanism to allow different transport layers (MINA, Java NIO,
Netty, and so forth) to be used independently of the protocol (0-8, 0-10, maybe even 1-0 eventually!)
or underlying transport mechanism (TCP, UDP, VM) and I keep discovering classes that appear
to do the same thing, but subtly different, or are just not used. I will probably be able
to use some of the logic from these classes but I see no benefit from introducing a 0-9 only
(apparently) transport layer that is completely untested.</p>

<p>Additionally, I have been looking at the <tt>ProtocolEngine</tt> interface,
and I discovered that the <tt>getWrittenBytes()</tt>/<tt>getReadBytes()</tt>
pair of methods that<br/>
are present there are not exposed through the MBean (although they are there, just commented
out) and where they are used, they are used incorrectly (both <tt>getWrittenBytes()</tt>
and <tt>getReadBytes()</tt> methods delegated to <tt>getWrittenBytes()</tt>.</p>

<p><span class="error">Unable to render embedded object: File (updated-networking-classes.png)
not found.</span><br/>
<b>This diagram shows the changes made to the Java classes involved in the Qpid networking

<h3><a name="QpidNetworkLayerUpdate2010-BrokerStartup"></a>Broker Startup</h3>

<p>The broker startup mechanism should be modified to allow use of a common network
transport layer, and be configurable either from the command-line or through system properties
set at a client when using the in-vm mechanism. The following classes would probably be required:</p>

Move <tt>startup()</tt> and <tt>shutdown()</tt> methods to the <tt>BrokerInstance</tt>
class, and build a <tt>BrokerOptions</tt> configuration from the command-line
options here. If<br/>
this class has to shut down the broker it started, it can safely call <tt>System.exit</tt>
if needed, as well, after telling the instance to shut down.</li>

This represents a broker instance that can be started and shut down (methods from <tt>Main</tt>
originally) where the startup method should take a <tt>BrokerOptions</tt> configuration
object. The instance would be created and methods called from <tt>Main</tt>, the
<tt>BrokerActivator</tt> or from a client wanting an in-vm broker. This class
should also contain instance fields that represent either the broker is embedded and contain
a copy of the OSGi context it is running in.</li>

The set of command-line options that are parsed out in the existing <tt>Main</tt>
(ports and protocol version exclusions and similar) should be stored in a separate object,
that can then be created independently for situations where broker startup does not happen
on the command-line.</li>

An OSGi activator that parses the configuration from a property file or similar to obtain
a <tt>BrokerOptions</tt> and uses that to call startup on a <tt>BrokerInstance</tt>.
Similarly, when the <tt>BrokerActivator</tt> shuts down, it should shut the <tt>BrokerInstance</tt>
down cleanly. This is distinct from the activator used by <em>Felix</em> when
starting up our embedded container, and this is where you can set the flag that would indicate
that the broker is embedded, so that the <tt>PluginManager</tt> knows <b>not</b>
to start a <em>Felix</em> OSGi container, but to use the existing OSGi context

A class used by a client <tt>vm://</tt> connection, that starts a <tt>BrokerInstance</tt>
instance in the same JVM. The <tt>BrokerOptions</tt> would be created using system
properties, or arguments passed using the broker connection URL.</li>

The <em>JUnit</em> test case that is used for system tests that start a broker.
This will now create a <tt>BrokerInstance</tt> and start it using a set of <tt>BrokerOption}}s
created from the test profile properties and other system properties, as appropriate in the
{{setUp()</tt> method, and shutting down the instance in the <tt>tearDown()</tt>

<h2><a name="QpidNetworkLayerUpdate2010-Workflow"></a>Workflow</h2>

<h3><a name="QpidNetworkLayerUpdate2010-Rationalise010TransportInterface"></a>Rationalise
0-10 Transport Interface</h3>

<p><a href="https://issues.apache.org/jira/browse/QPID-2811" class="external-link"
rel="nofollow">QPID-2811</a> <b>0.11</b> <em>In Progress</em></p>

<p>Create or modify current transport mechanism classes and interfaces to make them
more generic and allow for other mechanisms and protocols to be added in a modular way.</p>

<h3><a name="QpidNetworkLayerUpdate2010-Update010connectionconfigurationmechanismandproperties"></a>Update
0-10 connection configuration mechanism and properties</h3>

<p><a href="https://issues.apache.org/jira/browse/QPID-2812" class="external-link"
rel="nofollow">QPID-2812</a> <b>0.11</b> <em>In Progress</em></p>

<p>Update the 0-10 connection settings and system properties to rationalise the configuration
of the connection mechanism/transport/protocol. This may depend on how different transport
mechanisms are loaded, e.g. if we use OSGi plugins or not. It would be nice to make things
consistent across all protocols, so that broker addressing does not change. Note that some
transports may not support all types of broker addressing,and this has to fail gracefully.</p>

<p>This will also include removal of some classes and options, such as the <em>IoTransport</em>
configuration property. This property is present as an apparently untested 0-9 protocol <b>only</b>
option, and uses an entirely new mechanism to connect the transport layer to the MINA mechanism.
Since the intent of the preceding JIRA is to harmonise the transport layer interfaces between
protocols, I believe this is an unnecessary complication.</p>

<h3><a name="QpidNetworkLayerUpdate2010-Updatecurrent010socketconnectiontoconformtonewmechanism"></a>Update
current 0-10 socket connection to conform to new mechanism</h3>

<p><a href="https://issues.apache.org/jira/browse/QPID-2813" class="external-link"
rel="nofollow">QPID-2813</a> <b>0.11</b> <em>In Progress</em></p>

<p>Make any additional changes to the existing transport to allow it to conform fully
to the changes made in QPID-2811 and QPID-2812</p>

<h3><a name="QpidNetworkLayerUpdate2010-CreateTCPbased010MINAtransport"></a>Create
TCP based 0-10 MINA transport</h3>

<p><a href="https://issues.apache.org/jira/browse/QPID-2816" class="external-link"
rel="nofollow">QPID-2816</a> <b>0.11</b> <em>In Progress</em></p>

<p>Create a 0-10 MINA transport that implements the tcp:// protocol for broker communication</p>

<h3><a name="QpidNetworkLayerUpdate2010-CreateMINAInVM010Transport"></a>Create
MINA InVM 0-10 Transport</h3>

<p><a href="https://issues.apache.org/jira/browse/QPID-2814" class="external-link"
rel="nofollow">QPID-2814</a> <b>0.11</b> <em>In Progress</em></p>

<p>Create a MINA transport that implements the vm:// VmPipe protocol, to allow for in-vm
communication with the 0-10 protocol</p>

<h3><a name="QpidNetworkLayerUpdate2010-MakeInVMbrokerstartupprotocolindependent"></a>Make
InVM broker startup protocol independent</h3>

<p><a href="https://issues.apache.org/jira/browse/QPID-2815" class="external-link"
rel="nofollow">QPID-2815</a> <b>0.11</b> <em>In Progress</em></p>

<p>Update the way the in-vm broker is started to decouple it from any particular protocol

<h3><a name="QpidNetworkLayerUpdate2010-MakeTransportmechanismsintoOSGiplugins"></a>Make
Transport mechanisms into OSGi plugins</h3>

<p><a href="https://issues.apache.org/jira/browse/QPID-2818" class="external-link"
rel="nofollow">QPID-2818</a> <em>TODO</em></p>

<p>Make the transport mechanism pluggable using OSGi on both the broker and the client</p>

<h3><a name="QpidNetworkLayerUpdate2010-Addadditionalpluggabletransportmechanisms"></a>Add
additional pluggable transport mechanisms</h3>

<p><a href="https://issues.apache.org/jira/browse/QPID-2819" class="external-link"
rel="nofollow">QPID-2819</a> <em>TODO</em></p>

<p>Add additional transport mechanisms such as Netty or Grizzly</p>

    <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
       <a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Network+Layer+Update+2010">View
       <a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Network+Layer+Update+2010?showComments=true&amp;showCommentArea=true#addcomment">Add

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:commits-subscribe@qpid.apache.org

View raw message