Qpid
  1. Qpid
  2. QPID-1831

Improve JMS Destination abstraction to better support AMQP and Qpid specific features

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.7
    • Component/s: Java Client
    • Labels:
      None

      Description

      Qpid users have requested the following features in JIRAs/emails to the user list.

      1. Ability to specify Qpid specific queue declare arguments like qpid.max-size
      2. Support for any exchange type ..eg Headers, XML exchange
      3. Ability to specify binding arguments (needed for headers, xml exchanges)
      4. Ability to support destination specific parameters like msg-credits, byte-credits, sync-ack, sync-publish ..etc
      5. Ability bind a queue to multiple exchange/routingkey pairs
      6. Have the option of producer side declaring/binding the queue.

      The following proposal outlines a solution to the above mentioned requirements.
      http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS+Destination+configuration

      1. QPID-1831.patch
        35 kB
        Rajith Attapattu
      2. AMQXDest.patch
        44 kB
        Rajith Attapattu

        Activity

        Hide
        Rajith Attapattu added a comment -
        Show
        Rajith Attapattu added a comment - The following code patch implements the proposal outlined in http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS+Destination+configuration
        Hide
        Marnie McCormack added a comment -

        Moving items unlikely to be completed for 0.6 out to 0.7

        Show
        Marnie McCormack added a comment - Moving items unlikely to be completed for 0.6 out to 0.7
        Hide
        Rajith Attapattu added a comment -

        The attached patch contains basic support for the common addressing syntax to be used by all clients.
        The patch is incomplete as it is not functionally complete due to lack of a parser.
        The patch also does not contain any tests as of yet. I want to investigate the possibility about reusing tests written for the python client and then supplement it with java based tests.

        I'd appreciate your comments about the direction taken in this patch.
        Suggestions and criticisms are most welcomed.

        Implementation Notes
        ------------------------------------
        1. The required fields and methods to support the new addressing mechanism is added to AMQDestination itself. This was to ensure there is as little code changes as possible to the existing setup.

        2. The code requires a parser for the new addressing syntax. Once that is available code will be added to use that to populate the required fields.

        3. The new addressing support is only added to the 0-10 codepath as I am not sure there is sufficient protocol level support to implement it meaningfully in 0-8.

        4. For now I am ignoring the browse option (I believe this value could be used for the noconsume field in BasicMessageConsumer)

        5. For now I am ignoring reliability option as I am not quite sure how to tie that into the existing ack modes (perhaps I misunderstood).

        6. I have not bothered to factor in any abstraction required to support AMQP 1.0, as I feel it's best served if we look at the client as a whole rather than piece by piece when figuring out the right level of abstraction.

        7. I have removed the final keyword from _exchangeName, _exchangeClass, _isDurable, _isExclusive, _isAutoDelete to get more flexibility within the constructor methods. None of the above had any setter methods (well I added ones for exchangeName and exchangeClass for good reason) and are only set in the constructor or constructor like methods.

        8. The equals method for AMQDestination needs to be modified to handle the new addressing syntax.
        Ex. Consider a javax.jms.Destination dest1 with an address "foo" and another instance called dest2 with the same address. If the name resolves to an exchange, the queuenames contained within dest1 and dest2 would be different as a private temp queue is created for each if used by a consumer. If "foo" resolves to a queue then then the queuename would be the same for both instances. If an equals test is performed for dest1 and dest2 it should succeed for use cases, allthough the test criteria will be different.

        Show
        Rajith Attapattu added a comment - The attached patch contains basic support for the common addressing syntax to be used by all clients. The patch is incomplete as it is not functionally complete due to lack of a parser. The patch also does not contain any tests as of yet. I want to investigate the possibility about reusing tests written for the python client and then supplement it with java based tests. I'd appreciate your comments about the direction taken in this patch. Suggestions and criticisms are most welcomed. Implementation Notes ------------------------------------ 1. The required fields and methods to support the new addressing mechanism is added to AMQDestination itself. This was to ensure there is as little code changes as possible to the existing setup. 2. The code requires a parser for the new addressing syntax. Once that is available code will be added to use that to populate the required fields. 3. The new addressing support is only added to the 0-10 codepath as I am not sure there is sufficient protocol level support to implement it meaningfully in 0-8. 4. For now I am ignoring the browse option (I believe this value could be used for the noconsume field in BasicMessageConsumer) 5. For now I am ignoring reliability option as I am not quite sure how to tie that into the existing ack modes (perhaps I misunderstood). 6. I have not bothered to factor in any abstraction required to support AMQP 1.0, as I feel it's best served if we look at the client as a whole rather than piece by piece when figuring out the right level of abstraction. 7. I have removed the final keyword from _exchangeName, _exchangeClass, _isDurable, _isExclusive, _isAutoDelete to get more flexibility within the constructor methods. None of the above had any setter methods (well I added ones for exchangeName and exchangeClass for good reason) and are only set in the constructor or constructor like methods. 8. The equals method for AMQDestination needs to be modified to handle the new addressing syntax. Ex. Consider a javax.jms.Destination dest1 with an address "foo" and another instance called dest2 with the same address. If the name resolves to an exchange, the queuenames contained within dest1 and dest2 would be different as a private temp queue is created for each if used by a consumer. If "foo" resolves to a queue then then the queuename would be the same for both instances. If an equals test is performed for dest1 and dest2 it should succeed for use cases, allthough the test criteria will be different.
        Hide
        Rajith Attapattu added a comment - - edited

        The address based parser was committed at rev 901268 in Qpid trunk.
        In rev 906142, 906144 and 906145 I added the implementation of the new addressing syntax, the integration with the address parser and the required tests.

        Show
        Rajith Attapattu added a comment - - edited The address based parser was committed at rev 901268 in Qpid trunk. In rev 906142, 906144 and 906145 I added the implementation of the new addressing syntax, the integration with the address parser and the required tests.
        Hide
        Rajith Attapattu added a comment -

        QPID-2496 covers the outstanding work that needs be completed for addressing support.

        Show
        Rajith Attapattu added a comment - QPID-2496 covers the outstanding work that needs be completed for addressing support.

          People

          • Assignee:
            Rajith Attapattu
            Reporter:
            Rajith Attapattu
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development