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.
- My idea of HA / Load Sharing is borrowed from what I've learn in the
ActiveMQ world (their JDBC master/slave). I would like to have a
master broker (active), in some of the deployed servers, with all the
clients (producers and consumers) in all the servers (or external
clients), using this broker. If some problem arises with this server,
some of the slave ones will adquire the master role (this could be
made relying in some RDBMS locking scheme). The clients will use a
failover schema to cycle between the different existing brokers, until
they find a working one. This way, we will have HA /Load Sharing. Is
this scenario, or something equivalent, possible with qpid? Of
course, we will need a message store that could be seen by all the
clustered brokers, presumably located in a HA RDBMS solution.
- About the RDBMS storage, my idea will be to create a message store
relying in a ODBC driver. Do you think it's feasible? Or is there any
need for the store that a RDBMS could not meet?
There is work currently on active/active clustering, however what you
describe can be achieved with what we have. The is a plug-in store
module for the broker that can be used and if you use something like
Cluster Suite included as part of RHEL, or vertius or something like
that the above pattern can be configured.
Great to know. So, you don't see any problem into sharing the same store
from different brokers. The idea is that when one broker releases the
centralized lock (probably implemented as an select for update of some
well-known table row in the database) some other broker can take the
lock, start, and should be able to use without problems what is stored
in the database tables.
- Another interesting feature will be to be able to have some kind of
direct communication for clients running inside the same process of
the active broker. This is also inspired in the activemq vm tranport,
avoiding a socket communication for in-process clients. This way,
every in-process client would use a failover connector, where one of
the uris will be the in-process one, and the other some regular socket
ones to the other brokers in the cluster.
There is an in process transport that is used for some of the tests, if
you want to see this exposed as a feature, make some more noise...
It should be nice. That way, a lot of overhead will be avoided for
in-process communications. (making noise here).
Is that code already available in the svn ? If so, where is it located?
- The environment to develop / run the solution will be the Solaris
Operating System, using the Sun Studio 12 compilers suite. Is there
any problem with that?
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.
Other than using qpid, I'm considering to develop myself a solution.
But I think that it will be better to contribute to qpid for the
missing parts, if you think that they could be implemented and if this
meets the goals of the project. This is why I sent this mail to the
developers list, because I would like to know the implications of my
needs in terms of development efforts. Things like "yes, you just need
to implement the interface AAAA", or "yes, it can be done, but the
class BBBB should be extended to support this or that".
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?
Thanks again.
Regards
--
Manuel.
Thanks a lot for reading so far.
not an issue.
Carl.
.
