qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Greetings and questions
Date Mon, 26 May 2008 12:36:48 GMT
Manuel Teira wrote:
> Carl Trieloff escribió:
>>
>>
>> Currently the C++ broker can run as a daemon and broker. There is no
>> option to load it into another container. What C++ container are you
>> thinking off?
>>
>> The daemon does have things like stop etc.
>>   
> It's a simple container, as in my framework, services (exposing 
> start/stop) semantics, are deployed as plugins, and the core application 
> loads them and controls their lifecycle. I've seen the daemon code, and 
> seems feasible. The need for this is that I want the broker embedded as 
> another component of my server process. Hence, the question about the 
> in-process transport.
> 

It's quite simple to embed the broker in something else, our test harness 
already does this so it can start up an in-process broker for unit testing. Look 
at cpp/tests/BrokerFixture.

The test framework above actually used to implement a simple in-memory 
transport, but it was converted to use the loopback interface. The in-memory 
transport was too different from normal network transport when it came to 
testing behavior around network failures, disconnects etc. Also it introduced 
thread timing restrictions which caused different behavior esp. in error conditions.

The client and broker both use the same in-memory representation for AMQP frames 
(class qpid/framing/AMQFrame) so you can feed them from broker to client & 
vice-versa. If you want to see how the in-process transport used to work, look 
at the svn log for BrokerFixture and check the revision before it was 
introduced. May  not work exactly the same now, but should be reasonably close.

I'd suggest starting with the loopback interface (127.0.0.1) though, and 
consider in-memory only if you find a measurable performance problem.

Cheers,
Alan.

Mime
View raw message