On 5/19/07, Christopher G. Stach II <[EMAIL PROTECTED]> wrote:
James Strachan wrote:
>
> Thanks for the heads up! :)
>
> I guess we could make the locking strategy pluggable & we could have
> some implementation call the fcntl locking. e.g. maybe using Jtux
>
> http://www.basepath.com/aup/jtux/
>
Even though one could achieve this, I don't know what the benefit would
be.
Allow folks to run multiple broker instances on a shared file system
so that if one broker fails, another takes over.
http://activemq.apache.org/shared-file-system-master-slave.html
It only shifts the responsibility down. At least the user would
want a broker that is dependent on one or more brokers. Each of those
brokers shouldn't be dependent on each other for locking, data, or
anything else. I can appreciate that some people assume that shared
data is available, but shared data is just as easily corrupted, locked,
or unavailable. Essentially, when you find a single responsibility and
divide it, it probably shouldn't converge somewhere down the line. This
current pattern is most likely unusable for any HA situation.
Agreed - I'd much prefer a share nothing HA strategy where folks can
spin up and down brokers at any point in time and everything just
works (tm) with messages replicated onto multiple physical stores and
things auto-partitioning etc.
However we're not there yet, so its a question of trade-offs. Some
folks find it easier to rely on their shared file system / SAN to do
the HA; others can use the share-nothing approach in ActiveMQ (Pure
Master Slave)...
http://activemq.apache.org/masterslave.html
and live with the current limitations (no automatic fail-back of the
old master when it is brought back online).
Like many things in IT its a tradeoff. For now, today, the shared file
system approach is a pretty reasonable approach; if you already have a
reliable distributed file system (particularly if you have a SAN).
--
James
-------
http://macstrac.blogspot.com/
