All sounds sensible to me. Robbie
On 11 March 2011 10:01, 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. > > 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. > > 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. > > 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. > 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) > > Thoughts? > > Rob >
