Author: buildbot
Date: Fri Mar 28 13:23:04 2014
New Revision: 904062
Log:
Production update by buildbot for activemq
Modified:
websites/production/activemq/content/cache/main.pageCache
websites/production/activemq/content/pluggable-storage-lockers.html
Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/activemq/content/pluggable-storage-lockers.html
==============================================================================
--- websites/production/activemq/content/pluggable-storage-lockers.html
(original)
+++ websites/production/activemq/content/pluggable-storage-lockers.html Fri Mar
28 13:23:04 2014
@@ -106,7 +106,7 @@
</locker>
</jdbcPersistenceAdapter>
</persistenceAdapter>]]></script>
-</div></div><p>In order for this mechanism to work correctly, each broker in
the master/slave pair must have a different <code>brokerName</code> attribute
defined on the <code>broker</code> tag, as it is this value that is used to
reserve a lease.</p><p>The lease based lock is acquired by blocking at startup.
It is then retained for a period whose duration (in ms) is given by the
<code>lockKeepAlivePeriod</code> attribute. To retain the lock the master
broker periodically extends its lease by <code>lockAcquireSleepInterval</code>
milliseconds each time. In theory, therefore, the master broker is always
(<code>lockAcquireSleepInterval</code> <code>-</code>
<code>lockKeepAlivePeriod</code>) ahead of the slave broker with regard to the
lease. It is imperative that <code>lockAcquireSleepInterval >
lockKeepAlivePeriod</code>, to ensure the lease is always current. As of
ActiveMQ 5.9.0 a warning message is logged if this condition is not
met.</p><p>In the simplest case, the clocks
between master and slave must be in sync for this solution to work properly.
If the clocks cannot be in sync, the locker can use the system time from the
database CURRENT TIME and adjust the timeouts in accordance with their local
variance from the db system time.
If <code>maxAllowableDiffFromDBTime</code> is greater than zero the local
periods will be adjusted by any delta that exceeds
<code>maxAllowableDiffFromDBTime</code>.</p> <div class="aui-message hint
shadowed information-macro">
+</div></div><p>In order for this mechanism to work correctly, each broker in
the master/slave pair must have a different <code>brokerName</code> attribute
defined on the <code>broker</code> tag or use the <code><span
style="line-height: 1.4285715;">lease-database-locker </span></code><span
style="line-height: 1.4285715;"><code>leaseHolderId</code> attribute, as it is
this value that is used to reserve a lease.</span></p><p>The lease based lock
is acquired by blocking at startup. It is then retained for a period whose
duration (in ms) is given by the <code>lockKeepAlivePeriod</code> attribute. To
retain the lock the master broker periodically extends its lease by
<code>lockAcquireSleepInterval</code> milliseconds each time. In theory,
therefore, the master broker is always
(<code>lockAcquireSleepInterval</code> <code>-</code>
<code>lockKeepAlivePeriod</code>) ahead of the slave broker with regard to the
lease. It is imperative that <code>lockAcquireSleepInterval > lockKe
epAlivePeriod</code>, to ensure the lease is always current. As of ActiveMQ
5.9.0 a warning message is logged if this condition is not met.</p><p>In the
simplest case, the clocks between master and slave must be in sync for this
solution to work properly. If the clocks cannot be in sync, the locker can use
the system time from the database CURRENT TIME and adjust the timeouts in
accordance with their local variance from the db system time.
If <code>maxAllowableDiffFromDBTime</code> is greater than zero the local
periods will be adjusted by any delta that exceeds
<code>maxAllowableDiffFromDBTime</code>.</p> <div class="aui-message hint
shadowed information-macro">
<span class="aui-icon icon-hint">Icon</span>
<div class="message-content">
<p>It is important to know if the default rules
your JDBC driver uses for converting TIME values are JDBC compliant. If you're
using MySQL, for example, the driver's JDBC URL should
contain <code>useJDBCCompliantTimezoneShift=true</code> to ensure that
TIME value conversion is JDBC compliant. If not the locker could report a large
time difference when it compares the retrieved lease expiration time against
the current system time. Consult your JDBC driver's manual for more details.</p>
