On Fri, Mar 11, 2011 at 5:01 AM, Robert Godfrey <rob.j.godf...@gmail.com>wrote:
> On 11 March 2011 08:18, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > > On 11 March 2011 01:42, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > <snip> > > > > > 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. > > > > > <snip> > > > > It occurs to me now that this was actually fixed a while back and I > forgot, > > so yes the durability of the queue will also affect the Java brokers > > performance too, which is entirely sensible. Not getting persistence by > > default when you have asked for it is less so. > > > > So I think we're talking about a number of different things here. > Sorry my bad for not staying on the topic. However in a way it's good that we are discussing them all though it might have been better if these issues were discussed under their own thread. > 1) createQueue doesn't create a queue at the broker - but it does create a > Destination object. There is a question about what properties of the > created object should be implied from the passed in String. > 2) By default, on creating a consumer, the Java Client declares (creates) > the queue with the properties in the Destination Object. > 3) Sending persistent messages to a queue which has a lifetime limited to > the uptime of the Broker makes little sense > > Personally I think it's high time that we fixed 2), and made the default > not > to create queues (except of the temporary variety, and as necessary for > Durable Subscriptions). I believe there is already a System Property for > this, and we would just need to change the default. Obviously any such > change would need to be well advertised, and perhaps we should also add > some > logging where previously a queue would have been created and now it is not. > > Rob the addressing syntax (which is the default from the 0.8 release) does not create queues by default. So this is already there. If the node (exchange or queue) specified in the address is not found and if there is no explicit instruction to create it then an exception is thrown. > Issue 3) is something that should be dealt with on the Broker side I think > - > I've always thought that we should at least log (once per queue per > session) > where clients are sending durable messages to a transient queue. > I think that's probably the best way to handle it. The C++ broker may already be doing this, but Alan or Gordon can confirm. Issue 1) (what are the default properties of a Destination object created > through the createQueue API call) I actually care very little about as > anyone using this API for the purpose of creating the Queue on the Broker > should really be fully specifying the properties in the passed in String. > I fully agree with you here. If just a queue name is passed in, we should *not* be assuming things like durability etc.. A user has the ability to specify all the properties it likes (including how the queue should be created and deleted) if they choose to do so. > Having said that I think we should be careful changing the default > behaviour > until such a time ass we fix issue 2 (and we should do this ASAP - it's > long > overdue) > > Issue 2 is already fixed. When I implemented addressing I did try to preserve backwards compatibility all though I regret it now. (However I didn't know that the queues created using session.createQueue were durable by default.) Also we need to explicitly document what the default behaviour is for the benefit of our users. > Thoughts? > > Rob >
