db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4299) Slave start fails with message that the database is already booted, even when it is not.
Date Tue, 14 Jul 2009 14:06:14 GMT

    [ 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/%3c4A522D68.50401@sun.com%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.


Mime
View raw message