qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: Java Broker Durability Questions
Date Fri, 12 Nov 2010 11:02:29 GMT
Hi Patrick,

Answers in line below - hth ..

On Thu, Nov 11, 2010 at 9:20 PM, Patrick Nails <patrick.nails@gmail.com>wrote:

> I have a few questions about the Java Broker and durability:
> 1) If a Queue,Broker or Exchange are marked as durable (especially
> concerned
> about queues here) and a failover occurs, causing a switch to another
> broker, does this new broker obtain the durable information? What if the
> new
> broker is on a separate machine?
> Using a persistent store the new broker can use that existing BDB store to
pick up durable message data. If you define your queues in virtualhosts.xml
and keep your configs in step then it will also pick up queue durability.
Often users opt for shared SAN for the store in such a case, and the broker
on a seperate server.

> 2) It seems that a durable queue, will maintain the messages it had even on
> a broker restart (I think).
> Are durable exchanges and bindings only relevant if there are
> bindings/settings that are not made during start-up?
> If queues are durable, then the bindings that are associated with them are
> automatically restored, correct?
> Yes, it will corretly retain persistent messages on restart.Yes, bindings
are restored too - though for topics only with durable subscriptions.

> 3) Are there any problems with a Broker being started in Java Code, say by
> firing off a new thread using the Broker Main method?
> So long as your JVM is sized appropriately that's ok - depends what else
you're planning to do in the same VM instance ?

> 4) It seems that "Write-To-Disk" is not implemented for the Java Broker, is
> this correct?

Yes and No :-) So, all data is effectively written to disk using a
persistent BDB store and soft references are used to cache message handles
in the broker VM, being aged out. You are correct that this behaviour is not
configurable/triggered by resources.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message