You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kathey Marsden <km...@sbcglobal.net> on 2005/10/03 18:35:16 UTC
lang/wisconsin.sql
Running derbyall with the 10.1 jars made with a sane build (svn
292855), I am seeing a difference in plan for lang/wisconsin.sql in
embedded. If I run the test independently it passes.
Does this sound at all familiar to anyone? It is kind of hard to debug
because it only seems to occur in the context of a derbyall run.
Here is an example of part of the diff, full diff is attahched.
777 del
< Index Scan ResultSet for TENKTUP1 using index
TK1UNIQUE
2 at serializable isolation level using share row locking chosen by the
optimiz
er
777a777
> Hash Scan ResultSet for TENKTUP1 using index
TK1UNIQUE2
at serializable isolation level using share row locking:
778a779,780
The build I am using sits at http://people.apache.org/~kmarsden/snapshot/
Thanks for any clues.
Kathey
Re: New Proposed 10.1 snapshot (was Re: lang/wisconsin.sql)
Posted by Deepa Remesh <dr...@gmail.com>.
On 10/6/05, Kathey Marsden <km...@sbcglobal.net> wrote:
> I am using j9 from WCTME 5.7
>
> $ j9 -version
> java version "1.3.0"
>
> Licensed Materials - Property of IBM
>
> J9 - VM for the Java(TM) platform, Version 2.2
> (c) Copyright IBM Corp. 1991, 2004 All Rights Reserved
> Target: 20040706_1457_lHdSMR (Windows 2000 5.0 build 2195 Service Pack 4
> x86)
>
> Maybe my version is old. Is this the version you are using?
>
I am also using j9 from WCTME 5.7 - same version. These store tests
fail intermittently on my machine. I have not looked at the tests. The
method which is throwing IllegalStateException is getEntry() in
ZipFile. For this method, javadoc says
"Throws:
IllegalStateException - if the zip file has been closed
"
Thanks,
Deepa
Re: New Proposed 10.1 snapshot (was Re: lang/wisconsin.sql)
Posted by Kathey Marsden <km...@sbcglobal.net>.
Deepa Remesh wrote:
>I ran derbyall with J2ME/CDC/FP with the new snapshot. 3 tests failed.
>I have attached the diff for failures.
>
>* derbyall/derbyall.fail:jdbcapi/metadataJdbc20.java (needs master file update)
>* derbyall/storeall/storeall.fail:store/oc_rec1.java
>(java.lang.IllegalStateException)
>* derbyall/storeall/storeall.fail:store/oc_rec3.java
>(java.lang.IllegalStateException)
>
>The stack trace for IllegalStateException from .tmp files:
>java.lang.IllegalStateException:
> at java.util.zip.ZipFile.getEntryImpl(Native Method)
> at java.util.zip.ZipFile.getEntry(ZipFile.java:142)
> at java.util.jar.JarFile.getEntry(JarFile.java:307)
> at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:928)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:557)
> at java.security.AccessController.doPrivileged(AccessController.java:167)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:555)
>
>
>
>Has anyone seen this before?
>
>I tried to run the failed online compress tests individually but
>looking at the tests, I think they have to be run in sequence. So I
>ran just storeall suite and the tests oc_rec1.java and oc_rec3.java
>passed. I am not sure if these failures are intermittent. If anyone
>who has more knowledge of these tests can look into this and tell if
>this could be a problem in test/code, it would be great.
>
>
>
I did a derbyall run with J2ME on my machine last night and it all
passed. It seems to me that maybe this sis some sort of JVM issue.
The javadoc says IllegalStateException ...
"Signals that a method has been invoked at an illegal or inappropriate
time. In other words, the Java environment or Java application is not in
an appropriate state for the requested operation."
but I think that typically a subclassed exception would be thrown that
would give more information. Also the fact that the trace itself seems
to just be loading a class and has nothing to do with Derby, I think
is indicative of a JVM issue as well. Mike, is there some special
class loading stuff that goes on in this test that might cause this
issue to surface?
I am using j9 from WCTME 5.7
$ j9 -version
java version "1.3.0"
Licensed Materials - Property of IBM
J9 - VM for the Java(TM) platform, Version 2.2
(c) Copyright IBM Corp. 1991, 2004 All Rights Reserved
Target: 20040706_1457_lHdSMR (Windows 2000 5.0 build 2195 Service Pack 4
x86)
Maybe my version is old. Is this the version you are using?
Kathey
Re: New Proposed 10.1 snapshot (was Re: lang/wisconsin.sql)
Posted by Myrna van Lunteren <m....@gmail.com>.
Out of curiosity - is there anything helpful in derby.log?
Myrna
On 10/5/05, Deepa Remesh <dr...@gmail.com> wrote:
> I ran derbyall with J2ME/CDC/FP with the new snapshot. 3 tests failed.
> I have attached the diff for failures.
>
> * derbyall/derbyall.fail:jdbcapi/metadataJdbc20.java (needs master file
> update)
> * derbyall/storeall/storeall.fail:store/oc_rec1.java
> (java.lang.IllegalStateException)
> * derbyall/storeall/storeall.fail:store/oc_rec3.java
> (java.lang.IllegalStateException)
>
> The stack trace for IllegalStateException from .tmp files:
> java.lang.IllegalStateException:
> at java.util.zip.ZipFile.getEntryImpl(Native Method)
> at java.util.zip.ZipFile.getEntry(ZipFile.java:142)
> at java.util.jar.JarFile.getEntry(JarFile.java:307)
> at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:928)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:557)
> at java.security.AccessController.doPrivileged(AccessController.java:167)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:555)
>
> Has anyone seen this before?
>
> I tried to run the failed online compress tests individually but
> looking at the tests, I think they have to be run in sequence. So I
> ran just storeall suite and the tests oc_rec1.java and oc_rec3.java
> passed. I am not sure if these failures are intermittent. If anyone
> who has more knowledge of these tests can look into this and tell if
> this could be a problem in test/code, it would be great.
>
> Thanks,
> Deepa
>
> On 10/5/05, Kathey Marsden <km...@sbcglobal.net> wrote:
> > Knut Anders Hatlen wrote:
> >
> > >Kathey Marsden <km...@sbcglobal.net> writes:
> > >
> > >
> > >
> > >>Running derbyall with the 10.1 jars made with a sane build (svn
> > >>292855), I am seeing a difference in plan for lang/wisconsin.sql in
> > >>embedded. If I run the test independently it passes.
> > >>
> > >>
> > >
> > >I tried to run the test independently with your snapshot, and it
> > >failed.
> > >
> > Thanks Knut for looking at this. I finally gave up on that snapshot
> > and made a new proposed snapshot based on SVN 292855.
> > http://people.apache.org/~kmarsden/snapshot/
> >
> > I still have no idea what the problem was with wisconsin but derbyall on
> > Windows runs cleanly with the new one.
> > Also the same build has expected results on Ole's page.
> > http://db.apache.org/derby/derby_tests.html
> >
> > I will go ahead and bump the version. The only issue with the version
> > is that there was a test change checked in yesterday (DERBY-459)
> > which is not in the snapshot but got put in before the version bump.
> >
> > Deepa could you try this with J2ME? If anyone else can give the
> > snapshot a try before we post it that would be great.
> >
> > Thanks
> >
> > Kathey
> >
> >
> >
> >
>
>
>
Re: New Proposed 10.1 snapshot (was Re: lang/wisconsin.sql)
Posted by Deepa Remesh <dr...@gmail.com>.
I ran derbyall with J2ME/CDC/FP with the new snapshot. 3 tests failed.
I have attached the diff for failures.
* derbyall/derbyall.fail:jdbcapi/metadataJdbc20.java (needs master file update)
* derbyall/storeall/storeall.fail:store/oc_rec1.java
(java.lang.IllegalStateException)
* derbyall/storeall/storeall.fail:store/oc_rec3.java
(java.lang.IllegalStateException)
The stack trace for IllegalStateException from .tmp files:
java.lang.IllegalStateException:
at java.util.zip.ZipFile.getEntryImpl(Native Method)
at java.util.zip.ZipFile.getEntry(ZipFile.java:142)
at java.util.jar.JarFile.getEntry(JarFile.java:307)
at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:928)
at java.net.URLClassLoader$4.run(URLClassLoader.java:557)
at java.security.AccessController.doPrivileged(AccessController.java:167)
at java.net.URLClassLoader.findClass(URLClassLoader.java:555)
Has anyone seen this before?
I tried to run the failed online compress tests individually but
looking at the tests, I think they have to be run in sequence. So I
ran just storeall suite and the tests oc_rec1.java and oc_rec3.java
passed. I am not sure if these failures are intermittent. If anyone
who has more knowledge of these tests can look into this and tell if
this could be a problem in test/code, it would be great.
Thanks,
Deepa
On 10/5/05, Kathey Marsden <km...@sbcglobal.net> wrote:
> Knut Anders Hatlen wrote:
>
> >Kathey Marsden <km...@sbcglobal.net> writes:
> >
> >
> >
> >>Running derbyall with the 10.1 jars made with a sane build (svn
> >>292855), I am seeing a difference in plan for lang/wisconsin.sql in
> >>embedded. If I run the test independently it passes.
> >>
> >>
> >
> >I tried to run the test independently with your snapshot, and it
> >failed.
> >
> Thanks Knut for looking at this. I finally gave up on that snapshot
> and made a new proposed snapshot based on SVN 292855.
> http://people.apache.org/~kmarsden/snapshot/
>
> I still have no idea what the problem was with wisconsin but derbyall on
> Windows runs cleanly with the new one.
> Also the same build has expected results on Ole's page.
> http://db.apache.org/derby/derby_tests.html
>
> I will go ahead and bump the version. The only issue with the version
> is that there was a test change checked in yesterday (DERBY-459)
> which is not in the snapshot but got put in before the version bump.
>
> Deepa could you try this with J2ME? If anyone else can give the
> snapshot a try before we post it that would be great.
>
> Thanks
>
> Kathey
>
>
>
>
New Proposed 10.1 snapshot (was Re: lang/wisconsin.sql)
Posted by Kathey Marsden <km...@sbcglobal.net>.
Knut Anders Hatlen wrote:
>Kathey Marsden <km...@sbcglobal.net> writes:
>
>
>
>>Running derbyall with the 10.1 jars made with a sane build (svn
>>292855), I am seeing a difference in plan for lang/wisconsin.sql in
>>embedded. If I run the test independently it passes.
>>
>>
>
>I tried to run the test independently with your snapshot, and it
>failed.
>
Thanks Knut for looking at this. I finally gave up on that snapshot
and made a new proposed snapshot based on SVN 292855.
http://people.apache.org/~kmarsden/snapshot/
I still have no idea what the problem was with wisconsin but derbyall on
Windows runs cleanly with the new one.
Also the same build has expected results on Ole's page.
http://db.apache.org/derby/derby_tests.html
I will go ahead and bump the version. The only issue with the version
is that there was a test change checked in yesterday (DERBY-459)
which is not in the snapshot but got put in before the version bump.
Deepa could you try this with J2ME? If anyone else can give the
snapshot a try before we post it that would be great.
Thanks
Kathey
Re: lang/wisconsin.sql
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Kathey Marsden <km...@sbcglobal.net> writes:
> Running derbyall with the 10.1 jars made with a sane build (svn
> 292855), I am seeing a difference in plan for lang/wisconsin.sql in
> embedded. If I run the test independently it passes.
I tried to run the test independently with your snapshot, and it
failed. The diff is too big to attach, but you can find it here:
http://www.idi.ntnu.no/~knutanh/wisconsin.diff.txt
> Does this sound at all familiar to anyone? It is kind of hard to debug
> because it only seems to occur in the context of a derbyall run.
lang/wisconsin.sql is used in many of the test suites where different
options are passed to RunTest. You could run derbyall with stdout
redirected to a file and check what command line arguments are used.
--
Knut Anders