Mailing-List: contact issues-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 11 Oct 2017 21:39:00 +0000 (UTC)
From: "Volker Kleinschmidt (JIRA)" <jira@apache.org>
To: issues@activemq.apache.org
Message-ID: <JIRA.12483566.1259786443000.32747.1507757940067@Atlassian.JIRA>
In-Reply-To: <JIRA.12483566.1259786443000@Atlassian.JIRA>
References: <JIRA.12483566.1259786443000@Atlassian.JIRA> <JIRA.12483566.1259786443664@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (AMQ-2520) Oracle 10g RAC resource usage
 VERY high from the passive servers SQL requests to the Database.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 11 Oct 2017 21:39:05 -0000


    [ https://issues.apache.org/jira/browse/AMQ-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200986#comment-16200986 ] 

Volker Kleinschmidt edited comment on AMQ-2520 at 10/11/17 9:38 PM:
--------------------------------------------------------------------

Also note that if you use the FOR UPDATE NOWAIT or FOR UPDATE WAIT N forms of the locking query (as should be the default!!!), you will get an exception from the attempt to lock. Currently these are being logged at "info" or "warn" level depending on the locker implementation you use, so they will flood your logs with something that should be perfectly ignored, as this exception is the expected state 99.99% of the time (it should at most be logged at debug level). So there's definitely a need for code change here.


was (Author: volkerk):
Also note that if you use the FOR UPDATE NOWAIT or FOR UPDATE WAIT N forms of the locking query (as should be the default!!!), you will get an exception from the attempt to lock. Currently these are being logged at "warn" level, so they will flood your logs with something that should be perfectly ignored, as this exception is the expected state 99.99% of the time (it should at most be logged at debug level). So there's definitely a need for code change here.

> Oracle 10g RAC resource usage VERY high from the passive servers SQL requests to the Database.
> ----------------------------------------------------------------------------------------------
>
>                 Key: AMQ-2520
>                 URL: https://issues.apache.org/jira/browse/AMQ-2520
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.0, 5.4.0
>         Environment: Redhat Enterprise Linux 5, Oracle 10g RAC
>            Reporter: Thomas Connolly
>             Fix For: 5.x
>
>
> Two active MQ brokers are installed on RH EL 5 servers (one per server). 
> They're configured as a JDBC master / slave failover (as per examples). Failover is tested and working and messages delivered.
> Oracle is used for synchronisation (ACTIVEMQ_ tables), persistence etc.
> We run a durable subscriber, and the client connects via a failover operation.
> The SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE is causing spin lock on the Oracle database.
> Basically the indefinite waiting from the passive mq instance is causing high resource usage on Oracle.
> After a short period Oracle dashboard shows a high number of active sessions from Active MQ due to the continuous execution of
>     UPDATE ACTIVEMQ_LOCK SET TIME = ? WHERE ID = 1
> in the keepAlive method in 
>     https://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/DatabaseLocker.java
> As a workaround we've had to push out the lockAcquireSleepInterval to 5 minutes in the configuration of ActiveMQ, but this didn't work. 
> <jdbcPersistenceAdapter dataSource="#oracle-ds" useDatabaseLock="true" lockAcquireSleepInterval="300000" createTablesOnStartup="true"/>
> We're currently changing the broker to poll rather than block so in Statement.java we've added a WAIT 0 that throws an exception if the lock is not acquired.
>     public String getLockCreateStatement() {
>         if (lockCreateStatement == null) {
>             lockCreateStatement = "SELECT * FROM " + getFullLockTableName();
>             if (useLockCreateWhereClause) {
>                 lockCreateStatement += " WHERE ID = 1";
>             }
>             lockCreateStatement += " FOR UPDATE WAIT 0";
>         }
>         return lockCreateStatement;
>     }
> Any suggestions to this issue, this seems to be a quite fundamental issue?


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)