[jira] Commented: (DERBY-4299) Slave start fails with message that the database is already booted, even when it is not.
[ https://issues.apache.org/jira/browse/DERBY-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730861#action_12730861 ] Knut Anders Hatlen commented on DERBY-4299: --- I also see this if I run with authentication disabled (derby.connection.requireAuthentication), and it seems the reason is that impl.drda.Database.makeDummyConnection() creates a connection with all the connection attributes specified by the client, except user name and password. When authentication is disabled, the default user APP will be allowed to connect to the database, and since startMaster is one of the connection attributes, the master will be started. If authentication is enabled, the creation of the dummy connection will fail, and the master is not started until the real start master (with correct user name and password) is issued right after. The problem with startSlave is similar. It's makeDummyConnection() that's causing the problems there as well, but it doesn't have a problem with authentication being disabled since there is code in EmbedConnection to shut down the database if it was booted just for credentials checking while booting the slave. startSlave's problem is that the APP user must not be a noAccess user in order to be able to shut down the database again. The whole makeDummyConnection() scheme looks broken in the context of replication. Since it's only used to verify whether or not we're allowed to use securityMechanism=8 for the given database, I don't think much harm will be done if we just skip that step for replication commands. It is already coded so that it will report that the security mechanism is OK to use if it cannot be determined (despite comments in DRDAConnThread.validateSecMecUSRSSBPWD() saying the opposite). It is currently only possible to use securityMechanism=8 together with Derby's BUILTIN authentication provider, regardless of replication. > Slave start fails with message that the database is already booted, even when > it is not. > > > Key: DERBY-4299 > URL: https://issues.apache.org/jira/browse/DERBY-4299 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.1.1, 10.6.0.0 > Environment: java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) > SunOS opensolaris 5.11 snv_117 i86pc i386 i86pc Solaris >Reporter: Dag H. Wanvik > Attachments: assert.sh, auth.tar.bz2, reproscript, workingscript > > > Seen by Alan Burlison, cf. > http://mail-archives.apache.org/mod_mbox/db-derby-user/200907.mbox/ajax/%[email protected]%3e > ij> connect > 'jdbc:derby://bleaklow/opensolaris;user=auth;password=CHANGEME;securityMechanism=8;startSlave=true'; > ERROR XRE09: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC: > Cannot start replication slave mode for database 'opensolaris'. The > database has already been booted. > I can reproduce it using Alan's database (thanks, Alan!). When running a > debug build of Derby, however, I hit an ASSERT: > ASSERT FAILED Wrong LogInstant on log record (0,0) version real position > (4,3304) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147) > at > org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:403) > at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204) > at > org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939) > at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949) > at org.apache.derby.impl.store.raw.xact.Xact.destroy(Xact.java:1105) > at > org.apache.derby.impl.store.access.RAMTransaction.destroy(RAMTransaction.java:2030) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(DataDictionaryImpl.java:802) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:214) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333) > at > org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1858) > at > org.apache.derby.
[jira] Commented: (DERBY-4299) Slave start fails with message that the database is already booted, even when it is not.
[
https://issues.apache.org/jira/browse/DERBY-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730805#action_12730805
]
Alan Burlison commented on DERBY-4299:
--
I tried setting the default connection mode to read only in my test database,
and whilst the startSlave worked, the startMaster didn't, failing with:
SQLCODE: -1, SQLSTATE: XRE22, SQLERRMC: opensolarisXRE22 [XRE22]
And in the master log I see:
atabase Class Loader started - derby.database.classpath=''
Replication master role started for database 'opensolaris'.
2009-07-14 11:48:32.184 GMT Thread[DRDAConnThread_5,5,derby.daemons] (XID =
508), (SESSIONID = 3), (DATABASE = opensolaris), (DRDAID = {11}), Cleanup
action starting
java.sql.SQLException: Replication master has already been booted for database
'opensolaris'
:
:
Caused by: ERROR XRE22: Replication master has already been booted for database
'opensolaris'
This is different to the initial failure, when it was the startSlave that was
failing.
If I disable derby.drda.securityMechanism =
STRONG_PASSWORD_SUBSTITUTE_SECURITY, then both the master and slave start OK.
> Slave start fails with message that the database is already booted, even when
> it is not.
>
>
> Key: DERBY-4299
> URL: https://issues.apache.org/jira/browse/DERBY-4299
> Project: Derby
> Issue Type: Bug
> Components: Replication
>Affects Versions: 10.5.1.1, 10.6.0.0
> Environment: java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode)
> SunOS opensolaris 5.11 snv_117 i86pc i386 i86pc Solaris
>Reporter: Dag H. Wanvik
> Attachments: assert.sh, auth.tar.bz2, reproscript, workingscript
>
>
> Seen by Alan Burlison, cf.
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200907.mbox/ajax/%[email protected]%3e
> ij> connect
> 'jdbc:derby://bleaklow/opensolaris;user=auth;password=CHANGEME;securityMechanism=8;startSlave=true';
> ERROR XRE09: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC:
> Cannot start replication slave mode for database 'opensolaris'. The
> database has already been booted.
> I can reproduce it using Alan's database (thanks, Alan!). When running a
> debug build of Derby, however, I hit an ASSERT:
> ASSERT FAILED Wrong LogInstant on log record (0,0) version real position
> (4,3304)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
> at
> org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:403)
> at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204)
> at
> org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939)
> at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949)
> at org.apache.derby.impl.store.raw.xact.Xact.destroy(Xact.java:1105)
> at
> org.apache.derby.impl.store.access.RAMTransaction.destroy(RAMTransaction.java:2030)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(DataDictionaryImpl.java:802)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021)
> at
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573)
> at
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
> at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:214)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021)
> at
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1858)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1724)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1602)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:1021)
> at
> org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2580)
> so there seems to be an issue with the log. It could be related to
> DERBY-3896. In Alan's original repre he used client/Server mode, but I can
> reproduce the error with embedded more, cf. the attached script.
--
This message is automatically generated by JIRA.
-
You can reply to this email to
[jira] Commented: (DERBY-4299) Slave start fails with message that the database is already booted, even when it is not.
[
https://issues.apache.org/jira/browse/DERBY-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730753#action_12730753
]
Knut Anders Hatlen commented on DERBY-4299:
---
The problem appears to be related to the fact that the attached database has
noAccess as default connection mode. Changing this to readOnlyAccess with the
statement below made the problem go away.
call
syscs_util.syscs_set_database_property('derby.database.defaultConnectionMode',
'readOnlyAccess');
> Slave start fails with message that the database is already booted, even when
> it is not.
>
>
> Key: DERBY-4299
> URL: https://issues.apache.org/jira/browse/DERBY-4299
> Project: Derby
> Issue Type: Bug
> Components: Replication
>Affects Versions: 10.5.1.1, 10.6.0.0
> Environment: java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode)
> SunOS opensolaris 5.11 snv_117 i86pc i386 i86pc Solaris
>Reporter: Dag H. Wanvik
> Attachments: assert.sh, auth.tar.bz2, reproscript, workingscript
>
>
> Seen by Alan Burlison, cf.
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200907.mbox/ajax/%[email protected]%3e
> ij> connect
> 'jdbc:derby://bleaklow/opensolaris;user=auth;password=CHANGEME;securityMechanism=8;startSlave=true';
> ERROR XRE09: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC:
> Cannot start replication slave mode for database 'opensolaris'. The
> database has already been booted.
> I can reproduce it using Alan's database (thanks, Alan!). When running a
> debug build of Derby, however, I hit an ASSERT:
> ASSERT FAILED Wrong LogInstant on log record (0,0) version real position
> (4,3304)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
> at
> org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:403)
> at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204)
> at
> org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939)
> at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949)
> at org.apache.derby.impl.store.raw.xact.Xact.destroy(Xact.java:1105)
> at
> org.apache.derby.impl.store.access.RAMTransaction.destroy(RAMTransaction.java:2030)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(DataDictionaryImpl.java:802)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021)
> at
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573)
> at
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
> at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:214)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021)
> at
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1858)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1724)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1602)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:1021)
> at
> org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2580)
> so there seems to be an issue with the log. It could be related to
> DERBY-3896. In Alan's original repre he used client/Server mode, but I can
> reproduce the error with embedded more, cf. the attached script.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4299) Slave start fails with message that the database is already booted, even when it is not.
[
https://issues.apache.org/jira/browse/DERBY-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730744#action_12730744
]
Knut Anders Hatlen commented on DERBY-4299:
---
EmbedConnection has code to ensure that the database is stopped before
proceeding with startSlave after checking credentials:
// Check User's credentials and if it is a valid user of
// the database
//
try {
checkUserCredentials(tr.getDBName(), info);
} catch (SQLException sqle) {
if (isStartSlaveBoot && !slaveDBAlreadyBooted) {
// Failing credentials check on a previously
// unbooted db should not leave the db booted
// for startSlave command.
// tr.startTransaction is needed to get the
// Database context. Without this context,
// handleException will not shutdown the
// database
tr.startTransaction();
handleException(tr.shutdownDatabaseException());
}
throw sqle;
}
When using securityMechanism=8, the above will actually fail (expectedly) in
checkUserCredentials() and the code in the catch block will be executed. With a
database I created myself, it successfully shut down the database. However,
with the attached database, the call to startTransaction() fails with the stack
trace below, and we never get to the code that shuts down the open database.
ERROR 08004: Database connection refused.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276)
at
org.apache.derby.impl.sql.conn.GenericAuthorizer.refresh(GenericAuthorizer.java:323)
at
org.apache.derby.impl.sql.conn.GenericAuthorizer.(GenericAuthorizer.java:73)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(GenericLanguageConnectionContext.java:350)
at
org.apache.derby.impl.db.BasicDatabase.setupConnection(BasicDatabase.java:309)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(TransactionResourceImpl.java:188)
> Slave start fails with message that the database is already booted, even when
> it is not.
>
>
> Key: DERBY-4299
> URL: https://issues.apache.org/jira/browse/DERBY-4299
> Project: Derby
> Issue Type: Bug
> Components: Replication
>Affects Versions: 10.5.1.1, 10.6.0.0
> Environment: java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode)
> SunOS opensolaris 5.11 snv_117 i86pc i386 i86pc Solaris
>Reporter: Dag H. Wanvik
> Attachments: assert.sh, auth.tar.bz2, reproscript, workingscript
>
>
> Seen by Alan Burlison, cf.
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200907.mbox/ajax/%[email protected]%3e
> ij> connect
> 'jdbc:derby://bleaklow/opensolaris;user=auth;password=CHANGEME;securityMechanism=8;startSlave=true';
> ERROR XRE09: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC:
> Cannot start replication slave mode for database 'opensolaris'. The
> database has already been booted.
> I can reproduce it using Alan's database (thanks, Alan!). When running a
> debug build of Derby, however, I hit an ASSERT:
> ASSERT FAILED Wrong LogInstant on log record (0,0) version real position
> (4,3304)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
> at
> org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:403)
> at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204)
> at
> org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939)
> at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949)
> at org.apache.derby.impl.store.raw.xact.Xact.destroy(Xact.java:1105)
> at
> org.apache.derby.impl.store.access.RAMTransaction.destroy(RAMTransaction.java:2030)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(DataDictionaryImpl.java:802)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021)
> at
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573)
> at
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
> at org.apache.derby.impl.db.BasicDat
[jira] Commented: (DERBY-4299) Slave start fails with message that the database is already booted, even when it is not.
[ https://issues.apache.org/jira/browse/DERBY-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730374#action_12730374 ] Knut Anders Hatlen commented on DERBY-4299: --- I think the assert failure may be a red herring. (It may still be a problem though.) Alan sent me a copy of the database, and if I perform a clean shutdown on it, the assert failure goes away, but the database already booted error is still seen in a client/server environment. Removing securityMechanism=8 from the connection URL makes it possible to start the slave, so it seems like network server boots the database to check the credentials and leaves it open so that start slave fails. But there must be something more to it, as the thread on derby-user shows that it is possible to start a slave on another database with authentication+authorization+securityMechanism=8. > Slave start fails with message that the database is already booted, even when > it is not. > > > Key: DERBY-4299 > URL: https://issues.apache.org/jira/browse/DERBY-4299 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.1.1, 10.6.0.0 > Environment: java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) > SunOS opensolaris 5.11 snv_117 i86pc i386 i86pc Solaris >Reporter: Dag H. Wanvik > Attachments: assert.sh, auth.tar.bz2, reproscript, workingscript > > > Seen by Alan Burlison, cf. > http://mail-archives.apache.org/mod_mbox/db-derby-user/200907.mbox/ajax/%[email protected]%3e > ij> connect > 'jdbc:derby://bleaklow/opensolaris;user=auth;password=CHANGEME;securityMechanism=8;startSlave=true'; > ERROR XRE09: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC: > Cannot start replication slave mode for database 'opensolaris'. The > database has already been booted. > I can reproduce it using Alan's database (thanks, Alan!). When running a > debug build of Derby, however, I hit an ASSERT: > ASSERT FAILED Wrong LogInstant on log record (0,0) version real position > (4,3304) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147) > at > org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:403) > at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204) > at > org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939) > at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949) > at org.apache.derby.impl.store.raw.xact.Xact.destroy(Xact.java:1105) > at > org.apache.derby.impl.store.access.RAMTransaction.destroy(RAMTransaction.java:2030) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(DataDictionaryImpl.java:802) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:214) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333) > at > org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1858) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1724) > at > org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1602) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:1021) > at > org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) > at > org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2580) > so there seems to be an issue with the log. It could be related to > DERBY-3896. In Alan's original repre he used client/Server mode, but I can > reproduce the error with embedded more, cf. the attached script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4299) Slave start fails with message that the database is already booted, even when it is not.
[ https://issues.apache.org/jira/browse/DERBY-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730169#action_12730169 ] Dag H. Wanvik commented on DERBY-4299: -- Knut> I'm unchecking "Repro attached" since the repro appears to Knut> depend on one particular database that's not attached. I've I was going to ask Alan if I could attach it, but until such time, this is fine. Dag Knut> tried to reconstruct one that reproduces the problem based on Knut> the description in the derby-user thread, but with no luck so Knut> far. > Slave start fails with message that the database is already booted, even when > it is not. > > > Key: DERBY-4299 > URL: https://issues.apache.org/jira/browse/DERBY-4299 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.1.1, 10.6.0.0 > Environment: java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) > SunOS opensolaris 5.11 snv_117 i86pc i386 i86pc Solaris >Reporter: Dag H. Wanvik > Attachments: reproscript, workingscript > > > Seen by Alan Burlison, cf. > http://mail-archives.apache.org/mod_mbox/db-derby-user/200907.mbox/ajax/%[email protected]%3e > ij> connect > 'jdbc:derby://bleaklow/opensolaris;user=auth;password=CHANGEME;securityMechanism=8;startSlave=true'; > ERROR XRE09: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC: > Cannot start replication slave mode for database 'opensolaris'. The > database has already been booted. > I can reproduce it using Alan's database (thanks, Alan!). When running a > debug build of Derby, however, I hit an ASSERT: > ASSERT FAILED Wrong LogInstant on log record (0,0) version real position > (4,3304) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147) > at > org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:403) > at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204) > at > org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939) > at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949) > at org.apache.derby.impl.store.raw.xact.Xact.destroy(Xact.java:1105) > at > org.apache.derby.impl.store.access.RAMTransaction.destroy(RAMTransaction.java:2030) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(DataDictionaryImpl.java:802) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:214) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333) > at > org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1858) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1724) > at > org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1602) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:1021) > at > org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) > at > org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2580) > so there seems to be an issue with the log. It could be related to > DERBY-3896. In Alan's original repre he used client/Server mode, but I can > reproduce the error with embedded more, cf. the attached script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4299) Slave start fails with message that the database is already booted, even when it is not.
[ https://issues.apache.org/jira/browse/DERBY-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729739#action_12729739 ] Dag H. Wanvik commented on DERBY-4299: -- Actually, the *solution* duplicates DERBY-3896: shut down database cleanly before copying to the slave. Clearly it fails in another way here. It may be best to keep it open for a while, reopening. > Slave start fails with message that the database is already booted, even when > it is not. > > > Key: DERBY-4299 > URL: https://issues.apache.org/jira/browse/DERBY-4299 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.5.1.1, 10.6.0.0 > Environment: java version "1.6.0_13" > Java(TM) SE Runtime Environment (build 1.6.0_13-b03) > Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode) > SunOS opensolaris 5.11 snv_117 i86pc i386 i86pc Solaris >Reporter: Dag H. Wanvik > Attachments: reproscript, workingscript > > > Seen by Alan Burlison, cf. > http://mail-archives.apache.org/mod_mbox/db-derby-user/200907.mbox/ajax/%[email protected]%3e > ij> connect > 'jdbc:derby://bleaklow/opensolaris;user=auth;password=CHANGEME;securityMechanism=8;startSlave=true'; > ERROR XRE09: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC: > Cannot start replication slave mode for database 'opensolaris'. The > database has already been booted. > I can reproduce it using Alan's database (thanks, Alan!). When running a > debug build of Derby, however, I hit an ASSERT: > ASSERT FAILED Wrong LogInstant on log record (0,0) version real position > (4,3304) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147) > at > org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:403) > at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204) > at > org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939) > at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949) > at org.apache.derby.impl.store.raw.xact.Xact.destroy(Xact.java:1105) > at > org.apache.derby.impl.store.access.RAMTransaction.destroy(RAMTransaction.java:2030) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(DataDictionaryImpl.java:802) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) > at > org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427) > at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:214) > at > org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) > at > org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:333) > at > org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1858) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1724) > at > org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1602) > at > org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:1021) > at > org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) > at > org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2580) > so there seems to be an issue with the log. It could be related to > DERBY-3896. In Alan's original repre he used client/Server mode, but I can > reproduce the error with embedded more, cf. the attached script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
