You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Hiram Chirino (JIRA)" <ji...@apache.org> on 2006/11/13 22:43:07 UTC
[jira] Updated: (AMQ-732) Infinite recovery loop.
[ https://issues.apache.org/activemq/browse/AMQ-732?page=all ]
Hiram Chirino updated AMQ-732:
------------------------------
Fix Version/s: 4.2
(was: 4.1.0)
> Infinite recovery loop.
> -----------------------
>
> Key: AMQ-732
> URL: https://issues.apache.org/activemq/browse/AMQ-732
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 4.0
> Environment: Linux RHEL 3
> Reporter: Maxim Fateev
> Assigned To: Hiram Chirino
> Fix For: 4.2.0, 4.0.3
>
> Attachments: activemq-data-1-journal.tar.gz, activemq-data-2-journal.tar.gz
>
>
> The simplest way to reproduce the problem:
> 1. Remove storage directory.
> 2. Start broker using the following code:
> public static void main(String[] args) throws Exception {
> BrokerService broker = new BrokerService();
> broker.setPersistent(true);
> DefaultPersistenceAdapterFactory pFactory = new DefaultPersistenceAdapterFactory();
> pFactory.setJournalLogFiles(1);
> pFactory.setJournalLogFileSize(2048);
> broker.setPersistenceFactory(pFactory);
> broker.setUseJmx(false);
> broker.addConnector("tcp://localhost:61616");
> broker.start();
> Thread.sleep(1000000000000l);
> }
> 3. Shutdown the broker.
> 4. Start broker.
> It enters infinite loop
> [ main] BrokerService INFO ActiveMQ null JMS Message Broker (localhost) is starting
> [ main] BrokerService INFO For help or more information please see: http://incubator.apache.org/activemq/
> [ main] JDBCPersistenceAdapter INFO Database driver recognized: [apache_derby_embedded_jdbc_driver]
> [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, PRIMARY KEY ( ID ) )
> [ main] DefaultJDBCAdapter DEBUG Could not create JDBC tables; The message table already existed. Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in Schema 'APP'. SQLState: X0Y32 Vendor code: 20000
> [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS (MSGID_PROD,MSGID_SEQ)
> [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
> [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
> [ main] DefaultJDBCAdapter DEBUG Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME))
> [ main] DefaultJDBCAdapter DEBUG Could not create JDBC tables; The message table already existed. Failure was: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME)) Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState: X0Y32 Vendor code: 20000
> [ main] JDBCPersistenceAdapter DEBUG Cleaning up old messages.
> [ main] DefaultJDBCAdapter DEBUG Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION<>0 AND EXPIRATION<?) OR ID <= ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
> [ main] DefaultJDBCAdapter DEBUG Deleted 0 old message(s).
> [ main] JDBCPersistenceAdapter DEBUG Cleanup done.
> [ main] JournalPersistenceAdapter INFO Journal Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at: /workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
> [ main] JournalPersistenceAdapter DEBUG TRACE Entry: RECOVERED
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=53
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=97
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation overflowing into next logFile=0
> [ main] JournalPersistenceAdapter DEBUG TRACE Entry: RECOVERED
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=53
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=97
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation overflowing into next logFile=0
> [ main] JournalPersistenceAdapter DEBUG TRACE Entry: RECOVERED
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=53
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation offset=97
> [ Journal Writer] LogFileManager DEBUG getNextDataRecordLocation overflowing into next logFile=0
> The log entry from getNextDataRecordLocation is coming from log statement I've added to LogFileManager.getNextDataRecordLocation:
> public Location getNextDataRecordLocation(Location lastLocation) throws IOException, InvalidRecordLocationException {
> RecordInfo ri = readRecordInfo(lastLocation);
> while (true) {
> int logFileId = ri.getLocation().getLogFileId();
> int offset = ri.getNextLocation();
> log.debug("getNextDataRecordLocation offset=" + offset);
> // Are we overflowing into next logFile?
> if (offset >= ri.getLogFileState().getAppendOffset()) {
> LogFileNode nextActive = ri.getLogFileState().getNextActive();
> log.debug("getNextDataRecordLocation overflowing into next logFile=" + (nextActive == null ? "null" : String.valueOf(nextActive.getId())));
> if (nextActive == null) {
> return null;
> }
> logFileId = nextActive.getId();
> offset = 0;
> }
> try {
> ri = readRecordInfo(new Location(logFileId, offset));
> } catch (InvalidRecordLocationException e) {
> return null;
> }
> // Is the next record the right record type?
> if (ri.getHeader().getRecordType() == DATA_RECORD_TYPE) {
> return ri.getLocation();
> }
> // No? go onto the next record.
> }
> }
> It looks like recovery doesn't take into account that journaling storage file should have some end at some point.
> Similar problem happens if multiple files of bigger size are used. It happens every time one of the log files grows bigger then size specified in pFactory.setJournalLogFileSize(...) call.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira