[
https://issues.apache.org/jira/browse/AMQ-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
metatech updated AMQ-6249:
--------------------------
Attachment: activemq_db_lock_in_intervals_v2.diff
Here is an enhanced version of the patch, which checks for both "stopping" and
"stopped" state, which can happen when the lock query returns an error (for
instance "table does not exist") + log the error in "INFO", otherwise it is not
logged at all by default, which makes troubleshooting more difficult.
> Slave node should try to get lock in small intervals to check JDBC
> connectivity
> -------------------------------------------------------------------------------
>
> Key: AMQ-6249
> URL: https://issues.apache.org/jira/browse/AMQ-6249
> Project: ActiveMQ
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 5.11.1
> Environment: ServiceMix 5.4.1
> Reporter: metatech
> Attachments: activemq_db_lock_in_intervals_v2.diff
>
>
> In a JDBC master/slave configuration, the master node gets the lock in the
> database table ACTIVEMQ_LOCK and becomes active. The slave node tries to get
> the lock and waits indefinitely on the SQL query.
> In case of a network device failure, the TCP connection to the DB server is
> abruptly removed, and no FIN nor RST is sent to the broker. This results
> into a slave node which never resumes from this network issue without manual
> restart of the broker.
> The attached patch transforms the indefinite wait on the lock into a loop in
> small time intervals (defined by the "queryTimeout" variable). Also, it
> becomes possible to specify a TCP socket timeout at the JDBC driver level
> (for instance "oracle.jdbc.ReadTimeout" for Oracle) as an extra safety
> measure.
> In the default case, the "queryTimeout=-1", which falls back to the
> indefinite wait.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
