[ 
https://forge.continuent.org/jira/browse/SEQUOIA-1107?page=comments#action_14646
 ] 

Marc Herbert commented on SEQUOIA-1107:
---------------------------------------

>  As you're not distributed, I'd imagine the last-man-down flag isn't used

Ideally the number of controllers could be dynamic and this distinction would 
then not be possible anymore.

Even in today's static distributions, maybe you could come with scenarios where 
the non-distributed configuration would be "upgraded" to a distributed one. In 
such a case a correctly set last-man-down flag might be welcome.

I see no compelling reason to make an non-distributed exception to the simple, 
robust and straight-forward last-man-down feature.


> 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

Reply via email to