Hello Guillaume,
This was already fixed in 2.10 branch (see
https://forge.continuent.org/jira/browse/SEQUOIA-897), not yet
backported to CVS head.
This is the fix (almost the same as yours) :
if ((backendRecoveryInfo.getCheckpoint() == null)
|| (backendRecoveryInfo.getCheckpoint().length() == 0)
|| (backendRecoveryInfo.getBackendState() != BackendState.DISABLED))
Thank you for your help,
Cheers,
Stephane
Guillaume Smet (JIRA) a écrit :
Backend disabled but still in enabled state for initialize
----------------------------------------------------------
Key: SEQUOIA-901
URL: https://forge.continuent.org/jira/browse/SEQUOIA-901
Project: Sequoia
Type: Bug
Components: Recovery Log
Versions: Sequoia 3.0 beta2
Environment: 1 controller, 1 backend, embedded recovery log
Reporter: Guillaume Smet
Priority: Minor
This bug is related to this thread on the sequoia list:
https://forge.continuent.org/pipermail/sequoia/2007-January/004496.html
The problem:
- stopped the controller without shutdowning anything
- on startup, I have 23:32:56,584 INFO controller.virtualdatabase.test_db
Unexpected enabled state (1) for backend localhost1. Forcing backend to
disabled state.
- but when I try to initialize the backend, I have the following error: Backend
localhost1 is not in a disabled state (current state is enabled)
I've finally found the problem: the disabled state is not stored because the
BackendRecoveryInfo is "" and not null. The test in
RecoveryLog.storeBackendRecoveryInfo doesn't consider the empty string case and the
getCheckpointLogId called in the else clause throws a SQL exception which prevents
Sequoia to store the disabled state in the recovery log.
I attached a patch to fix this problem and to make the recovery log consistent.
--
Guillaume
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
