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:43:28 GMT
Carl Trieloff wrote:
> 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.
> ok, the broker does also have a plug-in system, see ./qpidd --help so if 
> needed you can also plug your server into the daemon if required.

We actually have plug-in transports now (good job Andrew.) Also see 
src/qpid/PlugIn.h for the plug-in framework and look at 
src/qpid/sys/TCPIOPlugin.cpp for an example of a plug-in transport.

Actually this is probably a better point to look at plugging in an  in-memory 
transport, compared to the AMQFrame layer as I suggested in my last mail. It 
means you'll still be paying for encoding/decoding, but on the up side
  - more robust to version changes and refactoring of  the higher level code.
  - fits consistently into the broker threading model.
  - encoded 'blobs' are more portable, e.g. if they end up being tunneled to a 
host with different architecture etc.

The first point is important, I have some memory management/lifecycle 
optimizations in mind would not play nice with passing frames out of the brokers 
dispatch thread.


View raw message