On Mon, Aug 10, 2009 at 7:04 PM, Aidan Skinner<[email protected]> wrote: > On Fri, Aug 7, 2009 at 4:03 PM, Tom<[email protected]> wrote: > >> I've seen an old thread and the unit tests where an embedded Qpid >> broker is created but wondered if anyone uses this feature in >> production. Obviously memory is a consideration but is there anything >> about the concept that is likely to be unsafe? >> >> AQMP (and Qpid) looks ideal for our environment but initially I might >> find it difficult to justify any extra overhead in administration. As >> familiarity grows, I can see us very quickly moving to a dedicated >> setup and using more of the advanced features. > > I'm not sure what you'd use the broker for if it wasn't accepting TCP > connections. Are you looking to do messaging entirely within the same > process?
I was hoping to start off small by using the broker to handle data for monitoring (rather than commit by migrating existing queues). The only consumers would run in the same vm, either acting as a simple proxy/bridge to a c++ broker [1] or just collecting statistics locally. I have always worked in environments where the broker availability can be more or less guaranteed (J2EE app server or Oracle AQ). If this isn't really practical then it's not a big deal, it was only a short term plan. [1] the proposed Java federation functionality sounds nice. Tom --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
