You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Andrew Kennedy <an...@gmail.com> on 2010/08/20 11:45:05 UTC
Updating the 0-10 Java transport layer
Hi.
I'm currently looking at the 0-10 transport layer in more detail, and
want to add a (currently) MINA based VM mechanism to the existing
socket based one, and eventually I envisage pluggable OSGi modules
that implement Netty or Grizzly transports for both the client and the
broker, using any AMQP protocol.
Anyway, I came across the following snippet in
AMQConnectionDelegate_8_0#makeBrokerConnection and wondered what the
"UseTransportIo" property was for:
// TODO: use system property thingy for this
if (System.getProperty("UseTransportIo", "false").equals("false"))
{
TransportConnection.getInstance(brokerDetail).connect(_conn._protocolHandler,
brokerDetail);
}
else
{
_conn.getProtocolHandler().createIoTransportSession(brokerDetail);
}
See viewvc for when the change was made:
http://svn.apache.org/viewvc?view=revision&revision=684016
As far as I can tell, the code that would be called if this property
is set (for instance IoTransport.connect_0_9() and some associated
classes that seem to be 0-9 specific) is not tested, *or* 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 Binding<X,Y> object, which
also crops up in the Toy* classes and their associated MinaHandler
that I mentioned in a previous message. 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 independantly 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.
Additionally, I have been looking at the ProtocolEngine class, and I
discovered that the getWrittedBytes/getReadBytes pair of methods that
are present there are not exposed through the MBean (although they are
commented out) - I think that the ProtocolEngine class could be
removed entirely, and its usage replaced with Receiver<ByteBuffer> in
all cases, and the extra methods can be added to a network transport
interface instead. I also found what I consider pointless redundancy
around thois class, where the following relationships hold:
ProtocolEngine_0_10 <<extends>> InputHandler <<implements>>
Receiver<ByteBuffer>
ProtocolEngine_0_10 <<implements>> ProtocolEngine <<extends>>
Receiver<ByteBuffer>
The relevant JIRA for most of this is QPID-2812
[https://issues.apache.org/jira/browse/QPID-2812] although see also
QPID-2811, QPID-2813, QPID-2814, QPID-2815, QPID-2816, and, eventually
QPID-2818 and QPID-2819. If anyone has any questions about what I'm
trying to achieve here, I can try and explain a bit more, and I'd
appreciate any comments or feedback...
Thanks,
Andrew.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Rajith Attapattu <ra...@gmail.com>.
Let me read through and comment on the individual JIRA's and then
maybe I can post a summary of my views here.
Rajith
On Fri, Aug 20, 2010 at 9:48 AM, Carl Trieloff <cc...@redhat.com> wrote:
>
> I still think it needs debate,
>
> For example, the discussion has been put forward to add in the new API
> model in Java between JMS and the transports. This is needed. How does
> that relate to this?
>
> This discussing needs to be had a bit more broadly so that all involved in
> the client can contribute / agree.
>
> I would like to see agreement between Rob, Rafi, Rajith, & Andrew for
> example
> on this topic.
>
> (unless it has happened and I missed it, if I see acks then I'll be happy)
> Carl.
>
>
>
> On 08/20/2010 09:09 AM, Sorin S. wrote:
>>
>> Hi,
>> My understanding is that Andrew is trying to make the I/O layer more
>> generic in the first instance and rationalize the
>> path from the wire to the protocol specific code in the same way for
>> all the available versions of amqp.
>> As soon as that is done, we can swap out Mina from both sides should
>> other frameworks be better suitable for Qpid and
>> also handle the future versions in a unified manner.
>>
>> Cheers,
>>
>> Sorin
>>
>>
>> On Fri, Aug 20, 2010 at 1:47 PM, Carl Trieloff<cc...@redhat.com>
>> wrote:
>>
>>>
>>> On 08/20/2010 05:45 AM, Andrew Kennedy wrote:
>>>
>>>>
>>>> Hi.
>>>>
>>>> I'm currently looking at the 0-10 transport layer in more detail, and
>>>> want to add a (currently) MINA based VM mechanism to the existing
>>>> socket based one, and eventually I envisage pluggable OSGi modules
>>>> that implement Netty or Grizzly transports for both the client and the
>>>> broker, using any AMQP protocol.
>>>>
>>>>
>>>
>>> My understanding we where trying to get rid of MINA in the Java client,
>>> this implies going the other way. I believe this need to be debated, as I
>>> think we want to get rid of the mina dependency which is preventing
>>> some of the needed JMS cleanup. Rob, Rafi, Rajith... please comment...
>>>
>>> Carl.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Bryan Kearney <bk...@redhat.com>.
On 08/20/2010 11:04 AM, Carl Trieloff wrote:
> On 08/20/2010 10:15 AM, Robert Godfrey wrote:
>> On 20 August 2010 15:48, Carl Trieloff<cc...@redhat.com> wrote:
>>> I still think it needs debate,
>>>
>>> For example, the discussion has been put forward to add in the new API
>>> model in Java between JMS and the transports. This is needed. How does
>>> that relate to this?
>>>
>>> This discussing needs to be had a bit more broadly so that all
>>> involved in
>>> the client can contribute / agree.
>>>
>>> I would like to see agreement between Rob, Rafi, Rajith,& Andrew for
>>> example
>>> on this topic.
>>>
>>> (unless it has happened and I missed it, if I see acks then I'll be
>>> happy)
>>> Carl.
>>>
>>>
>> I want to see the proposal from Andrew before commenting in detail,
>> but in general this is going on at a lower layer than the API stuff...
>> here we're considering the interface down to the IO layer. At the
>> moment this is a bit (no, a *lot*) of a mess, and is completely
>> different on the 0-10 codepath and the 0-8/0-9/0-9-1 codepath.
>> There's no real reason for the interface down to the transport from
>> the different protocol stacks to be different. What I understand
>> Andrew to be doing is tidying up where Aidan left off in removing
>> dependencies on particular implementations of an IO layer (e.g. MINA)
>> from the code, and providing a single interface that can be used by
>> the current (and future) protocol versions. As part of this I believe
>> he'll be encapsulating the current MINA code behind the interface so
>> that it is exposed in a similar way to the IoTransport that was
>> written as part of the 0-10 work.
>>
>> The initial driver for this work is to allow for the running of "InVM"
>> tests on the 0-10 codepath in the same way as they are run for 0-8,
>> 0-9 and 0-9-1 currently. getting these tests running again needs to
>> be a priority for us in terms of proving the Java Broker for 0-10.
>>
>> The work is really orthogonal to work on adding the new API to the
>> Java client and then writing a JMS client library on top of that API.
>> While I agree that such an approach could greatly simplify the client
>> - it would involve a major re-write which we would definitely want to
>> discuss and plan in advance.
>>
>> I don't think there is any real risk involved in the work Andrew is
>> discussing, and it will bring significant benefits in terms of
>> allowing us to use alternative IO layers, and unifying the interface
>> used underneath 0-10 and the other versions of the protocol.
>>
>>
>
> That helps set the context for me -- let's get input from Rafi and
> Rajith, and
> if we are in agreement then that is great.
>
> Carl.
If I read this as a non JMA api layer... that would be nice.
-- bk
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Carl Trieloff <cc...@redhat.com>.
On 08/20/2010 10:15 AM, Robert Godfrey wrote:
> On 20 August 2010 15:48, Carl Trieloff<cc...@redhat.com> wrote:
>
>> I still think it needs debate,
>>
>> For example, the discussion has been put forward to add in the new API
>> model in Java between JMS and the transports. This is needed. How does
>> that relate to this?
>>
>> This discussing needs to be had a bit more broadly so that all involved in
>> the client can contribute / agree.
>>
>> I would like to see agreement between Rob, Rafi, Rajith,& Andrew for
>> example
>> on this topic.
>>
>> (unless it has happened and I missed it, if I see acks then I'll be happy)
>> Carl.
>>
>>
>>
> I want to see the proposal from Andrew before commenting in detail,
> but in general this is going on at a lower layer than the API stuff...
> here we're considering the interface down to the IO layer. At the
> moment this is a bit (no, a *lot*) of a mess, and is completely
> different on the 0-10 codepath and the 0-8/0-9/0-9-1 codepath.
> There's no real reason for the interface down to the transport from
> the different protocol stacks to be different. What I understand
> Andrew to be doing is tidying up where Aidan left off in removing
> dependencies on particular implementations of an IO layer (e.g. MINA)
> from the code, and providing a single interface that can be used by
> the current (and future) protocol versions. As part of this I believe
> he'll be encapsulating the current MINA code behind the interface so
> that it is exposed in a similar way to the IoTransport that was
> written as part of the 0-10 work.
>
> The initial driver for this work is to allow for the running of "InVM"
> tests on the 0-10 codepath in the same way as they are run for 0-8,
> 0-9 and 0-9-1 currently. getting these tests running again needs to
> be a priority for us in terms of proving the Java Broker for 0-10.
>
> The work is really orthogonal to work on adding the new API to the
> Java client and then writing a JMS client library on top of that API.
> While I agree that such an approach could greatly simplify the client
> - it would involve a major re-write which we would definitely want to
> discuss and plan in advance.
>
> I don't think there is any real risk involved in the work Andrew is
> discussing, and it will bring significant benefits in terms of
> allowing us to use alternative IO layers, and unifying the interface
> used underneath 0-10 and the other versions of the protocol.
>
>
>
That helps set the context for me -- let's get input from Rafi and
Rajith, and
if we are in agreement then that is great.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Andrew Kennedy <an...@gmail.com>.
Also,
I should point out that the JIRA that mentions OSGi is purely in a
'Nice to have' category, and isn't something I expect to be working on
at any time in the near future... The important part of this is
consolidating and improving the transport layer. I expect that the
ability to add an OSGi module containg a Netty transport would be
something that would be useful, on the broker, certainly, and anyone
interested in a performant client should be able to swap in the same
implementation, using the class.forName mechanism already described by
Rajith.
Andrew.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> On 20 August 2010 15:48, Carl Trieloff <cc...@redhat.com> wrote:
>> I still think it needs debate,
>>
>> For example, the discussion has been put forward to add in the new API
>> model in Java between JMS and the transports. This is needed. How does
>> that relate to this?
>>
>> This discussing needs to be had a bit more broadly so that all involved in
>> the client can contribute / agree.
>>
>> I would like to see agreement between Rob, Rafi, Rajith, & Andrew for
>> example
>> on this topic.
>>
>> (unless it has happened and I missed it, if I see acks then I'll be happy)
>> Carl.
>>
>>
>
> I want to see the proposal from Andrew before commenting in detail,
> but in general this is going on at a lower layer than the API stuff...
> here we're considering the interface down to the IO layer. At the
> moment this is a bit (no, a *lot*) of a mess, and is completely
> different on the 0-10 codepath and the 0-8/0-9/0-9-1 codepath.
> There's no real reason for the interface down to the transport from
> the different protocol stacks to be different. What I understand
> Andrew to be doing is tidying up where Aidan left off in removing
> dependencies on particular implementations of an IO layer (e.g. MINA)
> from the code, and providing a single interface that can be used by
> the current (and future) protocol versions. As part of this I believe
> he'll be encapsulating the current MINA code behind the interface so
> that it is exposed in a similar way to the IoTransport that was
> written as part of the 0-10 work.
>
> The initial driver for this work is to allow for the running of "InVM"
> tests on the 0-10 codepath in the same way as they are run for 0-8,
> 0-9 and 0-9-1 currently. getting these tests running again needs to
> be a priority for us in terms of proving the Java Broker for 0-10.
>
> The work is really orthogonal to work on adding the new API to the
> Java client and then writing a JMS client library on top of that API.
> While I agree that such an approach could greatly simplify the client
> - it would involve a major re-write which we would definitely want to
> discuss and plan in advance.
>
> I don't think there is any real risk involved in the work Andrew is
> discussing, and it will bring significant benefits in terms of
> allowing us to use alternative IO layers, and unifying the interface
> used underneath 0-10 and the other versions of the protocol.
I agree this is pretty orthogonal to any higher level client refactor,
and getting a common transport interface for 0-8/9/10 makes sense as an
incremental step.
My one reservation is about the OSGi aspect. As a general principal I
would like to keep to an absolute minimum to the dependencies necessary
to run/embed the Java client (or any other clients for that matter). I'd
be interested to hear more about how OSGi is being used, what the
benefit is, and what implications that has for the footprint and
dependencies of the client.
I haven't actually read through the JIRAs yet, so if this is discussed
there already then please just tell me to RTFJ.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Aug 20, 2010 at 11:37 AM, Andrew Kennedy
<an...@gmail.com> wrote:
> On 20 August 2010 16:16, Rajith Attapattu <ra...@gmail.com> wrote:
>> I would like to see the following in any future work carried out in the area.
>>
>> 1. Move the additional transport code out of common module. This is a
>> very important requirement for me as I would like to get rid of the
>> MINA dependencies.
>> My goal is to make the clients as light weight as possible with
>> minimum dependencies in both runtime and compile time.
>
> +1 Although I'm not sure we yet have a good way of managing external
> modules that have dependencies. I am still thinking about the best way
> to do this.
>
>> 2. Preserve the ability to load any transport via reflection.
>
> +1 On the client, I don't intend to remove this. At first I thought
> about doing a similar thing to the broker with OSGi, but I don't think
> this is really feasible yet. The reflection mechanism (class.forName()
> basically) would still be used, with a system property to decide what
> transport to be used, and the external module supplied on the
> classpath as a .jar file.
>
>> 3. Not introduce any dependencies into client or common modules. I
>> mentioned this specifically as QPID-2818 mentions about OSGi-fication
>> of the transports on the client side.
>> This is a big -1 from me, unless this can be achieved via a
>> separate module without introducing any dependencies into the client
>> and common modules.
>
> Heh, see my quick edit - i realised this might be misconstrued as soon
> as I hit submit on the comment, so I edited it to add '(on the
> broker)' which I hoped would make things clearer...
>
>> In general I am +1 on making the code simple and easy understand.
>> I am -1 on making it any more complicated with features that are nice
>> to have than must have.
>
> Agreed, and I will straighten out the documentation I'm working on and
> add the relevant parts to some of the JIRAs so people have a better
> idea what I'm trying to accomplish, but I believe we're on the same
> page here...
Indeed we are.
Thank you sir for your explanation.
Looking forward to the doc and will pitch in as time permits.
Rajith
> Andrew.
> --
> -- andrew d kennedy ? edinburgh : +44 7941 197 134 ;
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Andrew Kennedy <an...@gmail.com>.
On 20 August 2010 16:16, Rajith Attapattu <ra...@gmail.com> wrote:
> I would like to see the following in any future work carried out in the area.
>
> 1. Move the additional transport code out of common module. This is a
> very important requirement for me as I would like to get rid of the
> MINA dependencies.
> My goal is to make the clients as light weight as possible with
> minimum dependencies in both runtime and compile time.
+1 Although I'm not sure we yet have a good way of managing external
modules that have dependencies. I am still thinking about the best way
to do this.
> 2. Preserve the ability to load any transport via reflection.
+1 On the client, I don't intend to remove this. At first I thought
about doing a similar thing to the broker with OSGi, but I don't think
this is really feasible yet. The reflection mechanism (class.forName()
basically) would still be used, with a system property to decide what
transport to be used, and the external module supplied on the
classpath as a .jar file.
> 3. Not introduce any dependencies into client or common modules. I
> mentioned this specifically as QPID-2818 mentions about OSGi-fication
> of the transports on the client side.
> This is a big -1 from me, unless this can be achieved via a
> separate module without introducing any dependencies into the client
> and common modules.
Heh, see my quick edit - i realised this might be misconstrued as soon
as I hit submit on the comment, so I edited it to add '(on the
broker)' which I hoped would make things clearer...
> In general I am +1 on making the code simple and easy understand.
> I am -1 on making it any more complicated with features that are nice
> to have than must have.
Agreed, and I will straighten out the documentation I'm working on and
add the relevant parts to some of the JIRAs so people have a better
idea what I'm trying to accomplish, but I believe we're on the same
page here...
Andrew.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Rajith Attapattu <ra...@gmail.com>.
First of all, I appreciate that there are several JIRA's opened
identifying the areas that Andrew is hoping to work.
I have gone through the JIRA's and made some comments.
In general I am quite happy about getting the transport code sorted out.
As mentioned in QPID-2811, I have made some improvements to cleanup
the Transport code in the 0-10 path.
Chief among them is the ability to load any transport via reflection
using some simple interfaces and a simple Builder class to construct
our sender and receiver pipes.
I would like to see the following in any future work carried out in the area.
1. Move the additional transport code out of common module. This is a
very important requirement for me as I would like to get rid of the
MINA dependencies.
My goal is to make the clients as light weight as possible with
minimum dependencies in both runtime and compile time.
2. Preserve the ability to load any transport via reflection.
3. Not introduce any dependencies into client or common modules. I
mentioned this specifically as QPID-2818 mentions about OSGi-fication
of the transports on the client side.
This is a big -1 from me, unless this can be achieved via a
separate module without introducing any dependencies into the client
and common modules.
In general I am +1 on making the code simple and easy understand.
I am -1 on making it any more complicated with features that are nice
to have than must have.
Regards,
Rajith
On Fri, Aug 20, 2010 at 10:15 AM, Robert Godfrey
<ro...@gmail.com> wrote:
> On 20 August 2010 15:48, Carl Trieloff <cc...@redhat.com> wrote:
>>
>> I still think it needs debate,
>>
>> For example, the discussion has been put forward to add in the new API
>> model in Java between JMS and the transports. This is needed. How does
>> that relate to this?
>>
>> This discussing needs to be had a bit more broadly so that all involved in
>> the client can contribute / agree.
>>
>> I would like to see agreement between Rob, Rafi, Rajith, & Andrew for
>> example
>> on this topic.
>>
>> (unless it has happened and I missed it, if I see acks then I'll be happy)
>> Carl.
>>
>>
>
> I want to see the proposal from Andrew before commenting in detail,
> but in general this is going on at a lower layer than the API stuff...
> here we're considering the interface down to the IO layer. At the
> moment this is a bit (no, a *lot*) of a mess, and is completely
> different on the 0-10 codepath and the 0-8/0-9/0-9-1 codepath.
> There's no real reason for the interface down to the transport from
> the different protocol stacks to be different. What I understand
> Andrew to be doing is tidying up where Aidan left off in removing
> dependencies on particular implementations of an IO layer (e.g. MINA)
> from the code, and providing a single interface that can be used by
> the current (and future) protocol versions. As part of this I believe
> he'll be encapsulating the current MINA code behind the interface so
> that it is exposed in a similar way to the IoTransport that was
> written as part of the 0-10 work.
>
> The initial driver for this work is to allow for the running of "InVM"
> tests on the 0-10 codepath in the same way as they are run for 0-8,
> 0-9 and 0-9-1 currently. getting these tests running again needs to
> be a priority for us in terms of proving the Java Broker for 0-10.
>
> The work is really orthogonal to work on adding the new API to the
> Java client and then writing a JMS client library on top of that API.
> While I agree that such an approach could greatly simplify the client
> - it would involve a major re-write which we would definitely want to
> discuss and plan in advance.
>
> I don't think there is any real risk involved in the work Andrew is
> discussing, and it will bring significant benefits in terms of
> allowing us to use alternative IO layers, and unifying the interface
> used underneath 0-10 and the other versions of the protocol.
>
> -- Rob
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Robert Godfrey <ro...@gmail.com>.
On 20 August 2010 15:48, Carl Trieloff <cc...@redhat.com> wrote:
>
> I still think it needs debate,
>
> For example, the discussion has been put forward to add in the new API
> model in Java between JMS and the transports. This is needed. How does
> that relate to this?
>
> This discussing needs to be had a bit more broadly so that all involved in
> the client can contribute / agree.
>
> I would like to see agreement between Rob, Rafi, Rajith, & Andrew for
> example
> on this topic.
>
> (unless it has happened and I missed it, if I see acks then I'll be happy)
> Carl.
>
>
I want to see the proposal from Andrew before commenting in detail,
but in general this is going on at a lower layer than the API stuff...
here we're considering the interface down to the IO layer. At the
moment this is a bit (no, a *lot*) of a mess, and is completely
different on the 0-10 codepath and the 0-8/0-9/0-9-1 codepath.
There's no real reason for the interface down to the transport from
the different protocol stacks to be different. What I understand
Andrew to be doing is tidying up where Aidan left off in removing
dependencies on particular implementations of an IO layer (e.g. MINA)
from the code, and providing a single interface that can be used by
the current (and future) protocol versions. As part of this I believe
he'll be encapsulating the current MINA code behind the interface so
that it is exposed in a similar way to the IoTransport that was
written as part of the 0-10 work.
The initial driver for this work is to allow for the running of "InVM"
tests on the 0-10 codepath in the same way as they are run for 0-8,
0-9 and 0-9-1 currently. getting these tests running again needs to
be a priority for us in terms of proving the Java Broker for 0-10.
The work is really orthogonal to work on adding the new API to the
Java client and then writing a JMS client library on top of that API.
While I agree that such an approach could greatly simplify the client
- it would involve a major re-write which we would definitely want to
discuss and plan in advance.
I don't think there is any real risk involved in the work Andrew is
discussing, and it will bring significant benefits in terms of
allowing us to use alternative IO layers, and unifying the interface
used underneath 0-10 and the other versions of the protocol.
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Carl Trieloff <cc...@redhat.com>.
I still think it needs debate,
For example, the discussion has been put forward to add in the new API
model in Java between JMS and the transports. This is needed. How does
that relate to this?
This discussing needs to be had a bit more broadly so that all involved in
the client can contribute / agree.
I would like to see agreement between Rob, Rafi, Rajith, & Andrew for
example
on this topic.
(unless it has happened and I missed it, if I see acks then I'll be happy)
Carl.
On 08/20/2010 09:09 AM, Sorin S. wrote:
> Hi,
> My understanding is that Andrew is trying to make the I/O layer more
> generic in the first instance and rationalize the
> path from the wire to the protocol specific code in the same way for
> all the available versions of amqp.
> As soon as that is done, we can swap out Mina from both sides should
> other frameworks be better suitable for Qpid and
> also handle the future versions in a unified manner.
>
> Cheers,
>
> Sorin
>
>
> On Fri, Aug 20, 2010 at 1:47 PM, Carl Trieloff<cc...@redhat.com> wrote:
>
>> On 08/20/2010 05:45 AM, Andrew Kennedy wrote:
>>
>>> Hi.
>>>
>>> I'm currently looking at the 0-10 transport layer in more detail, and
>>> want to add a (currently) MINA based VM mechanism to the existing
>>> socket based one, and eventually I envisage pluggable OSGi modules
>>> that implement Netty or Grizzly transports for both the client and the
>>> broker, using any AMQP protocol.
>>>
>>>
>> My understanding we where trying to get rid of MINA in the Java client,
>> this implies going the other way. I believe this need to be debated, as I
>> think we want to get rid of the mina dependency which is preventing
>> some of the needed JMS cleanup. Rob, Rafi, Rajith... please comment...
>>
>> Carl.
>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by "Sorin S." <ss...@gmail.com>.
Hi,
My understanding is that Andrew is trying to make the I/O layer more
generic in the first instance and rationalize the
path from the wire to the protocol specific code in the same way for
all the available versions of amqp.
As soon as that is done, we can swap out Mina from both sides should
other frameworks be better suitable for Qpid and
also handle the future versions in a unified manner.
Cheers,
Sorin
On Fri, Aug 20, 2010 at 1:47 PM, Carl Trieloff <cc...@redhat.com> wrote:
> On 08/20/2010 05:45 AM, Andrew Kennedy wrote:
>>
>> Hi.
>>
>> I'm currently looking at the 0-10 transport layer in more detail, and
>> want to add a (currently) MINA based VM mechanism to the existing
>> socket based one, and eventually I envisage pluggable OSGi modules
>> that implement Netty or Grizzly transports for both the client and the
>> broker, using any AMQP protocol.
>>
>
> My understanding we where trying to get rid of MINA in the Java client,
> this implies going the other way. I believe this need to be debated, as I
> think we want to get rid of the mina dependency which is preventing
> some of the needed JMS cleanup. Rob, Rafi, Rajith... please comment...
>
> Carl.
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Updating the 0-10 Java transport layer
Posted by Carl Trieloff <cc...@redhat.com>.
On 08/20/2010 05:45 AM, Andrew Kennedy wrote:
> Hi.
>
> I'm currently looking at the 0-10 transport layer in more detail, and
> want to add a (currently) MINA based VM mechanism to the existing
> socket based one, and eventually I envisage pluggable OSGi modules
> that implement Netty or Grizzly transports for both the client and the
> broker, using any AMQP protocol.
>
My understanding we where trying to get rid of MINA in the Java client,
this implies going the other way. I believe this need to be debated, as I
think we want to get rid of the mina dependency which is preventing
some of the needed JMS cleanup. Rob, Rafi, Rajith... please comment...
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org