Hi Richard
So I guess there are two possible behaviours that would satisfy your
requirement
1) durable queue *config" e.g. names/bindings etc.
or
2) the ability for the broker to automatically read some config on
startup. There is a --config option, but I think that only covers broker
config (the stuff covered in qpidd -h) and not queue/binding config.
I'd *love* to know if there's a good solution to this too I can't
believe that there isn't.
I did have an "out there" thought that it would be possible to have a
client app hanging on an automatic retry connection that establishes a
connection/session/destination but doesn't read any messages that just
might force a recreation of the queue and binding, similarly an auto
reconnect QMF client would be able to re-establish configuration. The
problem with these options is that you'd need to make sure that those
client apps never died either by having something like a cron job
monitoring their "alive" state or having them as inetd services. To be
honest these options make my toes curl a bit and I'd really hope that
there's a more elegant solution.
I'm afraid that's the best I've managed to come up with since this
morning :-(
It seems a very reasonable requirement to be able to provision
administratively created queues/exchanges/bindings/links etc. via broker
startup config.
To put it bluntly it would seem a really good thing indeed to be able to
put all of the information needed to establish a federated topology
under a configuration management system so that one can systematically
reproduce the topology.
I guess scripting qpid-config and qpid-route is one option, but it feels
inelegant and how would one trigger the script on broker start up.....
Frase
Fallon, Richard wrote:
Hi Carl,
Thanks for the response - I think I want the moon on a stick - but I
cannot rely on my publishers not to set the durable bit (especially as
it is on by default on a JMSMessage). So that won't quite do.
I have two federated brokers joined by a queue route and I want to
ensure that the queue route survives system restarts/updates but I do
not want to use message persistence. If the queue is not durable the
queue route is invalid. Mmmm.
Thanks
Richard
Richard Fallon
Architect
01928 598963
+447733312563
[email protected]
-----Original Message-----
From: Carl Trieloff [mailto:[email protected]]
Sent: 08 September 2011 17:27
To: [email protected]
Subject: Re: Durable Queue Behaviour
make the queue durable on create, but do not set the durable bit on
message publish. That should do it for you
Carl.
On 09/08/2011 11:47 AM, 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]
_______________________________________________________
Atos and Atos Consulting are trading names used by the Atos group. The
following trading entities are registered in England and Wales: Atos IT
Services UK Limited (registered number 01245534), Atos Consulting Limited
(registered number 04312380) and Atos IT Solutions and Services Limited
(registered number 01203466) The registered office for each is at 4 Triton
Square, Regents Place, London, NW1 3HG. The VAT No. for each is: GB232327983
This e-mail and the documents attached are confidential and intended solely for
the addressee, and may contain confidential or privileged information. If you
receive this e-mail in error, you are not authorised to copy, disclose, use or
retain it. Please notify the sender immediately and delete this email from
your systems. As emails may be intercepted, amended or lost, they are not
secure. Atos therefore can accept no liability for any errors or their
content. Although Atos endeavours to maintain a virus-free network, we do not
warrant that this transmission is virus-free and can accept no liability for
any damages resulting from any virus transmitted. The risks are deemed to be
accepted by everyone who communicates with Atos by email.
_______________________________________________________
---------------------------------------------------------------------
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]
