qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-1831) Improve JMS Destination abstraction to better support AMQP and Qpid specific features
Date Thu, 07 Jan 2010 15:16:09 GMT

     [ https://issues.apache.org/jira/browse/QPID-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rajith Attapattu updated QPID-1831:
-----------------------------------

    Attachment: QPID-1831.patch

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.

> Improve JMS Destination abstraction to better support AMQP and Qpid specific features
> -------------------------------------------------------------------------------------
>
>                 Key: QPID-1831
>                 URL: https://issues.apache.org/jira/browse/QPID-1831
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Client
>            Reporter: Rajith Attapattu
>            Assignee: Rajith Attapattu
>             Fix For: 0.7
>
>         Attachments: AMQXDest.patch, QPID-1831.patch
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message