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 Thu, 17 Mar 2011 15:12:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2036/9/21/_/styles/combined.css?spaceKey=qpid&amp;forWysiwyg=true"
type="text/css">
    </head>
<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>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~andrew.kennedy">Andrew
Kennedy</a>
    </h4>
        <div id="versionComment">
        <b>Comment:</b>
        add links to viewvc for review<br />
    </div>
        <br/>
                         <h4>Changes (2)</h4>
                                 
    
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
    
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >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 {{ApplicationRegistry}}
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 _VM_ 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 fixed. <br> <br></td></tr>
            <tr><td class="diff-changed-lines" >A [Presentation|^transport-layer.ppt]
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 <span class="diff-changed-words">release.<span
class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">.</span></span>
<br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h3.
Code Review <br> <br>Obviously a change like this needs to be reviewed carefully
before being committed to trunk. I have made several branches which are available to anyone
who wants to inspect the code in-progress, and a final review branch for what I expect to
be the code that gets merged back to trunk. I would like this update to be part of the *0.12*
release, and therefore I think it is important it becomes part of the *0.11* development stream
as soon as possible to enable comprehensive testing during development of the next release.
Also, once the Hudson CI environment (see [QPID-3149|https://issues.apache.org/jira/browse/QPID-3149]
for status) is available the testing will be more extensive and automated. <br> <br>*
[http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-20101013/qpid/java/] Initial branch
from 2010, now obsolete. <br> <br>* [http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-20110301/qpid/java/]
Most recent development branch, does not pass all tests and is missing some fixes that are
present in my development workspace. <br> <br>* [http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-review/qpid/java/]
Review code will be committed here, currently empty. This branch was made post the *0.10*
release branch, but any further changes still need to be merged from trunk before the code
is committed here. <br> <br>A _Review Board_ entry will also be created for discussion
of any changes needed before committing to trunk. <br> <br>* [https://reviews.apache.org/dashboard/]
<br> <br></td></tr>
            <tr><td class="diff-unchanged" >h2. Original Transport Code <br>
<br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <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
fixed.</p>

<p>A <a href="/confluence/download/attachments/25203508/transport-layer.ppt?version=1&amp;modificationDate=1299061992000">Presentation</a>
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>

<h3><a name="QpidNetworkLayerUpdate2010-CodeReview"></a>Code Review</h3>

<p>Obviously a change like this needs to be reviewed carefully before being committed
to trunk. I have made several branches which are available to anyone who wants to inspect
the code in-progress, and a final review branch for what I expect to be the code that gets
merged back to trunk. I would like this update to be part of the <b>0.12</b> release,
and therefore I think it is important it becomes part of the <b>0.11</b> development
stream as soon as possible to enable comprehensive testing during development of the next
release. Also, once the Hudson CI environment (see <a href="https://issues.apache.org/jira/browse/QPID-3149"
class="external-link" rel="nofollow">QPID-3149</a> for status) is available the testing
will be more extensive and automated.</p>

<ul>
	<li><a href="http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-20101013/qpid/java/"
class="external-link" rel="nofollow">http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-20101013/qpid/java/</a>
Initial branch from 2010, now obsolete.</li>
</ul>


<ul>
	<li><a href="http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-20110301/qpid/java/"
class="external-link" rel="nofollow">http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-20110301/qpid/java/</a>
Most recent development branch, does not pass all tests and is missing some fixes that are
present in my development workspace.</li>
</ul>


<ul>
	<li><a href="http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-review/qpid/java/"
class="external-link" rel="nofollow">http://svn.apache.org/viewvc/qpid/branches/grkvlt-network-review/qpid/java/</a>
Review code will be committed here, currently empty. This branch was made post the <b>0.10</b>
release branch, but any further changes still need to be merged from trunk before the code
is committed here.</li>
</ul>


<p>A <em>Review Board</em> entry will also be created for discussion of
any changes needed before committing to trunk.</p>

<ul>
	<li><a href="https://reviews.apache.org/dashboard/" class="external-link" rel="nofollow">https://reviews.apache.org/dashboard/</a></li>
</ul>


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

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

<ul>
	<li><tt>AMQConnectionDelegate_8_0#makeBrokerConnection(BrokerDetails)</tt>
	<ul>
		<li><tt>TransportConnection#getInstance(BrokerDetails)</tt></li>
		<li><tt>ITransportConnection#connect(AMQProtocolhandler, BrokerDetails)</tt>
		<ul>
			<li><tt>MinaNetworkDriver#open(...)</tt></li>
		</ul>
		</li>
	</ul>
	</li>
</ul>


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

<ul>
	<li><tt>AMQConnectionDelegate_0_10#makeBrokerConnection(BrokerDetails)</tt>
	<ul>
		<li><tt>Connection#connect(ConnectionSettings)</tt>
		<ul>
			<li><tt>TransportBuilder#init(Connection)</tt>
			<ul>
				<li><tt>Transport#getTransport()</tt></li>
				<li><tt>Transport#init(ConnectionSettings)</tt></li>
			</ul>
			</li>
			<li><tt>TransportBuilder#buildSenderPipe()</tt></li>
			<li><tt>TransportBuilder#buildReceiverPipe()</tt></li>
		</ul>
		</li>
	</ul>
	</li>
</ul>


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

<ul>
	<li><tt>Main#startup()</tt>
	<ul>
		<li><tt>MinaNetworkDriver#bind(...)</tt></li>
	</ul>
	</li>
</ul>


<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="image-wrap" style=""><img src="/confluence/download/attachments/25203508/qpid-transport.png?version=1&amp;modificationDate=1299061991000"
style="border: 0px solid black" /></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="image-wrap" style=""><img src="/confluence/download/attachments/25203508/networking-classes-orig.png?version=1&amp;modificationDate=1299061992000"
style="border: 0px solid black" /></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
class="code-keyword">false</span>"</span>))
   {
       TransportConnection.getInstance(brokerDetail).connect(_conn._protocolHandler, brokerDetail);
   }
   <span class="code-keyword">else</span>
   {
       _conn.getProtocolHandler().createIoTransportSession(brokerDetail);
   }
</pre>
</div></div>

<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
<tt>MinaHandler</tt>.</p>

<p><span class="image-wrap" style=""><a class="confluence-thumbnail-link 1317x555"
href='https://cwiki.apache.org/confluence/download/attachments/25203508/networking-classes-deleted.png'><img
src="/confluence/download/thumbnails/25203508/networking-classes-deleted.png" title="Deleted
networking classes" style="border: 0px solid black" /></a></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="image-wrap" style=""><img src="/confluence/download/attachments/25203508/updated-networking-classes.png?version=1&amp;modificationDate=1299061992000"
style="border: 0px solid black" /></span><br/>
<b>This diagram shows the changes made to the Java classes involved in the Qpid networking
layer.</b></p>

<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>

<ul>
	<li>BrokerInstance<br/>
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>
</ul>


<ul>
	<li>BrokerOptions<br/>
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>
</ul>


<ul>
	<li>Main<br/>
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>
</ul>


<ul>
	<li>BrokerActivator<br/>
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
instead.</li>
</ul>


<ul>
	<li>VmBroker<br/>
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>
</ul>


<ul>
	<li>QpidBrokerTestCase<br/>
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>
method.</li>
</ul>


<h3><a name="QpidNetworkLayerUpdate2010-TestProfiles"></a>Test Profiles</h3>

<p>Test profiles are created by adding a file named <tt><em>profile</em>.testprofile</tt>
to the <tt>qpid/java/test-profiles</tt> directory. This file is parsed as a series
of properties, adding to and overriding any set in the <tt>default.testprofile</tt>
file. The <em>default</em> test profile has now been deprecated, in favour of
using this file as simply a repository for the default values for test properties.</p>

<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Profile </th>
<th class='confluenceTh'> Broker Type </th>
<th class='confluenceTh'> Broker AMQP </th>
<th class='confluenceTh'> Client AMQP </th>
<th class='confluenceTh'> Notes </th>
</tr>
<tr>
<td class='confluenceTd'> <b>vm.0.10</b> </td>
<td class='confluenceTd'> <b>VM</b> </td>
<td class='confluenceTd'> <b>0-10</b> </td>
<td class='confluenceTd'> <b>0-10</b> </td>
<td class='confluenceTd'> Default profile </td>
</tr>
<tr>
<td class='confluenceTd'> vm.0.9.1 </td>
<td class='confluenceTd'> VM </td>
<td class='confluenceTd'> 0-9-1 </td>
<td class='confluenceTd'> 0-9-1 </td>
<td class='confluenceTd'>&nbsp;</td>
</tr>
<tr>
<td class='confluenceTd'> vm.0.9 </td>
<td class='confluenceTd'> VM </td>
<td class='confluenceTd'> 0-9 </td>
<td class='confluenceTd'> 0-9 </td>
<td class='confluenceTd'>&nbsp;</td>
</tr>
<tr>
<td class='confluenceTd'> vm.0.8 </td>
<td class='confluenceTd'> VM </td>
<td class='confluenceTd'> 0-8 </td>
<td class='confluenceTd'> 0-8 </td>
<td class='confluenceTd'>&nbsp;</td>
</tr>
<tr>
<td class='confluenceTd'> java.0.10 </td>
<td class='confluenceTd'> Java </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'>&nbsp;</td>
</tr>
<tr>
<td class='confluenceTd'> java.0.9.1 </td>
<td class='confluenceTd'> Java </td>
<td class='confluenceTd'> 0-9-1 </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'> Will negotiate AMQP version </td>
</tr>
<tr>
<td class='confluenceTd'> java.0.9 </td>
<td class='confluenceTd'> Java </td>
<td class='confluenceTd'> 0-9 </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'> Will negotiate AMQP version </td>
</tr>
<tr>
<td class='confluenceTd'> java.0.8 </td>
<td class='confluenceTd'> Java </td>
<td class='confluenceTd'> 0-8 </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'> Will negotiate AMQP version </td>
</tr>
<tr>
<td class='confluenceTd'> java-derby.0.10 </td>
<td class='confluenceTd'> Java </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'>&nbsp;</td>
</tr>
<tr>
<td class='confluenceTd'> java-derby.0.9.1 </td>
<td class='confluenceTd'> Java </td>
<td class='confluenceTd'> 0-9-1 </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'> Will negotiate AMQP version </td>
</tr>
<tr>
<td class='confluenceTd'> java-derby.0.9 </td>
<td class='confluenceTd'> Java </td>
<td class='confluenceTd'> 0-9 </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'> Will negotiate AMQP version </td>
</tr>
<tr>
<td class='confluenceTd'> java-derby.0.8 </td>
<td class='confluenceTd'> Java </td>
<td class='confluenceTd'> 0-8 </td>
<td class='confluenceTd'> 0-10 </td>
<td class='confluenceTd'> Will negotiate AMQP version </td>
</tr>
</tbody></table>
</div>


<h3><a name="QpidNetworkLayerUpdate2010-NetworkLayerResponsibilities"></a>Network
Layer Responsibilities</h3>

<p>The responsibilities for the network layer are split between four classes, which
are described below, along with the interfaces (if any) they must implement.</p>

<h4><a name="QpidNetworkLayerUpdate2010-%7B%7BNetworkTransport%7D%7D%2C%7B%7BIncomingNetworkTransport%7D%7Dand%7B%7BOutgoingNetworkTransport%7D%7D"></a><tt>NetworkTransport</tt>,
<tt>IncomingNetworkTransport</tt> and <tt>OutgoingNetworkTransport</tt></h4>

<p>This class represents the network transport mechanism and is used to make or receive
connections using that mechanism. It will create <tt>NetworkConnection</tt> objects
that represent an active connection using this mechanism.</p>

<ul>
	<li><em>close</em> - Close the transport and any associated <tt>NetworkConnection</tt>
objects.</li>
	<li><em>getAddress</em> Returns the address of the underlying socket that
is either listening or was connected to.</li>
	<li><em>isCompatible</em> Check whether the transport is compatible with
a network protocol.</li>
	<li><em>connect</em> Outgoing transport connection to a network address.</li>
	<li><em>accept</em> Incoming transport listening for connections on a network
address.</li>
</ul>


<h4><a name="QpidNetworkLayerUpdate2010-%7B%7BNetworkConnection%7D%7D"></a><tt>NetworkConnection</tt></h4>

<p>This is a representation of a network connection, and is responsible for creating
the <tt>Sender&lt;ByteBuffer&gt;</tt> implementation specific to the particular
network transport. It may also be responsible for the creation of the receiver or network
handler, or this may be left as the reposnsibility of the <em>connect</em> method
of the <tt>NetworkConnection</tt> in circumstances where both objects must be
created at the same time. It is, however, always responsible for closing both the sender and
receiver when it is closed.</p>

<ul>
	<li><em>getSender</em> Returns the <tt>Sender&lt;ByteBuffer&gt;</tt>
object that sends bytes to the network interface for this connection</li>
	<li><em>close</em> Clopses this connection and the associated receiver
and sender objects, as well as any other network resources, and stops threads it may own</li>
	<li><em>getReadBytes</em> Returns the number of bytes read over this connection</li>
	<li><em>getWrittenBytes</em> Returns the number of bytes written to this
connection</li>
	<li><em>getRemoteAddress</em> Returns the remote address of the underlying
socket.</li>
	<li><em>getLocalAddress</em> Returns the local address of the underlying
socket.</li>
</ul>


<h4><a name="QpidNetworkLayerUpdate2010-%7B%7BSender%3CByteBuffer%3E%7D%7D"></a><tt>Sender&lt;ByteBuffer&gt;</tt></h4>

<p>This class sends bytes to the network interface.</p>

<h4><a name="QpidNetworkLayerUpdate2010-NetworkHandler"></a>Network Handler</h4>

<p>This class receives bytes from the network interface and passes them on to a <tt>Receiver&lt;ByteBuffer</tt>
implementation that can handle and decode them. Also responsible for closing down the receiver
when the underlying network interface is closed, or signalling an exception to the receiver
when an error occurs.</p>


<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
version</p>

<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>

<h3><a name="QpidNetworkLayerUpdate2010-Make%7B%7BApplicationRegistry%7D%7DaSingleton"></a>Make
<tt>ApplicationRegistry</tt> a Singleton</h3>

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

<h3><a name="QpidNetworkLayerUpdate2010-JavatestprofilesdonoteffectivelytestallAMQPprotocolversions"></a>Java
test profiles do not effectively test all AMQP protocol versions</h3>

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

<p>Update the <tt>test-profiles</tt> contents with new profiles as described
above.</p>

<h3><a name="QpidNetworkLayerUpdate2010-Exclusivequeuesdonotrecordtheirowningsessionin010"></a>Exclusive
queues do not record their owning session in 0-10</h3>

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

<p>Exclusive queues do not record their owning session in 0-10</p>

<h3><a name="QpidNetworkLayerUpdate2010-Failovertestsdonotpasson010profiles"></a>Failover
tests do not pass on 0-10 profiles</h3>

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

<p>The failover mechanism is very tightly coupled to the 0-8 protocol classes, and many
tests using failover do not pass under 0-10.</p>
    </div>
        <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>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Network+Layer+Update+2010">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=25203508&revisedVersion=6&originalVersion=5">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Network+Layer+Update+2010?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

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


Mime
View raw message