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: Embedded Java broker
Date Tue, 11 Aug 2009 12:52:22 GMT
Hi Tom,

There's no reason why you can't do this with the Java broker. We'd recommend
a large heap (3GB on 32bit OS) so you have headroom for your broker memory

We use inVM brokers extensively for testing and there's nothing inherently
unsafe about it.

This isn't a scenario (afaik) that we test though so we'd say test it out !


On Tue, Aug 11, 2009 at 10:03 AM, Tom <808131@gmail.com> wrote:

> On Mon, Aug 10, 2009 at 7:04 PM, Aidan Skinner<aidan.skinner@gmail.com>
> wrote:
> > On Fri, Aug 7, 2009 at 4:03 PM, Tom<808131@gmail.com> 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:users-subscribe@qpid.apache.org

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