Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1676709530.1247562914876.JavaMail.jira@brutus>
Date: Tue, 14 Jul 2009 02:15:14 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4299) Slave start fails with message that
 the database is already booted, even when it is not.
In-Reply-To: <1526239638.1247236634836.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.<init>(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/%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.