Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 11 May 2011 17:33:47 +0000 (UTC)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1252661793.3713.1305135227618.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-2254) Assert during log file switch: log
 file position exceeded max log file size
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031875#comment-13031875 ] 

Dag H. Wanvik commented on DERBY-2254:
--------------------------------------

Great catch, Rick! Look safe to me, in that the added code could only make the log switch happen earlier. I believe its probably fine to keep the procedure for setting the end position, but I'd suggest running some performance tests so we'd know how much the impact is. Found this double assignment, which is probably a typo (harmless):

> setEndPosition( endPosition = newLog.getFilePointer() );


> Assert during log file switch: log file position exceeded max log file size
> ---------------------------------------------------------------------------
>
>                 Key: DERBY-2254
>                 URL: https://issues.apache.org/jira/browse/DERBY-2254
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.3.1.4
>         Environment: Solaris 10, Java SE 6 build 104 
>            Reporter: Olav Sandstaa
>            Assignee: Rick Hillegas
>              Labels: derby_triage10_5_2
>         Attachments: d2254.zip, derby-2254-01-ab-accountForMoreOverhead.diff
>
>
> When running simple tpc-b like transactions against a embedded Derby based on a SANE build of trunk the following assertion occurs for the background thread and all user threads:
>    org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size
> This seems to occur during a switch to a new log file.
> derby.log contains the following call stack for the background thread:
> Exception trace: 
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size
> 	at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> 	at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530)
> 	at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345)
> 	at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357)
> 	at org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394)
> 	at java.lang.Thread.run(Thread.java:619)
> 2007-01-17 23:09:48.638 GMT Thread[derby.rawStoreDaemon,5,derby.daemons] Cleanup action starting
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size
> 	at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> 	at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530)
> 	at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345)
> 	at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357)
> 	at org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668)
> 	at org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394)
> 	at java.lang.Thread.run(Thread.java:619)
> Cleanup action completed
> For my user threads the call stack is similar:
> Database Class Loader started - derby.database.classpath=''
> 2007-01-17 23:09:36.401 GMT Thread[Thread-51,5,main] (XID = 12632406), (SESSIONID = 51), (DATABASE = /export/home/tmp/derby-db), (DRDAID = null), Cleanup action starting
> 2007-01-17 23:09:36.401 GMT Thread[Thread-51,5,main] (XID = 12632406), (SESSIONID = 51), (DATABASE = /export/home/tmp/derby-db), (DRDAID = null), Failed Statement is: UPDATE accounts SET abal = abal + ? WHERE aid = ? AND bid = ?
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size
> 	at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> 	at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900)
> 	at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530)
> 	at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345)
> 	at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185)
> 	at org.apache.derby.impl.store.raw.data.LoggableActions.doAction(LoggableActions.java:221)
> 	at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:85)
> 	at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8521)
> 	at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1108)
> 	at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:479)
> 	at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523)
> 	at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:566)
> 	at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:260)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:358)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1182)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:299)
> 	at com.sun.derby.perf.clients.tpcb.DBConnection.performTransaction(DBConnection.java:595)
> 	at com.sun.derby.perf.clients.tpcb.Client.run(Client.java:218)
> After this it seems like no user threads are able to connect to the database (not surpricing).
> This happend using a SANE build and I am unsure by just looking at the assertion in the code whether this situation would have been fatal also if I had been using an INSANE build.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira