qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrewinternatio...@gmail.com>
Subject Updating the 0-10 Java transport layer
Date Fri, 20 Aug 2010 09:45:05 GMT

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

See viewvc for when the change was made:


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>>
    ProtocolEngine_0_10 <<implements>> ProtocolEngine <<extends>>

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

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

View raw message