Forwarding, since Gmail decided I didnt really want to reply to the list :)
---------- Forwarded message ----------
From: Robbie Gemmell
Date: 10 March 2011 21:02
On 10 March 2011 16:00, Rajith Attapattu <rajit...@gmail.com> wrote:
>
> On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell <robbie.gemm...@gmail.com
> > wrote:
>
>> Creating (non-temporary) durable queues has always been the default afaik,
>>
>
> If Qpid created durable queues by default then I think that is something we
> need to explicitly document, since it's different from what the API doc
> states.
>
> From the JMS API doc, it's quite clear that we are not exactly compliant.
> So the existing behaviour (and the current behaviour) is not really correct.
> "Note that this method is not for creating the physical queue. The physical
> creation of queues is an administrative task and is not to be initiated by
> the JMS API."
>
> It prohibits creation of the physical queue, let alone making it durable.
>
>
I wasn’t suggesting that the session.createQueue call itself created the
queue on the broker, it doesn’t and never has. It does however create a
Queue object that was previously configured to be durable by default,
resulting in eventual durable queue creation on the broker when the queue
declare gets issued during Consumer creation.
> I was initially going to mark all queues created (with just a name) as
> "create: never" so we are compliant with the spec.
> (Anybody who wants to override this could do so with explicitly specifying
> "create:sender/receiver/always" as appropriate.)
> However existing applications would have failed since it's dependent on the
> queue being created by the Qpid client, all though that is clearly the wrong
> behaviour.
>
> An unsuspecting user may be caught off guard as the JMS spec doesn't
> mention anything of the sort.
> Durable queues has an impact on performance and I am not sure it's a smart
> idea to make that the default.
>
You reference deciding to continue creating queues by default during
consumer creation in to preserve the existing behaviour for application
compatibility, but in that case I would expect **all** of the existing
default behaviour to be preserved and not just some of it since thats
arguably worse: now applications will continue creating queues as before,
but might lose messages at some point because the queues are not actually
durable like they might previously have been expected to be (see: this email
thread).
>
> If a user wants durability then I believe it should be explicitly
> signalled. So I am not happy durability being the default.
>
>
>> and given that the default delivery mode for the messages themselves is
>> persistent that probably makes some amount of sense.
>
>
> I think that was probably done as a precaution more than anything.
> So any message that ends up in a durable queue will be persisted unless the
> user explicitly says not to.
>
>
Exactly, because JMS doesnt really deal with queue durability (other than as
an interpretation of Durable Subscriptions) as a concept at all, it deals
with message persistence and queues just kind of exist or not. As such users
who send persistent messages using a JMS client might reasonably just expect
them to be persisted.
> Hope this helps.
>
> Regards,
>
> Rajith.
>
>
>> Such a change wont have
>> been caught by the tests since the profiles all still default to the old
>> syntax..
>>
>> The JMS API wont cover this because it doesn't really cover queue
>> creation,
>> except to say that it doesn't :)
>>
>
> Well if it was intended that way I am sure at least there would be some
> mention in the JMS specification doc.
>
>
The section you quoted above is the exact one I was thinking of at the time,
im not sure there is any other way to interpret that really; it isnt going
to say whether they should be durable or not because it explicitly says it
doesnt cover those operations in the first place.
Robbie
>
>
>> Robbie
>>
>> On 10 March 2011 15:16, Rajith Attapattu <rajit...@gmail.com> wrote:
>>
>> > Danushka,
>> >
>> > I don't think session.createQueue should create durable queues.
>> > At least there is no requirement like that specified in the JMS spec.
>> >
>> > If the 0.6 release creates durable queues then I think it should be a
>> bug,
>> > but I haven't really noticed anything like that before.
>> > For the upcoming 0.10 release (and of course trunk) you can create a
>> > durable
>> > queue using session.createQueue if you specify the correct option in the
>> > address string.
>> >
>> > Ex. The following address string will create my-queue and mark it
>> durable.
>> > "my-queue; {create: always , node : {durable:true}}"
>> >
>> > Refer to the programming guide on the website for a complete description
>> of
>> > the addressing syntax.
>> >
>> > Regards,
>> >
>> > Rajith
>> >
>> > On Thu, Mar 10, 2011 at 5:38 AM, Danushka Menikkumbura <
>> > danushka.menikkumb...@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > I see that the queues created using session.createQueue are not
>> durable
>> > in
>> > > the trunk version that I am using as opposed to it creates durable
>> queues
>> > > in
>> > > 0.6 release. I think this particular JMS call should create durable
>> > queues.
>> > >
>> > > Furthermore the trunk version that I use creates durable queues when I
>> > use
>> > > JNDI.
>> > >
>> > > Thanks,
>> > > Danushka
>> > >
>> > > --
>> > > Danushka Menikkumbura
>> > > Apache Axis2 PMC Member
>> > >
>> > > Apache Qpid - World Domination through Advanced Message Queueing ;
>> > > http://qpid.apache.org
>> > >
>> > > phone : +94 77 364 1754
>> > > personal blog : http://danushka-menikkumbura.blogspot.com/
>> > > <http://danushka-menikkumbura.blogspot.com/>technical blog :
>> > > http://danushkastechythoughts.blogspot.com/
>> > > <http://danushkastechythoughts.blogspot.com/>twitter :
>> > > http://twitter.com/danushkamenik
>> > > <http://twitter.com/danushkamenik>linkedin :
>> > > http://lk.linkedin.com/in/danushka
>> > >
>> >
>>
>
>
