Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <15660913.190521278181489864.JavaMail.jira@thor>
Date: Sat, 3 Jul 2010 14:24:49 -0400 (EDT)
From: "Bryan Pendleton (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1958) improve XSDG3 error to print
 container, actual i/o operation, and file name.
In-Reply-To: <10088284.1160674715080.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Bryan Pendleton commented on DERBY-1958:
----------------------------------------

Hi Eranda, Sorry about that, I should have tried it first not just guessed.

It looks like readPage and writePage in RAFContainer are overridden
by readPage and writePage in RAFContainer4, and it looks like we always
use RAFContainer4 for any JDK 1.4+ configuration. Mike or Knut Anders or somebody
else who's familiar with the store can probably confirm this for sure.

There is a class called BaseDataFileFactoryJ4 which arranges for this
overriding, though, and so I was able to re-point the store to use the
RAFContainer rather than the RAFContainer4 by simply making this change
to BaseDataFileFactoryJ4:

--- java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactoryJ4.java(revision 958595)
+++ java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactoryJ4.java(working copy)
@@ -42,6 +42,6 @@
      * objects capable of exploiting the NIO API available in Java 1.4+
      */
     protected Cacheable newRAFContainer(BaseDataFileFactory factory) {
-        return new RAFContainer4(factory);
+        return new RAFContainer(factory);
     }
 }

Once I did this, I started to hit the readPage and writePage methods in RAFContainer.

Now, I'm not totally sure what the implications of this are. Since (I believe) Derby
no longer supports any JDK version prior to JDK 1.4 (I think Derby 10.2 was the
last version that supported JDK 1.3 -- see DERBY-1982), if RAFContainer is ONLY
used for JDK 1.3, then perhaps we should just remove RAFContainer, rather
than trying to fix it.

Does the problematic XSDG3 message arise in RAFContainer4 as well?

I did a quick search for FILE_CONTAINER_EXCEPTION in the code, and maybe
the message only occurs in RAFContainer, but it would be nice if somebody else
could confirm these analyses.

Basically, the question is: can we just remove RAFContainer (or, at least,
RAFContainer.readPage and RAFContainer.writePage), now that we no longer
support JDK 1.3?


> improve XSDG3 error to print container, actual i/o operation, and file name.
> ----------------------------------------------------------------------------
>
>                 Key: DERBY-1958
>                 URL: https://issues.apache.org/jira/browse/DERBY-1958
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.1.4
>            Reporter: Mike Matrigali
>            Priority: Trivial
>
> The current error does not give enough information to know what container is the problem:
> ERROR XSDG3: Meta-data for Container
> org.apache.derby.impl.store.raw.data.RAFContainer@10632cd could not be
> accessed 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.