You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "metatech (JIRA)" <ji...@apache.org> on 2016/09/01 14:28:20 UTC
[jira] [Updated] (AMQ-6249) Slave node should try to get lock in
small intervals to check JDBC connectivity
[ https://issues.apache.org/jira/browse/AMQ-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
metatech updated AMQ-6249:
--------------------------
Attachment: (was: activemq_db_lock_in_intervals.diff)
> 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)