Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 89163 invoked from network); 9 Feb 2010 16:33:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Feb 2010 16:33:52 -0000 Received: (qmail 88274 invoked by uid 500); 9 Feb 2010 16:33:52 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 88210 invoked by uid 500); 9 Feb 2010 16:33:52 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 88202 invoked by uid 99); 9 Feb 2010 16:33:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2010 16:33:52 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2010 16:33:49 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id E9C0D29A0013 for ; Tue, 9 Feb 2010 08:33:27 -0800 (PST) Message-ID: <487569023.152711265733207956.JavaMail.jira@brutus.apache.org> Date: Tue, 9 Feb 2010 16:33:27 +0000 (UTC) From: "Knut Anders Hatlen (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives In-Reply-To: <1662950346.1213883025280.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831525#action_12831525 ] Knut Anders Hatlen commented on DERBY-3729: ------------------------------------------- I would feel more comfortable with this solution than downgrading the severity of this particular error. For database-level errors, I think we automatically shut down the database so that nothing more harmful should happen to it until we've performed recovery. I don't know the consequences of not doing that. > Error message is rather unrevealing when creating large databases on FAT32 drives > --------------------------------------------------------------------------------- > > Key: DERBY-3729 > URL: https://issues.apache.org/jira/browse/DERBY-3729 > Project: Derby > Issue Type: Improvement > Components: Network Client > Affects Versions: 10.3.3.0 > Environment: Windows XP with a FAT32 drive > Reporter: Jason C. Cole > Assignee: Bryan Pendleton > Priority: Minor > Attachments: clientServer_derby.log, clientSQLException.txt, embedded_derby.log, embeddedSQLException.txt, enhanceErrorMessage.diff, repro.java, reproEmbedded.java > > > I was creating a test database on an external USB drive formatted as FAT32- it contains some tables that have quite large binary objects in: This was in conjunction with Hibernate. I got this rather cryptic error message. > Looks rather scary: > 18:02:37,550 WARN JDBCExceptionReporter:77 - SQL Error: 40000, SQLState: 08006 > 18:02:37,550 ERROR JDBCExceptionReporter:78 - A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message > 18:02:37,597 ERROR AbstractFlushingEventListener:301 - Could not synchronize database state with session > org.hibernate.exception.JDBCConnectionException: could not insert: [proteinChainMoleculeBinaryData] > at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:74) > at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister. > java:2263) > at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2656) > at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:52) > at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139) > at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) > at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) > at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) > at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) > Initially it didnt even occur to me that this may be due to me using a FAT32 drive, but eventually I figured out that the table's file had got to the operating FAT32 limit: I had a file of 4,194,272 KB. > In the derby log, there's a more revealing, but still incorrect, error message: > ERROR XSDG1: Page Page(131071,Container(0, 2384)) could not be written to disk, please check if disk is full. > at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) > at org.apache.derby.impl.store.raw.data.CachedPage.writePage(Unknown Source) > at org.apache.derby.impl.store.raw.data.CachedPage.createIdentity(Unknown Source) > at org.apache.derby.impl.services.cache.CachedItem.takeOnIdentity(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.addEntry(Unknown Source) > at org.apache.derby.impl.services.cache.Clock.create(Unknown Source) > at org.apache.derby.impl.store.raw.data.FileContainer.initPage(Unknown Source) > at org.apache.derby.impl.store.raw.data.FileContainer.newPage(Unknown Source) > at org.apache.derby.impl.store.raw.data.BaseContainer.addPage(Unknown Source) > at org.apache.derby.impl.store.raw.data.StoredPage.getNewOverflowPage(Unknown Source) > at org.apache.derby.impl.store.raw.data.BasePage.insertLongColumn(Unknown Source) > at org.apache.derby.impl.store.raw.data.BasePage.insertAllowOverflow(Unknown Source) > at org.apache.derby.impl.store.raw.data.BasePage.insert(Unknown Source) > at org.apache.derby.impl.store.access.heap.HeapController.doInsert(Unknown Source) > at org.apache.derby.impl.store.access.heap.HeapController.insertAndFetchLocation(Unknown Source) > at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown Source) > at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown Source) > at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) > at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source) > at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source) > at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source) > at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) > at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) > Caused by: java.io.IOException: There is not enough space on the disk > at sun.nio.ch.FileDispatcher.pwrite0(Native Method) > at sun.nio.ch.FileDispatcher.pwrite(FileDispatcher.java:51) > at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:100) > at sun.nio.ch.IOUtil.write(IOUtil.java:75) > at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:651) > at org.apache.derby.impl.store.raw.data.RAFContainer4.writeFull(Unknown Source) > at org.apache.derby.impl.store.raw.data.RAFContainer4.writePage0(Unknown Source) > at org.apache.derby.impl.store.raw.data.RAFContainer4.writePage(Unknown Source) > ... 26 more > The error is still strictly speaking incorrect - my disk is far from full, but I have created a file too big for the disk type - but the error is at least closer to the truth and this would be useful information for the derby client to display rather than the rather scary looking message I was getting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.