Qpid
  1. Qpid
  2. QPID-2811

Rationalise 0-10 Transport Interface

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 0.7
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

      1. transport-layer.ppt
        1.17 MB
        Andrew Kennedy

        Activity

        Hide
        Rajith Attapattu added a comment -

        Andrew,

        Could you please be more specific about your plans ?

        I have made some minor improvements to support (QPID-2447, QPID-2444, QPID-2445, QPID-2446, QPID-2447).
        In summary those changes are as follows,

        1. Allow the ability to load any transport that implements the NetworkTransport interface through reflection.
        This simply allows the transports to be moved outside of the client and common modules which is one of my goals.
        Look at Transport.java, NetworkTransport.java and IoNetworkTransport.java

        2. A helper class called SecurityLayer which wraps our senders and receivers with SSL and SASL if they have been configured by the user.

        3. TransportBuilder class to build the sender and receiver pipelines.

        I think what I have done is good enough as a starting point to move out the transport code into a separate module.
        I would be tempted to keep the IoTransport within the common module as it does not contain any external dependencies.

        And then move the MINA transport to a separate module and also add any new transports like Netty ..etc into that module.

        Show
        Rajith Attapattu added a comment - Andrew, Could you please be more specific about your plans ? I have made some minor improvements to support ( QPID-2447 , QPID-2444 , QPID-2445 , QPID-2446 , QPID-2447 ). In summary those changes are as follows, 1. Allow the ability to load any transport that implements the NetworkTransport interface through reflection. This simply allows the transports to be moved outside of the client and common modules which is one of my goals. Look at Transport.java, NetworkTransport.java and IoNetworkTransport.java 2. A helper class called SecurityLayer which wraps our senders and receivers with SSL and SASL if they have been configured by the user. 3. TransportBuilder class to build the sender and receiver pipelines. I think what I have done is good enough as a starting point to move out the transport code into a separate module. I would be tempted to keep the IoTransport within the common module as it does not contain any external dependencies. And then move the MINA transport to a separate module and also add any new transports like Netty ..etc into that module.
        Hide
        Andrew Kennedy added a comment - - edited

        This is pretty much what I'm doing, actually, although I would like to remove the reflection and use OSGi (on the broker) eventually. I am working on a more detailed piece of documentation, which I will upload asap. The IoTransport class doesn't seem useful to me, but I will be keeping IoNetworkTransport, with only a few changes.

        Show
        Andrew Kennedy added a comment - - edited This is pretty much what I'm doing, actually, although I would like to remove the reflection and use OSGi (on the broker) eventually. I am working on a more detailed piece of documentation, which I will upload asap. The IoTransport class doesn't seem useful to me, but I will be keeping IoNetworkTransport, with only a few changes.
        Hide
        Rajith Attapattu added a comment -

        -1 on removing the ability to load a transport via reflection as it allows a simple and effective way of loading a transport without the need for things like OSGi.
        As mentioned before I am not opposed to you making the transports loaded via OSGi as long as no deps are introduced in the client and common modules.
        I think it's possible all though it may need some careful thinking. If needed I am quite happy to work with you to achieve it.

        Show
        Rajith Attapattu added a comment - -1 on removing the ability to load a transport via reflection as it allows a simple and effective way of loading a transport without the need for things like OSGi. As mentioned before I am not opposed to you making the transports loaded via OSGi as long as no deps are introduced in the client and common modules. I think it's possible all though it may need some careful thinking. If needed I am quite happy to work with you to achieve it.
        Hide
        Rajith Attapattu added a comment -

        The IoTransport class is not used in the new mechanism. I did not remove it as it seems the 0-8/0-9 client was dependent on it.
        So I'd left it as it is.

        I also see that you have edited your comment. I misunderstood the previous comment as you suggesting to remove the reflection based method for the client as well.
        My -1 for OSGi only applies to the client and that too only if deps are introduced into client and common modules.

        Keep us posted, happy to help when ever I can.

        Show
        Rajith Attapattu added a comment - The IoTransport class is not used in the new mechanism. I did not remove it as it seems the 0-8/0-9 client was dependent on it. So I'd left it as it is. I also see that you have edited your comment. I misunderstood the previous comment as you suggesting to remove the reflection based method for the client as well. My -1 for OSGi only applies to the client and that too only if deps are introduced into client and common modules. Keep us posted, happy to help when ever I can.
        Hide
        Andrew Kennedy added a comment -

        Created a branch from TRUNK with the transport mechanism/layer changes and improved broker startup for QPID-2720.

        https://svn.apache.org/repos/asf/qpid/branches/grkvlt-network-20101013

        This branch also contains the transaction idle timeout code for QPID-2864 and has a lot of dead code pruning, such as getting rid of duplicated concurrency classes and unwanted IO layer experimentation, moving of CLI tools, and makes all tests inherit from QpidBrokerTestCase, some locking has been updated. The broker has the capability to run in the same JVM as its clients (although only one broker at a time can exist) using the 'vm://' protocol, and can listen on many ports simultaneously for different AMQP versions, as with TCP. UDP is also supported, as is separate configuration of incoming and outgoing network transports, with hooks to allow future ODGi support on both client and broker. MINA has been upgraded to version 1.1.17 and backport-utl removed, and the release currently defaults to using MINA in the client, but this could be changed easily.

        There are also many other small and incidental changes, not all of which should or will be merged back to TRUNK, however any that are will be assigned JIRAs.

        New test profiles: default.0.8, default.0.10, java-udp and java-udp.0.10

        Test failures are still occuring, particularly with UDP and InVM 0-10 profiles.

        Show
        Andrew Kennedy added a comment - Created a branch from TRUNK with the transport mechanism/layer changes and improved broker startup for QPID-2720 . https://svn.apache.org/repos/asf/qpid/branches/grkvlt-network-20101013 This branch also contains the transaction idle timeout code for QPID-2864 and has a lot of dead code pruning, such as getting rid of duplicated concurrency classes and unwanted IO layer experimentation, moving of CLI tools, and makes all tests inherit from QpidBrokerTestCase, some locking has been updated. The broker has the capability to run in the same JVM as its clients (although only one broker at a time can exist) using the 'vm://' protocol, and can listen on many ports simultaneously for different AMQP versions, as with TCP. UDP is also supported, as is separate configuration of incoming and outgoing network transports, with hooks to allow future ODGi support on both client and broker. MINA has been upgraded to version 1.1.17 and backport-utl removed, and the release currently defaults to using MINA in the client, but this could be changed easily. There are also many other small and incidental changes, not all of which should or will be merged back to TRUNK, however any that are will be assigned JIRAs. New test profiles: default.0.8, default.0.10, java-udp and java-udp.0.10 Test failures are still occuring, particularly with UDP and InVM 0-10 profiles.
        Hide
        Andrew Kennedy added a comment -

        Presentation describing rationale and progress with transport layer changes

        Show
        Andrew Kennedy added a comment - Presentation describing rationale and progress with transport layer changes
        Hide
        Andrew Kennedy added a comment -

        Move forward to 0.9

        Show
        Andrew Kennedy added a comment - Move forward to 0.9
        Hide
        Robbie Gemmell added a comment -

        Closing out, work being undertaken via a new JIRA.

        Show
        Robbie Gemmell added a comment - Closing out, work being undertaken via a new JIRA.

          People

          • Assignee:
            Andrew Kennedy
            Reporter:
            Andrew Kennedy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development