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:
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/MessageStore.h
for recovery:
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/RecoveryManager.h
And then these are the set of data interfaces:
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/PersistableMessage.h
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/PersistableQueue.h
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/PersistableExchange.h
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/PersistableConfig.h
And these then are used to recover the above data interfaces:
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/RecoveredEnqueue.h
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/RecoveredDequeue.h
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/RecoverableTransaction.h
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/RecoverableMessage.h
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/src/qpid/broker/RecoverableConfig.h
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.
regards,
Carl.
