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 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.
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.
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.
> 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
> > >
> >
>
