[
https://issues.apache.org/activemq/browse/SMX4KNL-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie Goodyear updated SMX4KNL-163:
-----------------------------------
Attachment: smx4knl-163b.txt
smx4knl-163b.txt
This patch includes a Default JDBC lock implementation. To use this feature the
following must be set in your environment on each system in the master/slave
setup:
Classpath updated to include JDBC driver.
system.properties file updated to reflect the below entries.
Entries for etc/system.properties:
{noformat}
servicemix.lock=true
servicemix.lock.class=org.apache.servicemix.kernel.main.DefaultJDBCLock
servicemix.lock.jdbc.url=jdbc:derby://dbserver:1527/sample
servicemix.lock.jdbc.driver=org.apache.derby.jdbc.ClientDriver
servicemix.lock.jdbc.user=user
servicemix.lock.jdbc.password=password
servicemix.lock.jdbc.table=SERVICEMIX_LOCK
servicemix.lock.jdbc.clustername=smx4
servicemix.lock.jdbc.timeout=30
{noformat}
Note:
The database name "sample" will be created if it does not exist on the db.
First SMX4 instance to acquire the locking table is the master instance.
Will fail if jdbc driver is not on classpath.
Testing notes:
Was tested with the following setup:
{noformat}
SMX instances on separate hosts:
host1 (SMX4 on AIX)
host2 (SMX4 on Mac OSX)
Standalone Database Server:
dbserver (DerbyDB on Ubuntu)
{noformat}
Disconnecting the AIX machine allowed the Mac to pick up the SMX4 lock. When
AIX servicemix instance was restarted it waited until the Mac instance lost its
lock on the db table lock (Mac was shutdown).
If the database was to go offline then the current master would discover this
via the LockMonitor and shutdown the master instance of SMX. The former master
instance will now require manual restart. The slaves will upon restoration of
the database attempt to connect and start up as per normal. The rational behind
this scenario is that if SMX is setup in a clustered environment then the DB
hosting the lock table will most likely also be Highly Available, loss of the
DB would probably warrant shutting down the currently running SMX instance
leaving the slaves to await DB restoratiion. This feature helps avoid having a
second SMX instance act as master while the original master is still running
(unaware of the loss of jdbc lock).
> Provide default jdbc lock impl for master/slave deployments
> -----------------------------------------------------------
>
> Key: SMX4KNL-163
> URL: https://issues.apache.org/activemq/browse/SMX4KNL-163
> Project: ServiceMix Kernel
> Issue Type: New Feature
> Environment: All
> Reporter: Jamie Goodyear
> Assignee: Jamie Goodyear
> Fix For: 1.1.0
>
> Attachments: for-discussion-only.txt, smx4knl-163.txt,
> smx4knl-163a.txt, smx4knl-163b.txt
>
>
> Provide default jdbc lock impl for master/slave deployments.
> From note on SMX4KNL-106:
> By default, a file based locking mechanism is used. There is an interface
> that can be implemented to allow other locking mechanisms such as JDBC. This
> would require setting a system property for the class name of the lock (it
> can be done in etc/system.properties) and changing the shell script to add
> the needed jars to the boot classpath.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
