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
