[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832469#action_12832469 ] Knut Anders Hatlen commented on DERBY-3729: --- The patch looks like an improvement to me. +1. As far as I can see from DRDAConnThread.writeSQLCARDs(), a CMDCHKRM is always followed by an SQLCARD, so the change in NetConnectionReply should be safe. > 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, UpdateMessagesImproveClient.diff > > > 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: 4, 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 > o
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831573#action_12831573 ] Knut Anders Hatlen commented on DERBY-3729: --- Sounds like a good plan! +1 > 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: 4, 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
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[
https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831565#action_12831565
]
Bryan Pendleton commented on DERBY-3729:
As a side note, it looks like the sending of the CMDCHKRM was modified during
this checkin:
Author: kmarsden
Date: Fri Dec 31 13:49:50 2004
New Revision: 123827
URL: http://svn.apache.org/viewcvs?view=rev&rev=123827
Log:
Initial check in of XA for Network Server.
Prior to revision 123827, the Network Server apparently sent a SQLERRRM even
for high severity errors.
At any rate, the important thing from the point of view of this issue is that,
whether the server
sends CMDCHKRM or SQLERRRM, it also sends the SQLCARD either way, so the client
code
should be safe in checking for the SQLCARD.
I'm going to try to put together a new patch proposal that:
1) Adds more text to the XSDG1 error message suggesting file system limits or
quotas as a possible cause
2) Adds more text to the J123 ("unarchitected condition") error message
suggesting that
more information may be available in the server's derby.log file
3) Adds the reading of the SQLCARD after the reading of the CMDCHKRM, and the
incorporation of whatever error message contents we can find in the SQLCA, as
described in my comment above.
> 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: 4, 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
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831560#action_12831560 ] Bryan Pendleton commented on DERBY-3729: Thanks Knut, I agree. I am no longer pursuing the downgrading of the severity. > 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: 4, 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.insertRo
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ 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: 4, 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.
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831277#action_12831277 ] Bryan Pendleton commented on DERBY-3729: After looking through the derby client trace file, I could see that at least some of the server-side information was in fact available to the client, as a SQLCARD message following the CMDCHKRM. So I made the following experimental change to the client's NetConnectionReply.java: Index: NetConnectionReply.java === --- NetConnectionReply.java (revision 907116) +++ NetConnectionReply.java (working copy) @@ -876,9 +876,12 @@ checkRequiredObjects(svrcodReceived); netAgent_.setSvrcod(svrcod); +NetSqlca netSqlca = parseSQLCARD(null); +netAgent_.netConnection_.completeSqlca(netSqlca); agent_.accumulateChainBreakingReadExceptionAndThrow(new DisconnectException(agent_, new ClientMessageId(SQLState.DRDA_CONNECTION_TERMINATED), -msgutil_.getTextMessage(MessageId.CONN_DRDA_CMDCHKRM))); +msgutil_.getTextMessage(MessageId.CONN_DRDA_CMDCHKRM), +new Exception(netSqlca.getSqlErrmc(; } With this change, the SQLException that the user program receives contains within it a DisconnectException, and that exception in turn contains within it a simple Exception with the error message information from the server. When this exception is thrown on the client side, it thus looks something like: Exception in thread "main" java.sql.SQLException: 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 at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:358) at org.apache.derby.client.am.PreparedStatement.executeUpdate(PreparedStatement.java:399) at repro.main(repro.java:27) Caused by: org.apache.derby.client.am.DisconnectException: 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 at org.apache.derby.client.net.NetConnectionReply.parseCMDCHKRM(NetConnectionReply.java:881) at org.apache.derby.client.net.NetStatementReply.parseExecuteError(NetStatementReply.java:684) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:351) at org.apache.derby.client.net.NetStatementReply.readExecute(NetStatementReply.java:71) at org.apache.derby.client.net.StatementReply.readExecute(StatementReply.java:55) at org.apache.derby.client.net.NetPreparedStatement.readExecute_(NetPreparedStatement.java:189) at org.apache.derby.client.am.PreparedStatement.readExecute(PreparedStatement.java:1865) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2162) at org.apache.derby.client.am.PreparedStatement.executeUpdateX(PreparedStatement.java:404) at org.apache.derby.client.am.PreparedStatement.executeUpdate(PreparedStatement.java:390) ... 1 more Caused by: java.lang.Exception: Page Page(6144,Container(0, 1136)) could not be written to disk, please check if disk is full.::SQLSTATE: XJ001Java exception: 'FAKE FAKE FAKE: java.io.IOException'. ... 11 more > 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: 4, SQLState: > 08006 > 18:02:37,550 ERROR JDBCExceptionReporter:78 - A network protocol error was > encountered and the connection has been terminated: the requested command > encountere
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831068#action_12831068 ] Bryan Pendleton commented on DERBY-3729: I spent some time stepping through the handling of the XSDG1 error in the engine code. The bulk of this processing is driven by ContextManager.cleanupOnError, which iterates through each of the various contexts (language context, connection context, compiler context, transaction context, and so forth). For each such context, the ContextManager calls the context's cleanupOnError method. My conclusion after studying this code is that the cleanup handling for a database-severity exception differs substantially from the cleanup handling for a transaction-severity message. Since the severity level for message XSDG1 was chosen a long time ago, presumably for very good reasons, I'm increasingly reluctant to downgrade the severity of this exception. I'll spend some time looking at how the client handles SVRCOD_SESDMG, but I'm increasingly thinking that it's going to be hard to do much beyond just trying to improve the error message text. > 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: 4, 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.r
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830598#action_12830598 ] Bryan Pendleton commented on DERBY-3729: I briefly investigated two other possibilities: 1) Changing DRDAConnThread.getExceptionSeverity so that it processed DATABASE_SEVERITY and SESSION_SEVERITY using SVRCOD_ERROR, rather than SVRCOD_SESDMG 2) Changing the client processing in NetConnectionReply so that it treated SVRCOD_SESDMG using the same path as SVRCOD_ERROR The first change seemed to be very close to working, but I had some unexpected errors in the replication suite, which concerned me. The second change was complex. I didn't see an easy way to change the client handling of SESDMG to make it more like the ERROR code point. So, for now, I'm continuing to pursue the notion of downgrading the severity of XSDG1 from DATABASE severity to TRANSACTION severity. Does anybody know of a good writeup which describes the severity levels and the implications of choosing a particular severity level for a message? > 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: 4, 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) >
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[
https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830436#action_12830436
]
Bryan Pendleton commented on DERBY-3729:
I think that a substantial portion of this behavior may be due to the following
code from DRDAConnThread:
// If it is a real SQL Error write a SQLERRRM first
severity = getExceptionSeverity(e);
if (severity > CodePoint.SVRCOD_ERROR)
{
// For a session ending error > CodePoint.SRVCOD_ERROR
you cannot
// send a SQLERRRM. A CMDCHKRM is required. In XA if
there is a
// lock timeout it ends the whole session. I am not
sure this
// is the correct behaviour but if it occurs we have to
send
// a CMDCHKRM instead of SQLERRM
writeCMDCHKRM(severity);
}
The "FILE_WRITE_PAGE_EXCEPTION" is listed as XSDG1.D, meaning that it has
"database" severity,
which means that getExceptionSeverity() treats it as:
severity = CodePoint.SVRCOD_SESDMG;
Because of this, the exception falls into the "unarchitected and
implementation-specific condition".
It appears that if I change the exception to "transaction" severity, by
changing it from
XSDG1.D to XSDG1.T, then the error-handling flow in the client/server code is
dramatically
different, and the underlying exception *does* get transmitted back to the
client.
I'll continue to explore the implications of downgrading the severity of this
particular message
from database severity to transaction severity, but am interested in whether
others have a reaction
about what that would mean, in practice.
> 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: 4, 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,Co
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[
https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829808#action_12829808
]
Bryan Pendleton commented on DERBY-3729:
I'm experimenting with the following hack, which is intended to make it easier
to work on this problem.
This hack alters the store so that it simulates an error whenever any table
tries to be grown
beyond 6K pages. With this hack in place, I'm working on some simple repro
programs to
enable a comparison of the behavior in Embedded versus Client/Server
configurations.
Index: java/engine/org/apache/derby/impl/store/raw/data/CachedPage.java
===
--- java/engine/org/apache/derby/impl/store/raw/data/CachedPage.java
(revision 905108)
+++ java/engine/org/apache/derby/impl/store/raw/data/CachedPage.java
(working copy)
@@ -782,6 +782,11 @@
identity));
}
+if (identity != null && identity.getPageNumber() >= (6*1024) )
+throw StandardException.newException(
+ SQLState.FILE_WRITE_PAGE_EXCEPTION,
+ new IOException("FAKE FAKE FAKE"), identity);
+
try
{
myContainer.writePage(
> 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: enhanceErrorMessage.diff
>
>
> 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: 4, 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.cac
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829613#action_12829613 ] Bryan Pendleton commented on DERBY-3729: Ah. I see I somewhat missed the point. Let me see if I can reproduce this problem in a client/server scenario, so I can better understand where the "unarchitected" message is coming from and whether we can improve it. Thanks for clarifying, Jason and Knut! > 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: enhanceErrorMessage.diff > > > 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: 4, 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.ap
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829280#action_12829280 ] Knut Anders Hatlen commented on DERBY-3729: --- Actually, I think the message about the "unarchitected and implementation-specific condition" is something Derby's client driver comes up with when the connection is terminated abruptly. I think the original request is perfectly fine, that the "disk full" message should be displayed at the client side instead of "unarchitected condition". > 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: enhanceErrorMessage.diff > > > 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: 4, 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.sto
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829270#action_12829270 ] Jason C. Cole commented on DERBY-3729: -- Hi Bryan, Either option sounds fine to me; I would note that the main issue I had was that this got reported up the chain as a non-architected implementation specific error; disk issues would not seem to fall into that domain to me, but that is most likely hibernate's problem, rather than derby. Fixing the lower level error to be more general would be fine from the 'derby' side of things Thanks for looking at it Jason > 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: enhanceErrorMessage.diff > > > 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: 4, 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.Heap
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829149#action_12829149 ] Knut Anders Hatlen commented on DERBY-3729: --- Since a quota normally limits the total size of all files belonging to a user, and not the size of a single file, would it be better to turn the last part of the sentence around to avoid the term "quota on the maximum file size"? Something like ..., or if a quota or a file system limit on the maximum file size has been reached. or perhaps ..., or if a file system limit, like a quota or maximum file size, has been reached. > 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: enhanceErrorMessage.diff > > > 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: 4, 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.acces
[jira] Commented: (DERBY-3729) Error message is rather unrevealing when creating large databases on FAT32 drives
[ https://issues.apache.org/jira/browse/DERBY-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806862#action_12806862 ] Bryan Pendleton commented on DERBY-3729: It seems like it might be worthwhile to change this message from Page Page(131071,Container(0, 2384)) could not be written to disk, please check if disk is full. to Page Page(131071,Container(0, 2384)) could not be written to disk, please check if disk is full, or if a filesystem limit or quota on the maximum file size has been reached. > 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 >Priority: Minor > > 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: 4, 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.apa
