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-subscr...@qpid.apache.org
