activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Boemker (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-4564) ActiveMQ creates & initializes ACTIVEMQ_LOCK in wrong database when using separate lock data source
Date Fri, 31 May 2013 13:45:20 GMT

     [ https://issues.apache.org/jira/browse/AMQ-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tim Boemker updated AMQ-4564:
-----------------------------

    Description: When configured to use a secondary database for locking, ActiveMQ creates
and initializes ACTIVEMQ_LOCK in the primary  database.  It then starts as slave because it
can't lock the table in the secondary database.  (was: When configured to use a separate database
for locking, ActiveMQ Cleanup Timer notices that UPDATE ACTIVEMQ_LOCK SET TIME = ... WHERE
ID = ... touches no rows and stops the broker.

I noticed that there is a table named ACTIVEMQ_LOCK in the main database, and that table has
a row in it.  When I copied that row to the instance of ACTIVEMQ_LOCK in the database used
for locking, ActiveMQ ran fine.

ActiveMQ apparently started to initialize ACTIVEMQ_LOCK before it realized that it was supposed
to use a separate data source for locking.

)
        Summary: ActiveMQ creates & initializes ACTIVEMQ_LOCK in wrong database when using
separate lock data source  (was: ActiveMQ fails to hold lock because ACTIVEMQ_LOCK is missing
a row)
    
> ActiveMQ creates & initializes ACTIVEMQ_LOCK in wrong database when using separate
lock data source
> ---------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-4564
>                 URL: https://issues.apache.org/jira/browse/AMQ-4564
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.5.1
>            Reporter: Tim Boemker
>            Priority: Minor
>
> When configured to use a secondary database for locking, ActiveMQ creates and initializes
ACTIVEMQ_LOCK in the primary  database.  It then starts as slave because it can't lock the
table in the secondary database.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message