Hi,
what scenario are you trying to solve?
You can definitely make a queue durable then specify that the message
isn't persistent. I'm pretty sure though (at least with Java anyway)
that the default is for messages to be specified persistent (see
javax.jms.Message javadoc):
||
|*DEFAULT_DELIVERY_MODE
<http://download.oracle.com/javaee/5/api/javax/jms/Message.html#DEFAULT_DELIVERY_MODE>*|
The message producer's default delivery mode is |PERSISTENT|.
So you'd be reliant on all of the producers delivering to that queue to
implement non-default behaviour to guarantee that the queue was durable
but the messages didn't survive. That doesn't feel like a great thing to
do, even if producers were willing to set these flags it requires code
changes to the producers and you'd be dependent on a possibly lengthy
roll-out if you have lots of producers.
That said you mentioned "i.e. I want my configuration to survive a
restart" so is this really a case of needing to make sure that your
exchanges and links are durable? I think that you'll still need the
perstistence module.
Or is your scenario where you've got a bunch of queues & bindings to
them established and you want the queue names & bindings to survive a
restart but you're not fussed about any messages on the queue being
retained?
That's an interesting one if that is the case TBH I'm not sure of the
answer.
I guess that if the queues are created dynamically by consumers
connecting, when they reconnect after the broker restarts then
everything should get restarted fine - have you tried the automatic
reconnection option on the Connection URL, I'm fairly sure that works fine.
If the queues & bindings are created "administratively" e.g. via
qpid-config then I'm not sure of the best approach for automatically
re-creating them. Making them durable definitely works, but like you say
that's not quite what you actually want if the scenario above is your
use case.
Oh now you've got me thinking!!! I remember our conversation a bit back
about federation, Are you setting up a federated link with a queue
route, so you need to establish a queue & binding on the source broker
administratively then link that to the destination broker and you want
the set up the queue on the source broker to survive a restart?
I bet that *is* what you mean and I'm afraid I don't have a good answer
and I'd love to know too!!! - I'll have a think (I presume that making
the link that pulls data off the queue durable doesn't help?).
Maybe someone cleverer than me already knows the answer :-/
I guess for that scenario having the broker automatically read in config
that establishes the necessary queues/bindings upon startup would be
fine too (probably better than persisting pre-existing queues), but I'm
not sure how to achieve that either :-( I'd quite like to know the
answer to that too :-)
Frase
rfallon wrote:
All,
I want durable queues that DO NOT persist the messages, i.e. I want my
configuration to survive a restart but (as a performance trade-off) I do not
want to incur the costs of persisting data, so do not care if my data
survives.
So I have created a durable queue and tried starting up the broker with a
number of different options but the only two behaviours I can see are:-
1) Queue survives restart with all its data
2) Queue does not survive restart
>From my tests I have not been able to create a durable queue that does not
persist the data. Is this possible? How would I acheive this?
Btw currently using C++ v0.8.
--
View this message in context:
http://apache-qpid-users.2158936.n2.nabble.com/Durable-Queue-Behaviour-tp6772357p6772357.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
