[jira] [Closed] (AMQ-7164) MasterSlave JDBC redundancy uses broker's system time

["Christopher L. Shannon (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher L. Shannon closed AMQ-7164.
---------------------------------------
    Resolution: Won't Fix

I don't think there is anything to do here as the problem is incorrect system time and is simply a configuration issue.  I suppose something could be mentioned in the documentation but this seems kind of like common sense to me.  Having correct system time is extremely important for a messaging system and I imagine for most other types of networked systems time is important as well to have predictable behavior.

In the case of ActiveMQ there are other features that rely on timestamps as well besides just JDBC. For example, message expiration may not work properly if a client and a broker have differently configured system times as timestamp is used for that as well.

> MasterSlave JDBC redundancy uses broker's system time
> -----------------------------------------------------
>
>                 Key: AMQ-7164
>                 URL: https://issues.apache.org/jira/browse/AMQ-7164
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 5.15.8
>            Reporter: Marius Hentschel
>            Priority: Major
>
> A collegue of mine showed me an an odd behaviour with two brokers connected as Master/Slave via JDBC (on MySQL 5.7) today and we looked a bit into it:
> When the first broker was stopped, the second one didn't take over immediately but only 12 minutes later. We could repeat this.
> When the first broker was then restarted, it immediately took the lock back from the second one, if that was Master yet, causing it to go into slave mode again.
>  When the second one had not yet taken over, the first just took back the lock upon restart.
> As we had multiple similar setups running and not seen a similar behaviour anywhere else, we looked into what's happening on the DB used for the synchronization.
> We discovered that the timestamp, written into the {{activemq_lock}} table's {{TIME}} column was filled, using the system time of the broker writing to it.
>  We could then verify that the NTP synchronization on the 2nd machine was off by the 12 minutes. So the slave broker in its relative past was working as designed, waiting orderly until the lock had expired.
> +TL;DR:+
> The DB's system time should be used as source of truth instead of the individual broker's time, so the brokers just need to ask the DB if the lock is still valid (setting it with {{TIME = SYSDATE + <validity interval>}}, checking if {{TIME < SYSDATE}})
>  A hint in the documentation to keep the time synchronization could probably also solve it :)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)