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, 09 Mar 2011 03:46: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>
        <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" >| java-derby.0.8 | Java | 0-8 | 0-10
| Will negotiate AMQP version | <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h3.
Network Layer Responsibilities <br></td></tr>
            <tr><td class="diff-unchanged" > <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">The
responsibilities for the network layer are split between four classes, which are described
below, along with the interfaces (if any) they must implement. <br> <br>h4. {{NetworkTransport}},
{{IncomingNetworkTransport}} and {{OutgoingNetworkTransport}} <br> <br>This class
represents the network transport mechanism and is used to make or receive connections using
that mechanism. It will create {{NetworkConnection}} objects that represent an active connection
using this mechanism. <br> <br>* _close_ - Close the transport and any associated
{{NetworkConnection}} objects. <br>* _getAddress_ Returns the address of the underlying
socket that is either listening or was connected to. <br>* _isCompatible_ Check whether
the transport is compatible with a network protocol. <br>* _connect_ Outgoing transport
connection to a network address. <br>* _accept_ Incoming transport listening for connections
on a network address. <br> <br>h4. {{NetworkConnection}} <br> <br>This
is a representation of a network connection, and is responsible for creating the {{Sender&lt;ByteBuffer&gt;}}
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 _connect_ method of the {{NetworkConnection}} 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. <br> <br>* _getSender_ Returns the {{Sender&lt;ByteBuffer&gt;}}
object that sends bytes to the network interface for this connection <br>* _close_ Clopses
this connection and the associated receiver and sender objects, as well as any other network
resources, and stops threads it may own <br>* _getReadBytes_ Returns the number of bytes
read over this connection <br>* _getWrittenBytes_ Returns the number of bytes written
to this connection <br>* _getRemoteAddress_ Returns the remote address of the underlying
socket. <br>* _getLocalAddress_ Returns the local address of the underlying socket.
<br> <br>h4. {{Sender&lt;ByteBuffer&gt;}} <br> <br>This class
sends bytes to the network interface. <br> <br>h4. Network Handler <br>
<br>This class receives bytes from the network interface and passes them on to a {{Receiver&lt;ByteBuffer}}
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. <br> <br> <br></td></tr>
            <tr><td class="diff-unchanged" >h2. Workflow <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>

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

<p>There can only be a singlr instance of the <tt>ApplicationRegistry</tt>
in a particular JVM</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=4&originalVersion=3">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