Derby
  1. Derby
  2. DERBY-3729

Error message is rather unrevealing when creating large databases on FAT32 drives

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.3.3.0
    • Fix Version/s: 10.6.1.0
    • Component/s: Network Client
    • Labels:
      None
    • Environment:
      Windows XP with a FAT32 drive
    • Urgency:
      Low

      Description

      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.

      1. clientServer_derby.log
        211 kB
        Bryan Pendleton
      2. clientSQLException.txt
        2 kB
        Bryan Pendleton
      3. embedded_derby.log
        210 kB
        Bryan Pendleton
      4. embeddedSQLException.txt
        3 kB
        Bryan Pendleton
      5. enhanceErrorMessage.diff
        2 kB
        Bryan Pendleton
      6. repro.java
        1 kB
        Bryan Pendleton
      7. reproEmbedded.java
        1 kB
        Bryan Pendleton
      8. UpdateMessagesImproveClient.diff
        3 kB
        Bryan Pendleton

        Activity

        Hide
        Bryan Pendleton added a comment -

        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.

        Show
        Bryan Pendleton added a comment - 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.
        Hide
        Bryan Pendleton added a comment -

        Attached is a patch proposal to enhance the XSDG1 message with some
        additional text. The extra text is intended to suggest other possible reasons
        that the file could not be written, such as if a filesystem limit has been
        reached (e.g., the FAT32 4GB file limit) or a quota has been reached.

        Show
        Bryan Pendleton added a comment - Attached is a patch proposal to enhance the XSDG1 message with some additional text. The extra text is intended to suggest other possible reasons that the file could not be written, such as if a filesystem limit has been reached (e.g., the FAT32 4GB file limit) or a quota has been reached.
        Hide
        Knut Anders Hatlen added a comment -

        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.

        Show
        Knut Anders Hatlen added a comment - 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.
        Hide
        Jason C. Cole added a comment -

        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

        Show
        Jason C. Cole added a comment - 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
        Hide
        Knut Anders Hatlen added a comment -

        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".

        Show
        Knut Anders Hatlen added a comment - 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".
        Hide
        Bryan Pendleton added a comment -

        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!

        Show
        Bryan Pendleton added a comment - 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!
        Hide
        Bryan Pendleton added a comment -

        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(

        Show
        Bryan Pendleton added a comment - 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(
        Hide
        Bryan Pendleton added a comment -

        Attached 'repro.java' and 'reproEmbedded.java', which differ only in
        the JDBC driver class name and the connection URL, can be used,
        together with the CachedPage.java hack mentioned in my earlier comment,
        to reproduce the XSDG1 error in client/server and embedded environments.

        Show
        Bryan Pendleton added a comment - Attached 'repro.java' and 'reproEmbedded.java', which differ only in the JDBC driver class name and the connection URL, can be used, together with the CachedPage.java hack mentioned in my earlier comment, to reproduce the XSDG1 error in client/server and embedded environments.
        Hide
        Bryan Pendleton added a comment -

        derby.log files resulting from the client/server and embeded reproductions, for comparison.

        Show
        Bryan Pendleton added a comment - derby.log files resulting from the client/server and embeded reproductions, for comparison.
        Hide
        Bryan Pendleton added a comment -

        Exception received by the test program for the client/server and embedded test
        programs are attached. Note that, just as happened for Jason, in the client/server
        case I get the confusing "unarchitected and implementation-specific condition"
        exception whereas in the embedded case the XSDG1 exception is delivered
        straight to the program, so just as Knut suspected this appears to be a weakness
        in the client exception handling.

        Show
        Bryan Pendleton added a comment - Exception received by the test program for the client/server and embedded test programs are attached. Note that, just as happened for Jason, in the client/server case I get the confusing "unarchitected and implementation-specific condition" exception whereas in the embedded case the XSDG1 exception is delivered straight to the program, so just as Knut suspected this appears to be a weakness in the client exception handling.
        Hide
        Bryan Pendleton added a comment -

        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.

        Show
        Bryan Pendleton added a comment - 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.
        Hide
        Bryan Pendleton added a comment -

        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?

        Show
        Bryan Pendleton added a comment - 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?
        Hide
        Bryan Pendleton added a comment -

        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.

        Show
        Bryan Pendleton added a comment - 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.
        Hide
        Bryan Pendleton added a comment -

        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

        Show
        Bryan Pendleton added a comment - 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
        Hide
        Knut Anders Hatlen added a comment -

        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.

        Show
        Knut Anders Hatlen added a comment - 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.
        Hide
        Bryan Pendleton added a comment -

        Thanks Knut, I agree. I am no longer pursuing the downgrading of the severity.

        Show
        Bryan Pendleton added a comment - Thanks Knut, I agree. I am no longer pursuing the downgrading of the severity.
        Hide
        Bryan Pendleton added a comment -

        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.

        Show
        Bryan Pendleton added a comment - 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.
        Hide
        Knut Anders Hatlen added a comment -

        Sounds like a good plan! +1

        Show
        Knut Anders Hatlen added a comment - Sounds like a good plan! +1
        Hide
        Bryan Pendleton added a comment -

        Attached 'UpdateMessagesImproveClient.diff' is a patch proposal which:
        a) Adds additional text to XSDG1 and J123 messages
        b) Enhances the client's handling of CMDCHKRM to look for possible info in the SQLCARD

        Regression tests were clean.

        I'm planning to commit this patch, and would appreciate any feedback.

        Show
        Bryan Pendleton added a comment - Attached 'UpdateMessagesImproveClient.diff' is a patch proposal which: a) Adds additional text to XSDG1 and J123 messages b) Enhances the client's handling of CMDCHKRM to look for possible info in the SQLCARD Regression tests were clean. I'm planning to commit this patch, and would appreciate any feedback.
        Hide
        Knut Anders Hatlen added a comment -

        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.

        Show
        Knut Anders Hatlen added a comment - 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.
        Hide
        Bryan Pendleton added a comment -

        Thanks Knut Anders for the various reviews and suggestions. I think that
        this change is about as good as it's going to get in my client, so I've committed
        it to the trunk so we can get some additional experience with it there.

        Committed to subversion as revision 911955.

        Show
        Bryan Pendleton added a comment - Thanks Knut Anders for the various reviews and suggestions. I think that this change is about as good as it's going to get in my client, so I've committed it to the trunk so we can get some additional experience with it there. Committed to subversion as revision 911955.
        Hide
        Knut Anders Hatlen added a comment -

        [bulk update] Close all resolved issues that haven't been updated for more than one year.

        Show
        Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

          People

          • Assignee:
            Bryan Pendleton
            Reporter:
            Jason C. Cole
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development