You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Danushka Menikkumbura <da...@gmail.com> on 2011/03/10 11:38:22 UTC
session.createQueue does not create durable queues
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
Re: session.createQueue does not create durable queues
Posted by Danushka Menikkumbura <da...@gmail.com>.
> 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.
>
Yes. The specification does not explicitly say when you should create a
queue. But you always need a producer/consumer/browser/receiver in order to
make use of a queue. Therefore I do not see anything wrong with creating a
queue physically in the broker at the point of creating one of these objects
that is associated with the queue.
> 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.
>
+1
> 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.
>
+1. I think whether to "actually persist a durable queue" or not is
something that should be decided based on the message store you use. On the
other hand as I have mentioned in my initial mail it creates durable queues
by default if you use JNDI to get queue object instances.
Thanks,
Danushka
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
All sounds sensible to me.
Robbie
On 11 March 2011 10:01, Robert Godfrey <ro...@gmail.com> wrote:
>
>
> On 11 March 2011 08:18, Robbie Gemmell <ro...@gmail.com> wrote:
>
>> On 11 March 2011 01:42, Robbie Gemmell <ro...@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
>
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
On 11 March 2011 15:18, Rajith Attapattu <ra...@gmail.com> wrote:
>
> 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.
>
I also fully agree that we shouldn't be assuming the properties, however we
historically have and as long as we continue to create queues by default
then by extension we must assume something. Whilst doing that it should be
the same as it was before, both for continuity and so that the delivery mode
setting can actually have the intended effect from the viewpoint of someone
using a JMS client.
Robbie
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
( I really need to start hitting reply to all :P )
---------- Forwarded message ----------
Whilst i think its the right thing to do going forward, I don't think such a
change should be introduced at this point in the 0.10 release cycle.
Robbie
On 11 March 2011 16:23, Rajith Attapattu <ra...@gmail.com> wrote:
>
>
> On Fri, Mar 11, 2011 at 10:49 AM, Robbie Gemmell <robbie.gemmell@gmail.com
> > wrote:
>
>> On 11 March 2011 15:30, Robert Godfrey <ro...@gmail.com> wrote:
>>
>> > 2) By default, on creating a consumer, the Java Client declares
>> (creates)
>> > the queue with the properties in the Destination Object.
>> >
>> > 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.
>> > >
>> >
>> >
>> > To be clear if you do
>> >
>> > Queue q = session.createQueue("myQueue");
>> > MessageConsumer mc = session.createConsumer(q);
>> >
>> > You are saying that no queue called "myQueue" will be created on the
>> Broker
>> > now?
>> >
>> > I thought that what was being said was that it is still created, but
>> while
>> > previously this would have created a durable queue, now it creates a
>> > transient one
>> >
>> > -- Rob
>> >
>>
>> I believe that is exactly what was being said by Danushka (and myself).
>> Just
>> to confirm my own sanity I have checked that doing the above does indeed
>> now
>> create a transient 'myQueue' when using trunk, but when using an older
>> client isntead creates a durable queue.
>>
>> I don't think there was any disagreement about the previous or current
> behaviour.
> I believe the disagreement was about making the queue 'durable' by default.
>
>
>> The correct course of action is of course to stop the client creating any
>> queues by default so that people must explicitly choose what they want.
>>
>
> Yes I am hoping to create a JIRA and make that simple fix and ask it to be
> included in the 0.10 release.
> The fix is very simple. Just needs to remove the line that sets create
> option to always.
>
>
>> However, until that it done it should really have the previous behaviour
>> so
>> that message delivery mode actually takes effect and causes messages to be
>> persisted if Persistent delivery is specified.
>>
>> Robbie
>>
>
>
Re: session.createQueue does not create durable queues
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Mar 11, 2011 at 10:49 AM, Robbie Gemmell
<ro...@gmail.com>wrote:
> On 11 March 2011 15:30, Robert Godfrey <ro...@gmail.com> wrote:
>
> > 2) By default, on creating a consumer, the Java Client declares (creates)
> > the queue with the properties in the Destination Object.
> >
> > 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.
> > >
> >
> >
> > To be clear if you do
> >
> > Queue q = session.createQueue("myQueue");
> > MessageConsumer mc = session.createConsumer(q);
> >
> > You are saying that no queue called "myQueue" will be created on the
> Broker
> > now?
> >
> > I thought that what was being said was that it is still created, but
> while
> > previously this would have created a durable queue, now it creates a
> > transient one
> >
> > -- Rob
> >
>
> I believe that is exactly what was being said by Danushka (and myself).
> Just
> to confirm my own sanity I have checked that doing the above does indeed
> now
> create a transient 'myQueue' when using trunk, but when using an older
> client isntead creates a durable queue.
>
> I don't think there was any disagreement about the previous or current
behaviour.
I believe the disagreement was about making the queue 'durable' by default.
> The correct course of action is of course to stop the client creating any
> queues by default so that people must explicitly choose what they want.
>
Yes I am hoping to create a JIRA and make that simple fix and ask it to be
included in the 0.10 release.
The fix is very simple. Just needs to remove the line that sets create
option to always.
> However, until that it done it should really have the previous behaviour so
> that message delivery mode actually takes effect and causes messages to be
> persisted if Persistent delivery is specified.
>
> Robbie
>
Re: session.createQueue does not create durable queues
Posted by Danushka Menikkumbura <da...@gmail.com>.
> I believe that is exactly what was being said by Danushka (and myself).
> Just
> to confirm my own sanity I have checked that doing the above does indeed
> now
> create a transient 'myQueue' when using trunk, but when using an older
> client isntead creates a durable queue.
>
+1.
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
On 11 March 2011 15:30, Robert Godfrey <ro...@gmail.com> wrote:
> 2) By default, on creating a consumer, the Java Client declares (creates)
> the queue with the properties in the Destination Object.
>
> 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.
> >
>
>
> To be clear if you do
>
> Queue q = session.createQueue("myQueue");
> MessageConsumer mc = session.createConsumer(q);
>
> You are saying that no queue called "myQueue" will be created on the Broker
> now?
>
> I thought that what was being said was that it is still created, but while
> previously this would have created a durable queue, now it creates a
> transient one
>
> -- Rob
>
I believe that is exactly what was being said by Danushka (and myself). Just
to confirm my own sanity I have checked that doing the above does indeed now
create a transient 'myQueue' when using trunk, but when using an older
client isntead creates a durable queue.
The correct course of action is of course to stop the client creating any
queues by default so that people must explicitly choose what they want.
However, until that it done it should really have the previous behaviour so
that message delivery mode actually takes effect and causes messages to be
persisted if Persistent delivery is specified.
Robbie
Re: session.createQueue does not create durable queues
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Mar 11, 2011 at 10:30 AM, Robert Godfrey <ro...@gmail.com>wrote:
> 2) By default, on creating a consumer, the Java Client declares (creates)
> the queue with the properties in the Destination Object.
>
> 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.
> >
>
>
> To be clear if you do
>
> Queue q = session.createQueue("myQueue");
> MessageConsumer mc = session.createConsumer(q);
>
> You are saying that no queue called "myQueue" will be created on the Broker
> now?
>
> Sorry Rob I should have made it clear.
For this particular case (if just the queue name is specified) I set the
create option so it does get created.
As I said I really regret doing it, as it's not properly backwards
compatible, nor it's really consistent with the way addressing works in rest
of the code.
Maybe I should fix it properly (to be consistent with how addressing works)
for this release.
When I said I fixed issue #2, I meant the following,
Destination q = new AMQAnyDestination("myQueue");
MessageConsumer cons = session.createConsumer(q);
The above will definitely throw an exception if "myQueue" is not found on
the broker.
> I thought that what was being said was that it is still created, but while
> previously this would have created a durable queue, now it creates a
> transient one
>
> -- Rob
>
Re: session.createQueue does not create durable queues
Posted by Robert Godfrey <ro...@gmail.com>.
2) By default, on creating a consumer, the Java Client declares (creates)
the queue with the properties in the Destination Object.
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.
>
To be clear if you do
Queue q = session.createQueue("myQueue");
MessageConsumer mc = session.createConsumer(q);
You are saying that no queue called "myQueue" will be created on the Broker
now?
I thought that what was being said was that it is still created, but while
previously this would have created a durable queue, now it creates a
transient one
-- Rob
Re: session.createQueue does not create durable queues
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Mar 11, 2011 at 5:01 AM, Robert Godfrey <ro...@gmail.com>wrote:
> On 11 March 2011 08:18, Robbie Gemmell <ro...@gmail.com> wrote:
>
> > On 11 March 2011 01:42, Robbie Gemmell <ro...@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
>
Re: session.createQueue does not create durable queues
Posted by Robert Godfrey <ro...@gmail.com>.
On 11 March 2011 08:18, Robbie Gemmell <ro...@gmail.com> wrote:
> On 11 March 2011 01:42, Robbie Gemmell <ro...@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
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
On 11 March 2011 01:42, Robbie Gemmell <ro...@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.
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
On 10 March 2011 22:15, Rajith Attapattu <ra...@gmail.com> wrote:
>
>
> On Thu, Mar 10, 2011 at 4:05 PM, Robbie Gemmell <ro...@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 <ra...@gmail.com> wrote:
>>
>> >
>> > On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell <
>> robbie.gemmell@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.
>
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 <ra...@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.menikkumbura@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
>> >> > >
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: session.createQueue does not create durable queues
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Mar 10, 2011 at 4:05 PM, Robbie Gemmell <ro...@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 <ra...@gmail.com> wrote:
>
> >
> > On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell <
> robbie.gemmell@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 <ra...@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.menikkumbura@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
> >> > >
> >> >
> >>
> >
> >
>
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ra...@gmail.com> wrote:
>
> On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell <robbie.gemmell@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. 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.
> 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).
>
> 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.
> 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 <ra...@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.menikkumbura@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
>> > >
>> >
>>
>
>
Re: session.createQueue does not create durable queues
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell
<ro...@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 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.
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.
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.
> Robbie
>
> On 10 March 2011 15:16, Rajith Attapattu <ra...@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.menikkumbura@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
> > >
> >
>
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
Creating (non-temporary) durable queues has always been the default afaik,
and given that the default delivery mode for the messages themselves is
persistent that probably makes some amount of sense. 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 :)
Robbie
On 10 March 2011 15:16, Rajith Attapattu <ra...@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.menikkumbura@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
> >
>
Re: session.createQueue does not create durable queues
Posted by Rajith Attapattu <ra...@gmail.com>.
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.menikkumbura@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
>
Re: session.createQueue does not create durable queues
Posted by Robbie Gemmell <ro...@gmail.com>.
Danushka, you can control the destination syntax using the system property
'qpid.dest_syntax' so you should be able to reinstate the previous behaviour
by leveraging that if you so wish:
-Dqpid.dest_syntax=BURL (to set the old style BindingURL syntax)
-Dqpid.dest_syntax=ADDR (to use the new style Addressing syntax, default)
Robbie
On 10 March 2011 10:38, Danushka Menikkumbura <
danushka.menikkumbura@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
>