On 10 March 2011 22:15, Rajith Attapattu <[email protected]> wrote: > > > On Thu, Mar 10, 2011 at 4:05 PM, Robbie Gemmell > <[email protected]>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 <[email protected]> wrote: >> >> > >> > On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell < >> [email protected] >> > > 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. >
Ok, I took your quoting of the session.createQueue javadoc as a basis of argument to suggest that you were, my mistake. > 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 am not suggesting that it creating queues duing Consumer construction is what the API says it should do, as it is pretty clear that it only covers creation creation of temporary queues, and (in our implementation of topic subscriptions) creation and removal of the backing queues used for DurableSubscriptions. The durability of the queues it is already creating by default is the point of interest here though, not whether it should actually be creating them. The JMS API says nothing in this regard as it has no concept of queue durability (only topic subscription durability, which is not the same thing although a durable queue is how we implement that), and as we have both pointed out JMS doesnt cover general queue 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). >> >> 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. > Message persistence is the only option given to users of the JMS API and is persistent by default, so I dont see that as being open to interpretation. The default client behaviour should allow for the delivery mode setting to actually have an effect. The explicit choice is there to use non persistent. That the client creates a queue, rightly or wrongly, is somewhat irrelevant from the users perspective if they ask for persistent delivery and dont get it because the queue we create isnt durable. That is something I feel could catch out users who have actually read the JMS API that they are using. Being able to explicitly state a queue isnt durable so that delivery mode doesnt have the desired affect is fine, but not the other way around. Imposing a performance penalty (there is none in the Java broker currently, its performance revolves entirely around the message delivery mode not the queue durability) on unsuspecting users seems better to me than imposing less reliable messaging on the users who have actually asked for reliablility. > > >> > 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. > > I dont feel that I am interpreting the spec at all, given that as we have both noted it doesnt cover general queue creation, it explicitly covers the choice between persistent (default) and non persistent message delivery modes and the associated reliability and performance tradeoffs, and has no concept of queue durability. I'm happy to read the API segments which would clarify my understanding? Robbie > >> > 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 <[email protected]> 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 < >> >> > [email protected]> 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 >> >> > > >> >> > >> >> >> > >> > >> > >
