[
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.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.
