[
https://issues.apache.org/activemq/browse/AMQ-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom updated AMQ-2520:
---------------------
Description:
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"/>
Any suggestions to this issue, this seems to be a quite fundamental issue?
was:
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.
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.
<jdbcPersistenceAdapter dataSource="#oracle-ds" useDatabaseLock="true"
lockAcquireSleepInterval="300000" createTablesOnStartup="true"/>
Any suggestions to this issue?
> Oracle 10g RAC resource usage VERY high from the passive servers keepAlive
> requests to the Database.
> ----------------------------------------------------------------------------------------------------
>
> Key: AMQ-2520
> URL: https://issues.apache.org/activemq/browse/AMQ-2520
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.3.0
> Environment: Redhat Enterprise Linux 5, Oracle 10g RAC
> Reporter: Tom
> Priority: Blocker
>
> 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"/>
> 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.
