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)