Hi Andrew,
Thanks for the report. Which version of Sequoia are you using?
If you are using the last stable version, please file a JIRA entry so
that we can track down this issue.
Thanks again,
Emmanuel
A minor error/annoyance to report:
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.
thanks,
Andrew Lawrenson
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
