On Thu, Mar 10, 2011 at 4:05 PM, Robbie Gemmell <robbie.gemm...@gmail.com>wrote:
> 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.
>
I didn't imply that, as I am well aware that isn't the case.
I was referring to the queue being created when a consumer is created off
that destination (again wrong behaviour).
The only thing that I wasn't aware was that it was durable by default, which
I clearly think is not a smart idea.
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.
>
>
Exactly and that is clearly the wrong behaviour as per what is described in
the API !
The queue being created as a side affect of creating a consumer is actually
worse.
>
>
> > 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).
>
> Again, I wasn't aware that the queues were durable by default.
There was no documentation in the code or otherwise indicating that (if
there is then I apologize for not doing enough research).
I certainly believe durability should be an explicit choice.
I would not want to impose a performance penalty on an unsuspecting user
simply bcos of the way we interpret the JMS spec.
>
> > 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.
>
>
I disagree with your interpretation of the JMS spec.
I really don't think many users out there really think that way either.
Most folks are well aware that writing to the disk is expensive, and would
not expect that to be the default behaviour.
> > 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
> >> > >
> >> >
> >>
> >
> >
>
