Last-man-down error in non-distributed controller
-------------------------------------------------
Key: SEQUOIA-1107
URL: https://forge.continuent.org/jira/browse/SEQUOIA-1107
Project: Sequoia
Type: Bug
Versions: sequoia 2.10.10
Environment: Windows XP, Java 1.5.0_08
Reporter: Andrew Lawrenson
Priority: Minor
If you're running a non-distributed Sequoia Virtual Database(e.g. theres no
Distribution section in the Virtual Database config), it appears you can get an
errant error message about not being able to store the last-man-down flag.
As you're not distributed, I'd imagine the last-man-down flag isn't used,
but it's still generating an invalid error message:
2008-06-24 16:50:08,220 WARN org.continuent.sequoia.controller.recoverylog -
Checkpoint disable all backends-192.168.0.109:6954-20080624165008220+0100 was
stored
2008-06-24 16:50:08,971 WARN org.continuent.sequoia.controller.recoverylog -
Checkpoint shutdown-192.168.0.109:6954-20080624165008971+0100 was stored
2008-06-24 16:50:08,987 ERROR org.continuent.sequoia.controller.shutdown -
Failed to store last-man-down flag.
java.sql.SQLException: The statement was aborted because it would have caused a
duplicate key value in a unique or primary key constraint or unique index
identified by 'SQL080624164859330' defined on 'CHECKPOINT'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
Source)
<snip...>
at
org.continuent.sequoia.controller.recoverylog.RecoveryLog.execDatabaseUpdate(RecoveryLog.java:440)
at
org.continuent.sequoia.controller.recoverylog.RecoveryLog.setLastManDown(RecoveryLog.java:3720)
at
org.continuent.sequoia.controller.core.shutdown.VirtualDatabaseShutdownThread.shutdownCacheRecoveryLogAndGroupCommunication(VirtualDatabaseShutdownThread.java:103)
at
org.continuent.sequoia.controller.core.shutdown.VirtualDatabaseSafeShutdownThread.shutdown(VirtualDatabaseSafeShutdownThread.java:58)
<snip...>
Caused by: ERROR 23505: The statement was aborted because it would have caused
a duplicate key value in a unique or primary key constraint or unique index
identified by 'SQL080624164859330' defined on 'CHECKPOINT'.
at org.apache.derby.iapi.error.StandardException.newException(Unknown
Source)
at
org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown
Source)
at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown
Source)
at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown Source)
at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown
Source)
at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown
Source)
at
org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
Source)
at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown
Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
... 12 more
It looks like the insert of last-man-down is done by the VirtualDatabase (so is
done regardless of whether you're distributed or not), whereas clearing the
last-man-down is only done when starting a DistributedVirtualDatabase, so in a
non-distributed environment, the last-man-down flag set during
Recoverylog.intializeDatabase() is never cleared.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
