qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: Greetings and questions
Date Fri, 23 May 2008 15:58:50 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.

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.

>> no idea - maybe someone else on list has tried, I expect it should not
>> be that much work to get it building on Solaris -- Andrew is the one to
>> hit up on that. The store might be
>> a bit more complicated, you might want to consider doing an impl of the
>> store interface for ODBC.
> Well, I gave it a first try, and was not successful. I installed ruby 
> and python (this last one not mentioned as a dependency, however it is 
> used for the automatic code generation too) and commented out the 
> AC_CHECK_PROG for help2man, just to make a fast test at compiling the 
> C++ part, and errores arised for the first compilation attempt.
> "./qpid/framing/amqp_types.h", line 38: Error: Could not open include 
> file<stdint.h>.
> This one is for that file lacking in solaris 9. Not an issue.
> I've got another boost related errors, but I think they could be 
> related with my solaris setup for boost. Will try tomorrow in a 
> solaris 10 machine.

ok, let us know how it goes - newer versions of boost == less pain :-)

>> from discription items would be
>> - create Actice/Passive scripts for your env
>> - build project on Sun -- and implications of that. should not be that
>> bad as Linus and Sun are both posix.
>> - port a store module, or just impl a ODBC interface for the store
>> interface.
> About the first item, passive/active is more an automatic feature. 
> Different servers will start, trying to adquire the RDBMS lock, only 
> actually starting the broker the one that gets the lock. If this 
> server dies or lose contact with the RDBMS, another one will take the 
> lock and start its embedded broker. Clients connected to the first 
> broker will lost their connection, to failover to some other one.
> Where is the store interface specified? And the current implementations?

The two interfaces are:

for recovery:

And then these are the set of data interfaces:

And these then are used to recover the above data interfaces:

Fastest would be to take the bdb code path and translate it into ODBC 
from this
store: https://svn.jboss.org/repos/rhmessaging/store/trunk/cpp

If you use an ASL compat impl of ODBC, we could commit that back to the 
qpid repo.

View raw message