activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <>
Subject [jira] Commented: (AMQ-2520) Oracle 10g RAC resource usage VERY high from the passive servers SQL requests to the Database.
Date Wed, 10 Feb 2010 11:01:42 GMT


Gary Tully commented on AMQ-2520:

So does the poll work for you by having the lock statement return immediately and hence make
the lockAcquireSleepInterval relevant again. 
We can provide a specialization of the lock implementation for Oracle if this is the case.

> Oracle 10g RAC resource usage VERY high from the passive servers SQL requests to the
> ----------------------------------------------------------------------------------------------
>                 Key: AMQ-2520
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.0, 5.4.0
>         Environment: Redhat Enterprise Linux 5, Oracle 10g RAC
>            Reporter: Tom
> 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
> in the keepAlive method in 
> 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"
> We're currently changing the broker to poll rather than block so in 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 is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message