Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Pluggable ActiveMQ Storage Lockers

DZone's Guide to

Pluggable ActiveMQ Storage Lockers

· Integration Zone
Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

Shared storage master slave broker topologies depend on successful storage locking. Meaning that only a single broker (the master) is active and use the message database. So far locking was tied to a specific message store, so KahaDB was using shared file locking while JDBC store was using a specialized database table to keep slaves from starting. This work fine for the most use cases, but sometimes folks need to use a custom locker (like when the standard file locking doesn’t work on their NFS) or tune existing solutions.

For the upcoming 5.7.0 release we introduced pluggable storage lockers, which means that message storage locking is totally separated from the store itself. That means that you can now use any locking strategy with any store. An example configuration is shown below:

<persistenceAdapter>
    <kahaDB directory = "target/activemq-data">
        <locker>
            <shared-file-locker lockAcquireSleepInterval="5000"/>
        </locker>
    </kahaDB>
</persistenceAdapter>

You can find more details on this new feature here. It will also allow us to implement new locking strategies, based on ZooKeeper for example, which will make high-availability setups even easier. So stay tuned.

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:

Published at DZone with permission of Dejan Bosanac, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}