qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Proposal for a new JMS Destination configuration
Date Thu, 07 May 2009 13:41:42 GMT
On Thu, May 7, 2009 at 8:57 AM, Rafael Schloming <rafaels@redhat.com> wrote:
> Gordon Sim wrote:
>>
>> Rafael Schloming wrote:
>>>
>>> Gordon Sim wrote:
>>>>
>>>> Rajith Attapattu wrote:
>>>>>
>>>>> Gordon,
>>>>>
>>>>> Thanks for you feedback. Comments inline.
>>>>>
>>>>> On Tue, May 5, 2009 at 2:06 PM, Gordon Sim <gsim@redhat.com> wrote:
>>>>>>>
>>>>>>> Suggestions and criticisms are equally welcomed.
>>>>>>
>>>>>> I am very much in favour of some changes in the configuration of
>>>>>> destinations and expanding the capabilities in this regard. However
I
>>>>>> wonder
>>>>>> if perhaps a simpler syntax is possible?
>>>>>>
>>>>>> Even the simplest example:
>>>>>>
>>>>>>  xqueue.myQueue = name='myQueue'
>>>>>>  xdestination.myQueue = queue=myQueue
>>>>>
>>>>> Could you compare with new proposal I sent to the list and see if the
>>>>> simplest format is good enough?
>>>>> In the new one it would be as simple as
>>>>> destinationx.<jndi-name> = myQueue
>>>>
>>>> So are the following entirely independent and equivalent forms for the
>>>> same thing?
>>>>
>>>> queuex.my-jndi-name = {name=MyQueue, durable=true}
>>>> destinationx.my-jndi-queue = MyQueue; {durable=true}
>>>>
>>>> If so, whats the motivation for the first form?
>>>
>>> I think the queuex stuff is only to control whether and how you
>>> auto-declare queues, so the common case would be:
>>>
>>> destinationx.my-jndi-name = MyQueue
>>>
>>> And then if you wanted to auto-declare the queue you would add this:
>>>
>>> queuex.MyQueue = {auto-create=true, durable=true, ...}
>>
>> I see. That is not at all obvious (at least to me) from either the syntax
>> or the proposal text.
>>
>> Is the auto-create not implied in that case? I.e. why else would you have
>> a queuex type declaration other than to auto-create the queue?
>
> I presume it would be to make assertions on the properties of a queue,
> however you could choose to omit that feature and imply auto-create from the
> presence of the declaration.
>
>> Would such a queue be auto-created for either the first consumer or the
>> first producer to be created?
>
> I think you might actually want to control that explicitly, e.g. have
> something like this:
>
> queuex.MyQueue = {create-on-send=true, create-on-receive=false, ...}

In my previous proposal I had a create queue option on the publisher
link to configure if it should be created at send (and defaulted to
receive).
So I think something along the lines that Rafi has proposed is
valuable to have. We have users requesting queues to be created at
send time so the messages get stored even if a consumer is not present
at the moment.

>
>>> As I understand it you would only add options to the destination in order
>>> to configure the individual producers and consumers created from the
>>> destination, e.g.:
>>>
>>> destinationx.my-jndi-name = MyQueue; {prefetch=100, sync=true, ...}
>>>
>>>> The advantage as I viewed it was more related to intuitiveness (since
>>>> the file is a properties file).
>>>>
>>>>> I think most destination definitions will be quite simple and may not
>>>>> be as confusing with the more compact format.
>>>>
>>>> I don't think the compact syntax is confusing; I think its just another
>>>> syntax embedded in the properties file syntax. I could certainly live with
>>>> that, but it's probably worth thinking about it and being sure that the
>>>> reasons for it are clear.
>>>>
>>>> I think the source of confusion may be around the various options, what
>>>> they mean, how they are interpreted or whether they are valid in a given
>>>> context or not.
>>>
>>> I think the main reason for using this format rather than a flat
>>> properties file format is that we also need a syntax for something people
>>> can pass to Session.createTopic("...") and Session.createQueue("..."), and
>>> the properties file format doesn't work so well for that.
>>
>> Thats a fair point (at least to an extent!).
>
> I think there are some other good reasons to avoid depending too heavily on
> the properties file format for the syntax of the destination. In particular
> for consistent configuration across varied file formats (including across
> the various different language clients), it is fairly nice to have a closed
> and self-contained syntax for specifying addresses and configuring links
> (producers & consumers).
>
> I would ideally like to be able to cut and paste this part of the
> configuration between a java, cpp, and python client, or even between a
> .properties jndi file and, e.g. a .xml jndi file. I don't see this happening
> if we design the syntax specifically for a flat properties file.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>



-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

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


Mime
View raw message