Re: OutBufferedStream test fails on JDK13 platforms ...
Hello. I found that JDK13 installed in my development environment can not work... Error message from java virtual machine was as next. [EMAIL PROTECTED]:~$ java -version /usr/local/jdk1.3.1_18/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file:No such file or directory Next, I linked libstdc++.so.6.0.7 to libstdc++-libc6.1-1.so.2 as next for walk around. rufelza:/usr/lib# ln -s libstdc++.so.6.0.7 libstdc++-libc6.1-1.so.2 And executed java virtual machine again. However, another error happened as next ... [EMAIL PROTECTED]:~$ java -version Segmentation fault I think I need your help Best regards. TomohitoNakayama wrote: Hello Satheesh. I have access to JDK13 and have interest to fix it. I start to survey. Best regards. Satheesh Bandaram wrote: I have been seeing this test fail on JDK13 platforms, both SUN and IBM JVMs since the test was committed. Tomohito, do you have access to JDK13 platform and have interest to fix this failure? If not, I can help. Satheesh [bandaram:satheesh] svn log OutBufferedStream.out r405037 | tmnk | 2006-05-08 05:36:39 -0700 (Mon, 08 May 2006) | 1 line - DERBY-326 Improve streaming of large objects for network server and client - Patch by Tomohito Nakayama ([EMAIL PROTECTED]) -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Re: OutBufferedStream test fails on JDK13 platforms ...
Hello Satheesh. I have access to JDK13 and have interest to fix it. I start to survey. Best regards. Satheesh Bandaram wrote: I have been seeing this test fail on JDK13 platforms, both SUN and IBM JVMs since the test was committed. Tomohito, do you have access to JDK13 platform and have interest to fix this failure? If not, I can help. Satheesh [bandaram:satheesh] svn log OutBufferedStream.out r405037 | tmnk | 2006-05-08 05:36:39 -0700 (Mon, 08 May 2006) | 1 line - DERBY-326 Improve streaming of large objects for network server and client - Patch by Tomohito Nakayama ([EMAIL PROTECTED]) -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Re: Possible CPU loop in testProtocol in cross-release scenario?
Anyway, setting those two fields to false in DDMReader.initialize() made the hang go away, and derbynetclientmats runs cleanly with that change. Wonderful! Thanks for the quick analysis, Knut Anders. It sounds like I should open a JIRA issue for this and we should package up your fix and get it into the codeline. I'll log the issue and include our discussion as notes. thanks, bryan
Re: Possible CPU loop in testProtocol in cross-release scenario?
Knut Anders Hatlen <[EMAIL PROTECTED]> writes: > Bryan Pendleton <[EMAIL PROTECTED]> writes: > >> I was trying to verify that the changes in DERBY-920 hadn't >> introduced any new compatibility problems (they shouldn't, because >> we were changing an internal class, but I wanted to make sure). >> >> So I was trying to follow some old tips about how to run tests with >> an old client against a new server, as documented in: >> http://wiki.apache.org/db-derby/TestingOldClientNewServer >> >> However, when I did this, the test "testProtocol" did not terminate. >> Instead, it entered a hard CPU loop consuming 100% of my machine, >> until I killed the test process. >> >> Can somebody please try these steps (from the wiki page) against >> the current trunk and see whether or not you get the same CPU loop >> problem that I got? > > Hi Bryan, > > I also see this. However, the CPU usage is more like 0% than 100%. I > think this is caused by the pre-fetching that was added to the network > client in DERBY-822. If you put this at the end of values1.inc > > readReplyDss > readLengthAndCodepoint QRYDTA > skipBytes > > or simply > > skipDss > > testProtocol will terminate successfully. > > This is not a compatibility issue, since the network client (also the > 10.1 client) knows that a QRYDTA object may or may not arrive. The > protocol test, on the other hand, is written with a specific version > of the server in mind, with the expected server response > hard-coded. Since the 10.1 version of the test doesn't expect QRYDTA > from an OPNQRY, the actual server response and the expected response > will be out of sync. > > I'm not sure what causes the hang, though. The test that is hanging is > "Test for too large value for OUTEXP in EXCSQLSTT", and it happens in > the first skipDss in connect.inc. When this test starts, there is at > least a left-over QRYDTA from the previous test (and perhaps more > since that one doesn't read any data sent from the server). But that > should not be a problem since the endTest command is supposed to close > the socket and streams and open new ones. We should probably look into > why this is happening, at least so that we can eliminate that there's > something wrong with the network server code. It seems like the hang is in fact caused by a bug in DDMReader. dssIsChainedWithDiffID and dssIsChainedWithSameID are not reset in initialize(), so values from a previous session might be used. In this particular case, the old values made DDMReader.getCurrChainState() return an incorrect value, which again made calls to DDMWriter.finalizeChain() a no-op. The protocol test therefore never sent the DRDA commands it thought it had sent, and both sides ended up waiting for data from the other one. It is not clear to me whether this bug actually can be triggered outside the protocol test since the client driver doesn't use DDMReader/DDMWriter. The way DRDAConnThread uses those classes should be safe, as the server always reads a command before responding and the fields seem to be set to reasonable values at each read. Anyway, setting those two fields to false in DDMReader.initialize() made the hang go away, and derbynetclientmats runs cleanly with that change. -- Knut Anders
[jira] Updated: (DERBY-1424) Build derbyclient.jar from a dependency list generated by classlister
[ http://issues.apache.org/jira/browse/DERBY-1424?page=all ] Andrew McIntyre updated DERBY-1424: --- Attachment: derbyclient_classlister.patch Attaching a patch for this issue. I haven't had time to thoroughly test it yet due to trouble with the testing environment where I was working on this, but I wanted to make sure I didn't lose the patch since I had already put it together. > Build derbyclient.jar from a dependency list generated by classlister > - > > Key: DERBY-1424 > URL: http://issues.apache.org/jira/browse/DERBY-1424 > Project: Derby > Type: Improvement > Components: Build tools > Versions: 10.2.0.0 > Reporter: Andrew McIntyre > Assignee: Andrew McIntyre > Fix For: 10.2.0.0 > Attachments: derbyclient_classlister.patch > > Currently, derbyclient.jar is built from a hardcoded list of classes in the > top-level build.xml file. This causes a few unnecessary and unwanted > classfiles to be added to the insane jar files, such as SanityManager and > some of the reference files. derbyclient.jar should be built from a > dependency list generated by classlister, similar to how the other jars are > built. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1424) Build derbyclient.jar from a dependency list generated by classlister
Build derbyclient.jar from a dependency list generated by classlister - Key: DERBY-1424 URL: http://issues.apache.org/jira/browse/DERBY-1424 Project: Derby Type: Improvement Components: Build tools Versions: 10.2.0.0 Reporter: Andrew McIntyre Assigned to: Andrew McIntyre Fix For: 10.2.0.0 Currently, derbyclient.jar is built from a hardcoded list of classes in the top-level build.xml file. This causes a few unnecessary and unwanted classfiles to be added to the insane jar files, such as SanityManager and some of the reference files. derbyclient.jar should be built from a dependency list generated by classlister, similar to how the other jars are built. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Copyrights redux
On 6/16/06, Rick Hillegas <[EMAIL PROTECTED]> wrote: Hi Jean, While I'm on the topic: I asked these questions in the context of 10.2, but it seems that issue (2) may apply to 10.1.3 as well. Do the copyright notices for the 10.1.3 release need to conform to the pattern in (2)? Yes, and I've updated the copyright notice in the 10.1.3 documentation to reflect the change as described below: > "Copyright 1997, 2005 The Apache Software Foundation or its licensors, > as applicable." > > to > "Copyright 1997, 2005-2006 The Apache Software Foundation or its > licensors, as applicable." Since this only affected a handful of documentation files in the -bin distributions and no code, I updated the -bin distributions with the affected doc files and regenerated their signatures. andrew
Re: Possible CPU loop in testProtocol in cross-release scenario?
Bryan Pendleton <[EMAIL PROTECTED]> writes: > I was trying to verify that the changes in DERBY-920 hadn't > introduced any new compatibility problems (they shouldn't, because > we were changing an internal class, but I wanted to make sure). > > So I was trying to follow some old tips about how to run tests with > an old client against a new server, as documented in: > http://wiki.apache.org/db-derby/TestingOldClientNewServer > > However, when I did this, the test "testProtocol" did not terminate. > Instead, it entered a hard CPU loop consuming 100% of my machine, > until I killed the test process. > > Can somebody please try these steps (from the wiki page) against > the current trunk and see whether or not you get the same CPU loop > problem that I got? Hi Bryan, I also see this. However, the CPU usage is more like 0% than 100%. I think this is caused by the pre-fetching that was added to the network client in DERBY-822. If you put this at the end of values1.inc readReplyDss readLengthAndCodepoint QRYDTA skipBytes or simply skipDss testProtocol will terminate successfully. This is not a compatibility issue, since the network client (also the 10.1 client) knows that a QRYDTA object may or may not arrive. The protocol test, on the other hand, is written with a specific version of the server in mind, with the expected server response hard-coded. Since the 10.1 version of the test doesn't expect QRYDTA from an OPNQRY, the actual server response and the expected response will be out of sync. I'm not sure what causes the hang, though. The test that is hanging is "Test for too large value for OUTEXP in EXCSQLSTT", and it happens in the first skipDss in connect.inc. When this test starts, there is at least a left-over QRYDTA from the previous test (and perhaps more since that one doesn't read any data sent from the server). But that should not be a problem since the endTest command is supposed to close the socket and streams and open new ones. We should probably look into why this is happening, at least so that we can eliminate that there's something wrong with the network server code. -- Knut Anders
Re: [jira] Commented: (DERBY-1032) Create new scripts which follow common practice at Apache
On 6/16/06, David Van Couvering <[EMAIL PROTECTED]> wrote: I didn't follow how this solution is going to be backward-compatible. I'm assuming we'll be keeping the old ones around, perhaps invoking the new ones? I was planning on leaving the old ones where they are, it's mentioned towards the end of the comment in JIRA. We could have the old ones invoke the new ones if desired. andrew
[jira] Commented: (DERBY-396) Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN
[ http://issues.apache.org/jira/browse/DERBY-396?page=comments#action_12416601 ] Rick Hillegas commented on DERBY-396: - Hi Wade, Scott did not submit a patch for this issue and he has moved on to other pursuits. This issue is currently unassigned. > Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN > -- > > Key: DERBY-396 > URL: http://issues.apache.org/jira/browse/DERBY-396 > Project: Derby > Type: New Feature > Components: SQL > Environment: LINUX > Reporter: Kumar Matcha > > Alter Statement should support dropping a column, modifying a column to a > different data type , rename a column. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1423) set CLASSPATH example in testing/README.htm lists an absolute path for jakarta-oro-2.0.8.jar
set CLASSPATH example in testing/README.htm lists an absolute path for jakarta-oro-2.0.8.jar Key: DERBY-1423 URL: http://issues.apache.org/jira/browse/DERBY-1423 Project: Derby Type: Improvement Components: Test Reporter: Stan Bradbury Priority: Minor The set CLASSPATH example in ...trunk/java/testing/README.htm specifies an absolute path for the jar file jakarta-oro-2.0.8.jar. All other jars in the example are identified by the environment variable $jardir. To be consistent and help us folks that cutNpaste commands update the file entry: /local/derby/tools/java/jakarta-oro-2.0.8.jar with: $jardir/jakarta-oro-2.0.8.jar in the example -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Driver autoloading and engine booting
My vote: - Document it for 10.2 - Log a bug - Work on fixing it by booting on first connection rather than when the driver is loaded. -1 on removing the autoloading feature, unless people have evidence that this is going to cause real problems for our users. David Rick Hillegas wrote: This topic was raised in an earlier email thread (http://comments.gmane.org/gmane.comp.apache.db.derby.devel/20899) but it does not appear that we agreed on a solution. I would like to re-open this topic and hopefully we can converge on how we want to handle this issue. Olav has analyzed a problematic interaction between JDBC4-driver-autoloading and Derby-embedded-engine-booting. In addition to the above email thread, the problem is also discussed in DERBY-1399. Here's a brief sketch of the issue: a) With JDBC4, vendors mark their jar files to indicate the names of jdbc drivers in those jars. During the lifetime of a vm, the very first request for a Connection causes the DriverManager to look inside all of the jars and register all indicated jdbc drivers. b) When our embedded driver registers itself, it also boots the engine, using whatever derby properties are currently visible. Typically, the engine stays booted for the lifetime of the vm. This can cause a Heisenbug in the following scenario: o The customer runs two applications in the same vm: EmbeddedApp and OtherApp. o Before getting its first Connection, the EmbeddedApp hand-crafts its own derby properties to configure the engine's behavior. o OtherApp could be an application which uses the Derby client driver or some other jdbc driver. o If OtherApp runs before EmbeddedApp, then the engine will boot without the hand-crafted properties. o It may not be deterministic whether OtherApp or EmbeddedApp runs first. Sometimes you get the right engine properties and sometimes you don't. It is worth pointing out that this Heisenbug can occur today, pre-JDBC4, if OtherApp is another embedded Derby application. JDBC4-driver-autoloading broadens the family of affected scenarios. It is hard to say how much the family is broadened. It is probably worthwhile documenting this Heisenbug somewhere in our user guides and release notes. In addition, two solutions have been proposed for eliminating the extra exposure introduced by JDBC4. Neither of these approaches addresses the pre-JDBC4 case: 1) Remove the JDBC4-driver-autoloading. This removes a useful ease-of-development feature and makes us fail to be JDBC4-compliant. 2) Don't boot the engine when registering the embedded driver. Instead, boot the engine the first time that someone requests an embedded Connection. This approach involves a lot of testing. In addition, we could 3) Decide that the extra exposure is minimal and not do anything besides document it. I hope that the community can agree on the severity of this extra exposure and on the best approach for handling it. Please share your opinions. Thanks, -Rick
Driver autoloading and engine booting
This topic was raised in an earlier email thread (http://comments.gmane.org/gmane.comp.apache.db.derby.devel/20899) but it does not appear that we agreed on a solution. I would like to re-open this topic and hopefully we can converge on how we want to handle this issue. Olav has analyzed a problematic interaction between JDBC4-driver-autoloading and Derby-embedded-engine-booting. In addition to the above email thread, the problem is also discussed in DERBY-1399. Here's a brief sketch of the issue: a) With JDBC4, vendors mark their jar files to indicate the names of jdbc drivers in those jars. During the lifetime of a vm, the very first request for a Connection causes the DriverManager to look inside all of the jars and register all indicated jdbc drivers. b) When our embedded driver registers itself, it also boots the engine, using whatever derby properties are currently visible. Typically, the engine stays booted for the lifetime of the vm. This can cause a Heisenbug in the following scenario: o The customer runs two applications in the same vm: EmbeddedApp and OtherApp. o Before getting its first Connection, the EmbeddedApp hand-crafts its own derby properties to configure the engine's behavior. o OtherApp could be an application which uses the Derby client driver or some other jdbc driver. o If OtherApp runs before EmbeddedApp, then the engine will boot without the hand-crafted properties. o It may not be deterministic whether OtherApp or EmbeddedApp runs first. Sometimes you get the right engine properties and sometimes you don't. It is worth pointing out that this Heisenbug can occur today, pre-JDBC4, if OtherApp is another embedded Derby application. JDBC4-driver-autoloading broadens the family of affected scenarios. It is hard to say how much the family is broadened. It is probably worthwhile documenting this Heisenbug somewhere in our user guides and release notes. In addition, two solutions have been proposed for eliminating the extra exposure introduced by JDBC4. Neither of these approaches addresses the pre-JDBC4 case: 1) Remove the JDBC4-driver-autoloading. This removes a useful ease-of-development feature and makes us fail to be JDBC4-compliant. 2) Don't boot the engine when registering the embedded driver. Instead, boot the engine the first time that someone requests an embedded Connection. This approach involves a lot of testing. In addition, we could 3) Decide that the extra exposure is minimal and not do anything besides document it. I hope that the community can agree on the severity of this extra exposure and on the best approach for handling it. Please share your opinions. Thanks, -Rick
Re: [jira] Commented: (DERBY-930) Add support for autoloading of Derby client drivers
Rick Hillegas (JIRA) wrote: I think that derby-dev should continue to discuss the issue which Olav has analyzed in DERBY-1399. I will continue this discussion shortly. If the behaviour change for DERBY-930 is intentional a special release note is needed for this issue in the section for "Changes that might affect existing applications": It might read something like this ... PROBLEM: Autoloading of driver causes changes to behavior of derby properties. SYMPTOM: Derby does not recognize derby.system.home or other properties set by the application and creates database in the wrong location or fails to recognize properties. CAUSE: Automatic loading of the driver with JDBC 4.0 causes derby to be booted before the derby.system.home property has been set. Therefore the property is ignored. SOLUTION: There is no product solution to this issue. WORKAROUND: The only workaround is to set derby.system.home before any connection is made to any database. For example derby.system.home can be specified on the command line with -Dderby.system.home= Now that I put it like that I can imagine all the users in the world that this is going to impact and I become more convinced that this is a bug and a serious regression.I liked the suggestion to defer booting derby embedded until the first embedded connection is made, but apparently there are other implications for derby.drda.startNetworkServer that I don't quite understand yet. IMHO they all should be fixed if possible so we don't break existing applications. Kathey
Re: Did the MessageBundleTest pass before it was made part of derbyall?
Yes, I understand, thanks. David Andrew McIntyre wrote: On 6/16/06, David Van Couvering <[EMAIL PROTECTED]> wrote: Hm, thanks Andrew. That may very well be, but it was also the case that the master file did not get correctly checked in. I was running in the classes directory. I'll run with the jar files, and see what happens, and correct my logic as needed. Meanwhile, I'll remove MessageBundleTest from derbyall. Note that the test will pass when running from the classes because SQLState will be in your classpath as part of the full class tree. It will continue to fail in jar testing because of the problem I described above. andrew
[jira] Commented: (DERBY-930) Add support for autoloading of Derby client drivers
[ http://issues.apache.org/jira/browse/DERBY-930?page=comments#action_12416591 ] Rick Hillegas commented on DERBY-930: - I think that derby-dev should continue to discuss the issue which Olav has analyzed in DERBY-1399. I will continue this discussion shortly. Based on that discussion, we can decide what to put in a release note. It's unclear to me how to divide JDBC4 functionality among release notes. This issue may deserve a release not by itself, or it may be a subcase of some larger release note for JDBC4 features. But in any event, I agree we should attach some description to this issue for rollup somewhere in the 10.2 release notes. In addition, this behavior should be documented in the user guides. The analysis of user guide changes can be found in DERBY-1271. > Add support for autoloading of Derby client drivers > --- > > Key: DERBY-930 > URL: http://issues.apache.org/jira/browse/DERBY-930 > Project: Derby > Type: New Feature > Components: Build tools, JDBC > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Fix For: 10.2.0.0 > Attachments: ClassloadingTest.jar, bug930.diff, bug930_problem.diff, > bug930_problem2.diff, bug930_rev2.diff, bug930_rev3.diff > > Write Derby's driver names into the correct spot in derby.jar and > derbyclient.jar so that the 1.6 vm autoloads Derby drivers. Section 10.2.1 of > the JDBC4 spec describes the details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1394) Working With Derby - Introduction and prerequisites - Improvements
[ http://issues.apache.org/jira/browse/DERBY-1394?page=comments#action_12416589 ] Stan Bradbury commented on DERBY-1394: -- Opps please my mistake int he previous comment under #4: s/10.3/10.2 Of course Working With Derby is slated for release with v 10.2 (not 10.3) so any examples with version strings should reference 10.2. > Working With Derby - Introduction and prerequisites - Improvements > -- > > Key: DERBY-1394 > URL: http://issues.apache.org/jira/browse/DERBY-1394 > Project: Derby > Type: Improvement > Components: Documentation > Versions: 10.2.0.0 > Environment: DITA-sourced documentation > Reporter: Halley Pacheco de Oliveira > Priority: Minor > Fix For: 10.2.0.0 > Attachments: twwdIntro.diff, twwdIntro.diff.html, twwdIntro.html, > twwdIntro_2.diff, twwdIntro_2.diff.html, twwdIntro_2.html > > 1) There is a gramatical error: > It's written "sections" and not "section": > "In way of introduction this sections provides a brief description of Derby." > and should be, in my opinion: > "In way of introduction this section provides a brief description of Derby." > 2) DERBY_HOME > It's written: > "Note the filesystem path to the Derby installation (referred to as > DERBY_HOME)." > but DERBY_HOME doesn't appear anywhere else in this page, so it is not > possible > to note it in this page. It only appears in the activities pages. By this > reason, > in my opinion, the sentence should be: > "Note the filesystem path to the Derby installation (referred to as > DERBY_HOME) in the activities sections." > 3) Commas could be used to make some sentences shorter: > === > - "Derby is a full featured, open source relational database engine that is > written and implemented completely in Java." > into > + "Derby is a full featured, open source, relational database engine, that is > written and implemented completely in Java." > === > - "It provides users with a small footprint, standards-based Java database > that can be tightly embedded into any Java based solution." > into > + "It provides users with a small footprint, standards-based, Java database, > that can be tightly embedded into any Java based solution." > === > - "In it's default configuration there is no separate database server to be > installed or maintained by the end user." > into > + "In it's default configuration, there is no separate database server to be > installed or maintained by the end user." > === > - "This document demonstrates but does not teach the Java, JDBC and SQL > presented so readers wishing a deeper understanding of these topics will need > additional reference materials." > into > + "This document demonstrates, but does not teach, the Java, JDBC and SQL > presented, so readers wishing a deeper understanding of these topics will > need additional reference materials. > === > - "If unsure about the Java or Derby environments installed perform the > following steps before attempting the subsequent activities:" > into > + "If unsure about the Java or Derby environments installed, perform the > following steps before attempting the subsequent activities:" > === > - "The output you see may be different from what is shown here because the > java -version command outputs vendor-specific information." > into > + "The output you see may be different from what is shown here, because the > java -version command outputs vendor-specific information." > === > - "If the command produced an error or the version listed is not 1.3 or > higher please install a Java development kit before continuing." > into > + "If the command produced an error or the version listed is not 1.3 or > higher, please install a Java development kit before continuing." > === > - "From the Downloads page use the link to the 'Latest Official Release' then > locate the bin distribution (e.g. db-derby-10.2.0-bin). Download the file and > unbundle the release." > into > + "From the Download page use the link to the 'Latest Official Release', then > locate the bin distribution (e.g. db-derby-10.2.0-bin). Download the file and > unbundle the release." > 4) Download the file and unbundle the release. > Is is not easy to understand what this sentence means. There are two files > for the binary distribution: -bin.zip and -bin.tar.gz > So the previous sentence could be changed to: > "From the Download page use the link to the 'Latest Official Release', then > locate the bin distribution (e.g. db-derby-10.1.2.1-bin.zip and > db-derby-10.1.2.1-bin.tar.gz). Download the appropriate file for your > platform, '-bin.zip' for Windows or '-bin.tar.gz' for Unix/Linux", and > unzip/untar this file. After decompressing the downloaded file, move the > directory created to the filesystem path choosed to be the root directory of > the Derby installation (e.g., move db-derby-10.1.2.1-bin C:\Derby) -- Thi
Re: [jira] Commented: (DERBY-578) Grouped select from temporary table raises null pointer exception in byte code generator
Since only predicatePushdown failed, I generated a context diff for this one file. I already have a bunch of other uncommitted changes in my view, so I'm not sure how I can generate one patch file without pulling in a lot of other stuff. The following sequence of steps should work. 1. Apply the complete patch (578.patch.txt). 2. revert predicatePushdown 3. patch predicatePushdown. Manish --- "Rick Hillegas (JIRA)" wrote: > [ > http://issues.apache.org/jira/browse/DERBY-578?page=comments#action_12416588 > ] > > Rick Hillegas commented on DERBY-578: > - > > Hi Manish, > > I'm confused about what I'm supposed to do with the > latest attachment. It looks like it might just be > the changes to predicatePushdown.out. Could you give > me a single patch file which contains everything I > need to apply this patch and which I can apply with > a single patch command? Thanks-Rick > > > Grouped select from temporary table raises null > pointer exception in byte code generator > > > > > > > Key: DERBY-578 > > URL: > http://issues.apache.org/jira/browse/DERBY-578 > > Project: Derby > > Type: Bug > > > Components: SQL, Services > > Reporter: Rick Hillegas > > Assignee: Manish Khettry > > Attachments: 578.diff.txt, > predicatePushdown.out.patch > > > > The last statement in the following script: > > autocommit off; > > declare global temporary table session.ztemp > > ( orderID varchar( 50 ) ) > > not logged; > > select orderID from session.ztemp group by > orderID; > > raises the following stack trace in the trunk: > > java.lang.NullPointerException > > at java.util.Hashtable.get(Hashtable.java:333) > > at > org.apache.derby.iapi.services.classfile.ClassHolder.findMatchingEntry(ClassHolder.java:656) > > at > org.apache.derby.iapi.services.classfile.ClassHolder.addUtf8Entry(ClassHolder.java:482) > > at > org.apache.derby.iapi.services.classfile.ClassHolder.addString(ClassHolder.java:506) > > at > org.apache.derby.iapi.services.classfile.ClassHolder.addConstant(ClassHolder.java:302) > > at > org.apache.derby.impl.services.bytecode.BCMethod.push(BCMethod.java:452) > > at > org.apache.derby.impl.sql.compile.FromBaseTable.generateDistinctScan(FromBaseTable.java:3216) > > at > org.apache.derby.impl.sql.compile.FromBaseTable.generateResultSet(FromBaseTable.java:3032) > > at > org.apache.derby.impl.sql.compile.FromBaseTable.generate(FromBaseTable.java:2978) > > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) > > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) > > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) > > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) > > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) > > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) > > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) > > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) > > at > org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(ScrollInsensitiveResultSetNode.java:109) > > at > org.apache.derby.impl.sql.compile.ReadCursorNode.generate(ReadCursorNode.java:118) > > at > org.apache.derby.impl.sql.compile.CursorNode.generate(CursorNode.java:546) > > at > org.apache.derby.impl.sql.compile.StatementNode.generate(StatementNode.java:232) > > at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:433) > > at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:107) > > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:704) > > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:533) > > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480) > > at > org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299) > > at > org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) > > at > org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) > > at > org.apache.derby.impl.tools.ij.Main.go(Main.java:203) > > at > org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169) > > at > org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) > > at org.apache.derby.tools.ij.main(ij.java:60) > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one
[jira] Commented: (DERBY-578) Grouped select from temporary table raises null pointer exception in byte code generator
[ http://issues.apache.org/jira/browse/DERBY-578?page=comments#action_12416588 ] Rick Hillegas commented on DERBY-578: - Hi Manish, I'm confused about what I'm supposed to do with the latest attachment. It looks like it might just be the changes to predicatePushdown.out. Could you give me a single patch file which contains everything I need to apply this patch and which I can apply with a single patch command? Thanks-Rick > Grouped select from temporary table raises null pointer exception in byte > code generator > > > Key: DERBY-578 > URL: http://issues.apache.org/jira/browse/DERBY-578 > Project: Derby > Type: Bug > Components: SQL, Services > Reporter: Rick Hillegas > Assignee: Manish Khettry > Attachments: 578.diff.txt, predicatePushdown.out.patch > > The last statement in the following script: > autocommit off; > declare global temporary table session.ztemp > ( orderID varchar( 50 ) ) > not logged; > select orderID from session.ztemp group by orderID; > raises the following stack trace in the trunk: > java.lang.NullPointerException > at java.util.Hashtable.get(Hashtable.java:333) > at > org.apache.derby.iapi.services.classfile.ClassHolder.findMatchingEntry(ClassHolder.java:656) > at > org.apache.derby.iapi.services.classfile.ClassHolder.addUtf8Entry(ClassHolder.java:482) > at > org.apache.derby.iapi.services.classfile.ClassHolder.addString(ClassHolder.java:506) > at > org.apache.derby.iapi.services.classfile.ClassHolder.addConstant(ClassHolder.java:302) > at > org.apache.derby.impl.services.bytecode.BCMethod.push(BCMethod.java:452) > at > org.apache.derby.impl.sql.compile.FromBaseTable.generateDistinctScan(FromBaseTable.java:3216) > at > org.apache.derby.impl.sql.compile.FromBaseTable.generateResultSet(FromBaseTable.java:3032) > at > org.apache.derby.impl.sql.compile.FromBaseTable.generate(FromBaseTable.java:2978) > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) > at > org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) > at > org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(ScrollInsensitiveResultSetNode.java:109) > at > org.apache.derby.impl.sql.compile.ReadCursorNode.generate(ReadCursorNode.java:118) > at > org.apache.derby.impl.sql.compile.CursorNode.generate(CursorNode.java:546) > at > org.apache.derby.impl.sql.compile.StatementNode.generate(StatementNode.java:232) > at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:433) > at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:107) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:704) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:533) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480) > at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299) > at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) > at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) > at org.apache.derby.impl.tools.ij.Main.go(Main.java:203) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169) > at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) > at org.apache.derby.tools.ij.main(ij.java:60) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
OutBufferedStream test fails on JDK13 platforms ...
I have been seeing this test fail on JDK13 platforms, both SUN and IBM JVMs since the test was committed. Tomohito, do you have access to JDK13 platform and have interest to fix this failure? If not, I can help. Satheesh [bandaram:satheesh] svn log OutBufferedStream.out r405037 | tmnk | 2006-05-08 05:36:39 -0700 (Mon, 08 May 2006) | 1 line - DERBY-326 Improve streaming of large objects for network server and client - Patch by Tomohito Nakayama ([EMAIL PROTECTED])
Re: Did the MessageBundleTest pass before it was made part of derbyall?
On 6/16/06, David Van Couvering <[EMAIL PROTECTED]> wrote: Hm, thanks Andrew. That may very well be, but it was also the case that the master file did not get correctly checked in. I was running in the classes directory. I'll run with the jar files, and see what happens, and correct my logic as needed. Meanwhile, I'll remove MessageBundleTest from derbyall. Note that the test will pass when running from the classes because SQLState will be in your classpath as part of the full class tree. It will continue to fail in jar testing because of the problem I described above. andrew
Re: [jira] Commented: (DERBY-1032) Create new scripts which follow common practice at Apache
I didn't follow how this solution is going to be backward-compatible. I'm assuming we'll be keeping the old ones around, perhaps invoking the new ones? David Andrew McIntyre (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1032?page=comments#action_12416463 ] Andrew McIntyre commented on DERBY-1032: For this change, I propose the following: * create new scripts which replicate the functionality provided by the scripts in the frameworks directories with new scripts which all reside in a single new directory in the -bin distribution: /bin * use the environment variable DERBY_HOME to indicate the location of the Derby installation instead of DERBY_INSTALL. A check to verify that the value is valid, for example verifying that DERBY_HOME/lib/derby.jar exists, might be used. However there are some situation where a simple check may not be desired, for example, if NetworkServerControl is being used in an environment without derby.jar. I need to think about this check a little further. * use the JAVA_HOME variable to determine the location of the Java installation, instead of relying on the java executable being in the path, and provide appropriate warnings if the variable is not set. If JAVA_HOME is not set or the java executable is not on the path, fail with an error. * for maintainability, refactor setup and environment validation to a shared file used by all scripts, although there will be two of these files: one for the set of batch scripts and one for the set of shell scripts. * remove the extension for the Unix shell scripts so that the utilities can be executed by their name. e.g. on a Unix system, instead of the current 'ij.ksh', only 'ij' would need to be typed to execute ij if the PATH contains $DERBY_HOME/bin. * provide a DERBY_OPTS variable that would allow overriding JVM options and setting Derby JVM properties in the use of the scripts, similar to the ANT_OPTS environment variable. (See DERBY-345) The contents of the bin directory would include: dblook(.bat) derby_common(.sh|.bat) ij(.bat) NetworkServerControl(.bat) setEmbeddedCP(.bat) setNetworkClientCP(.bat) setNetworkServerCP(.bat) startNetworkServer(.bat) stopNetworkServer(.bat) sysinfo(.bat) The (.bat) above indicates that for each Unix shell script without an extension, there will be a corresponding Windows batch file. The script which shares the common setup and environment validation logic, derby_common, will have the .sh extension on Unix to prevent accidental execution in Unix shell environments, even though such execution would be harmless. The portability goal for the shell scripts is that they be able to run in any fairly recent shell environment: bash, tcsh, ksh, and zsh on Solaris, Mac OS X, AIX, Linux, and Cygwin and MKS on Windows. Since batch files run only on Windows/DOS, it is only necessary that they meet the requirements listed above. Note that my plan is not to remove the scripts in the frameworks directory at this time, since there may be downstream projects that currently use the scripts. However, the scripts in the frameworks directory should be clearly marked as deprecated and that in the future downstream projects should use the scripts in the bin directory instead. It should also be suggested that the utilities can be invoked directly from a command line with 'java -jar' via the new derbyrun.jar. Please let me know if you see any problems with this proposal. Otherwise, I will post a patch shortly that contains the new scripts for the top-level bin directory. Create new scripts which follow common practice at Apache - Key: DERBY-1032 URL: http://issues.apache.org/jira/browse/DERBY-1032 Project: Derby Type: Improvement Components: Demos/Scripts Versions: 10.2.0.0 Reporter: Andrew McIntyre Assignee: Andrew McIntyre Priority: Minor Scripts for Derby should be written to follow common practice at Apache. This means locating them in a bin directory, and self configuring from the minimum amount of information necessary: installation location and in our case, the location of Java, from the variables DERBY_HOME and JAVA_HOME respectively. If these variables are not set, we should report this to the user. Good examples are available in Ant, Forrest, and Maven, and much of the same setup code can be reused from those projects.
Re: Did the MessageBundleTest pass before it was made part of derbyall?
Hm, thanks Andrew. That may very well be, but it was also the case that the master file did not get correctly checked in. I was running in the classes directory. I'll run with the jar files, and see what happens, and correct my logic as needed. Meanwhile, I'll remove MessageBundleTest from derbyall. David Andrew McIntyre wrote: On 6/15/06, David Van Couvering <[EMAIL PROTECTED]> wrote: I ran derbyall on my machine prior to checkin and it worked. But this checkin was the first time derbyall included MessageBundleTest. It did not pass before then. I must have not properly checked in the output file, is all I can think of. I'll look into this, apologies. The problem is that MessageBundleTest has a direct reference to the class file for the SQLState class (org.apache.derby.shared.common.reference.SQLState.class), which, during compilation, compiles in a reference to the actual class and not one of the public final strings defined by the SQLState class. During compilation, the SQLState class is normally factored out by the compiler, since the Strings it contains can be placed directly into the constant pool of classes that reference it. However, since MessageBundleTest contains a direct reference to SQLState.class, a reference to the fully qualified class file SQLState.class remains in MessageBundleTest.class. This means that the class file for SQLState needs to be present at runtime (e.g., in derbyTesting.jar), or the direct reference to SQLState.class in MessageBundleTest:54 needs to be removed, for the test to pass. andrew
[jira] Commented: (DERBY-396) Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN
[ http://issues.apache.org/jira/browse/DERBY-396?page=comments#action_12416580 ] Wade Chandler commented on DERBY-396: - Hmmm. I think what Scott said was he is working on it and no where did I see where he said it works. He mentions something working in another server. Did you see him write something else some where besides this issue? > Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN > -- > > Key: DERBY-396 > URL: http://issues.apache.org/jira/browse/DERBY-396 > Project: Derby > Type: New Feature > Components: SQL > Environment: LINUX > Reporter: Kumar Matcha > > Alter Statement should support dropping a column, modifying a column to a > different data type , rename a column. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
ApacheCon Asia: August 15-17, 2006, in Sri Lanka
The call for papers is open and the deadline for submissions is July 9: http://www.asia.apachecon.com/ regards, -jean
[jira] Commented: (DERBY-1394) Working With Derby - Introduction and prerequisites - Improvements
[ http://issues.apache.org/jira/browse/DERBY-1394?page=comments#action_12416577 ] Stan Bradbury commented on DERBY-1394: -- Thanks, Halley, for all the attention you are giving to improving Working With Derby. I like your suggestions and think we should go ahead and commit them with possibly a couple of minor adjusts (aka tweaks) as listed below. I'm new to the whole commit and patch process so am uncertain how best to proceed since you have created patches for the issues already. I assume (I would appreciate a confirmation from a commiter) that I could create another patch that performs these 'tweaks' assuming no one opposes them? Comments and 'tweaks' on items in the Description. #1 - Needs to be "section" #2 - "referred to as DERBY_HOME" NOTE: at the time of writing it was (and still is) my understanding that DERBY_HOME will be replacing DERBY_INSTALL throughout the v 10.3 manuals. I wanted to introduce this term early in the document and originally worded it "referred to as DERBY_HOME throughout the manual set". In review this was identified as cumbersome and removed. Your rewrite is an improvement over the current wording. Do you think something like this might highlight the term even better?: Note the filesystem path to the Derby installation (this is commonly referred to as DERBY_HOME in the Derby documentation). Either wording will be a improvement. #3 - Commas Many commas were overlooked, the text is much more readable with them. The only added commas that seem odd to me (and I am not studied in English grammar) are the commas before the lead-in words 'because' and 'that'. Do you know if this is grammatically correct? When speaking I do not normally pause at these points. ..Java database, that can be tightly embedded ... ..relational database engine, that is written and implemented ... ..different from what is shown here, because the java -version command... #4 - Clarifying the download files and unbundling I like the rewrite: >From the Download page use the link to the 'Latest Official Release', then >locate the bin distribution (e.g. db-derby-10.1.2.1-bin.zip and >db-derby-10.1.2.1-bin.tar.gz). Download the appropriate file for your >platform, '-bin.zip' for Windows or '-bin.tar.gz' for Unix/Linux", and >unzip/untar this file. -- Perhaps changes to the versions referenced would also be helpful. I was hesitant to list a filename that would change from release to release (I am not sure there is a naming convention in place for these files). I also realize the document should probably use the likely v10.3 filenames (not 10.1.2.1). Do you think it would be better to abstract the example names with something like "db-derby--bin.tar.gz"? I think it best to avoid touching on 'installation' details. The assumption is that Derby is already installed and the intent of this paragraph is to help the user locate the proper file if, for some reason, they do not know where Derby is installed on the machine. Installation, though simple, can be a topic unto itself and the exact commands differ depending on the OS. I think it best to let people turn to the installation information bundled with the download. If you decide to keep this sentence please change '..the filesystem path choosed..' to '..the filesystem path choosen..'. After decompressing the downloaded file, move the directory created to the filesystem path choosed to be the root directory of the Derby installation (e.g., move db-derby-10.1.2.1-bin C:\Derby) And the suggested rewrite of the 'Welcome ..' paragraph (comment dated Jun 14) is GREAT !! Thanks again for applying your talents to improving this document. > Working With Derby - Introduction and prerequisites - Improvements > -- > > Key: DERBY-1394 > URL: http://issues.apache.org/jira/browse/DERBY-1394 > Project: Derby > Type: Improvement > Components: Documentation > Versions: 10.2.0.0 > Environment: DITA-sourced documentation > Reporter: Halley Pacheco de Oliveira > Priority: Minor > Fix For: 10.2.0.0 > Attachments: twwdIntro.diff, twwdIntro.diff.html, twwdIntro.html, > twwdIntro_2.diff, twwdIntro_2.diff.html, twwdIntro_2.html > > 1) There is a gramatical error: > It's written "sections" and not "section": > "In way of introduction this sections provides a brief description of Derby." > and should be, in my opinion: > "In way of introduction this section provides a brief description of Derby." > 2) DERBY_HOME > It's written: > "Note the filesystem path to the Derby installation (referred to as > DERBY_HOME)." > but DERBY_HOME doesn't appear anywhere else in this page, so it is not > possible > to note it in this page. It only appears in the activities pages. By this > reason, > in my opinion, the sentence should be: > "Note the filesystem path to the Derby inst
Apache Derby (in the guise of Java DB) now shipping in Sun Java SE JDK
As you may or may not have seen on the blogosphere, build 88 of Mustang includes Java DB 10.2, Sun's supported distribution of Derby 10.2. This is great news, both for our team and for developers. Developers get the Best Database In the World (TM) out-of-the box, and Derby will likely get a lot more users and attention! If you want to check it out, please go to http://download.java.net/jdk6/binaries/ David
[jira] Commented: (DERBY-1399) DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
[ http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416568 ] Kathey Marsden commented on DERBY-1399: --- Thanks Olav. I reopened DERBY-930 so a release note can be added descibing the user impact and describe symptoms users might encounter. Then it will be easier for the community to assess if the behavior change is acceptable or this needs to be clasified as a regression. I 'd prefer to not ccommit this patch until that dertermination has been made. > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > --- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Attachments: autoload.diff > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-930) Add support for autoloading of Derby client drivers
[ http://issues.apache.org/jira/browse/DERBY-930?page=all ] Kathey Marsden reopened DERBY-930: -- Reopened because at least release note is needed for behavior change. > Add support for autoloading of Derby client drivers > --- > > Key: DERBY-930 > URL: http://issues.apache.org/jira/browse/DERBY-930 > Project: Derby > Type: New Feature > Components: Build tools, JDBC > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Fix For: 10.2.0.0 > Attachments: ClassloadingTest.jar, bug930.diff, bug930_problem.diff, > bug930_problem2.diff, bug930_rev2.diff, bug930_rev3.diff > > Write Derby's driver names into the correct spot in derby.jar and > derbyclient.jar so that the 1.6 vm autoloads Derby drivers. Section 10.2.1 of > the JDBC4 spec describes the details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-930) Add support for autoloading of Derby client drivers
[ http://issues.apache.org/jira/browse/DERBY-930?page=all ] Kathey Marsden updated DERBY-930: - Derby Info: [Existing Application Impact, Release Note Needed] This change may impact existing applications as evidenced by the need to change a related test in DERBY-1399. It requires at least a release note documenting the impact.Once that has been done it will be easier understand the scope of the problem and whether this is a regression that needs to be addressed or a behaviour change accepted by the community. DERBY-1399 has some informaition on this topic. http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416359 Rick, could you add the release note to this issue? Bryan posted some helpful Release Note format info at: http://wiki.apache.org/db-derby/ReleaseNoteFormat?highlight=%28ReleaseNote%29 > Add support for autoloading of Derby client drivers > --- > > Key: DERBY-930 > URL: http://issues.apache.org/jira/browse/DERBY-930 > Project: Derby > Type: New Feature > Components: Build tools, JDBC > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Fix For: 10.2.0.0 > Attachments: ClassloadingTest.jar, bug930.diff, bug930_problem.diff, > bug930_problem2.diff, bug930_rev2.diff, bug930_rev3.diff > > Write Derby's driver names into the correct spot in derby.jar and > derbyclient.jar so that the 1.6 vm autoloads Derby drivers. Section 10.2.1 of > the JDBC4 spec describes the details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1326) Network server may abandon sessions when Derby system is shutdown and this causes intermittent hangs in the client
Bryan Pendleton wrote: I'm a little worried that DERBY-1326 and DERBY-51 are getting inter-twined, though; it seems like your comments are very applicable to DERBY-51. Yes, the two issues are definitely related. However, let me point out that DERBY-51 is about what happens to "Derby embedded" (aka. the Derby system) when the network server is shut down. My comment to DERBY-1326 was about what happens to the network server when the Derby system (Derby embedded) is shut down - which is more like the opposite of DERBY-51 :) -- John
[jira] Created: (DERBY-1422) Derby web site source needs headers that comply with new ASF policy
Derby web site source needs headers that comply with new ASF policy --- Key: DERBY-1422 URL: http://issues.apache.org/jira/browse/DERBY-1422 Project: Derby Type: Sub-task Components: Web Site Reporter: Jean T. Anderson Assigned to: Jean T. Anderson Derby web site source files need the ASF source file header that was posted to legal-discuss: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Copyrights redux
Hi, Rick I'd like to redo your list in terms of (1) internal for source code vs. (2) externally viewable because the new changes just affect the first. 1) Internal for source code : due date 8/1/06 for releases This is a new policy that takes effect for releases starting Aug 1. It doesn't affect 10.1.3. It affects any release after Aug 1, such as 10.2. Incidently, the best example is the httpd project. At the risk of oversimplifying the objective, my take is there are two primary goals, which helps understand why this change is occurring: - Moving the ASF copyright out of source files and into the NOTICE file clarifies that the ASF copyright is for the collective work. - Anybody who accesses any single source file will know that it may be used. Derby source files affected: - code (needs to be updated) - DITA docs (needs to be updated) - web site -- I haven't paid attention to this, so need to update most files. I'll add a subtask to DERBY-1377, will assign myself to it, and will look at what the Forrest project did because they recently did it. - generated html source for the docs produced by the DITA doc builds. The DITA doc build process needs to be modified to do the right thing. 2) Externally viewable : no changes planned (yet) So at the bottom of http://db.apache.org/derby/ you'll see this line: "Copyright © 2004-2006 Apache Software Foundation" Anyone accessing the web site sees it, which is what I mean by "externally viewable". It doesn't require looking at source to see it. That copyright line is good for now, is the application of http://www.apache.org/dev/apply-license.html#new . It might get changed at some point, perhaps to be a link to a terms and conditions page, but that hasn't been decided yet. Same for the copyright page in each doc. Andrew updated the copyright pages in the 10.1 doc branch yesterday (svn revision 414499 [1]), but I'm not spotting the updates yet in the docs at http://db.apache.org/derby/docs/10.1/ . -jean [1] http://mail-archives.apache.org/mod_mbox/db-derby-commits/200606.mbox/[EMAIL PROTECTED] Rick Hillegas wrote: > Hi Jean, > > While I'm on the topic: I asked these questions in the context of 10.2, > but it seems that issue (2) may apply to 10.1.3 as well. Do the > copyright notices for the 10.1.3 release need to conform to the pattern > in (2)? > > Thanks, > -Rick > > > Rick Hillegas wrote: > >> Hi Jean, >> >> I wanted to confirm with you what we should do about copyright >> notices. Copyright notices seem to appear in three places: >> >> 1) On the Derby website >> >> 2) In the published user guides which we bundle with releases >> >> 3) In the Derby source code, including the source code for the web >> site and the user guides >> >> Here's what I think you have discovered: >> >> 1) We do NOT have to change the copyright notices which appear on the >> web site. >> >> 2) The copyright notices which appear in the user guides need to >> change from >> >> "Copyright 1997, 2005 The Apache Software Foundation or its licensors, >> as applicable." >> >> to >> "Copyright 1997, 2005-2006 The Apache Software Foundation or its >> licensors, as applicable." >> >> 3) We need to rototill the copyright notices in the source code as >> described in DERBY-1377. >> >> Does this sound right to you? >> >> Thanks, >> -Rick > > >
Regression Test Failure! - TinderBox_Derby 414832 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 414832/2006-06-16 16:02:27 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1676675 2 144.76% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-414832.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/414832.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/414832.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Commented: (DERBY-1397) Tuning Guide: Puzzling optimizer documentation
Bryan Pendleton wrote:
Is it really realistic, though, to allow a setting of 2 million,
which gives the optimizer permission to try to create a
in-memory hash table of 2 gigabytes? I mean, I'd need a 64-bit JVM...
Related, is it worth putting a line or two in this doc telling the
user that it would be foolish to set this value to something which
is higher than the actual physical memory that they have on their
machine -- if I have a 256 Mb machine, telling the optimizer to do
a 512 Mb hash join in "memory" is probably performance suicide, no?
I think these are both excellent points, and I think that Yes, it would be a
good idea to add the appropriate notes to the documentation. When I answered
the question of "max value", I was just looking at it from a programmatic
standpoint--but as you've pointed out, there are some practical considerations
here, as well. Note that "performance suicide" is the right term here--as
described below, the query *should* theoretically still execute, but it might
suffer from a spill-to-disk performance penalty.
Also, perhaps we should have a line suggesting that if the
user decides to increase this value, they should check their JVM
memory settings and make sure they've authorized the JVM to use
that much memory (e.g., on Sun JVMs, -XmxNNNm should be set).
Sounds good to me--thanks for pointing that out. Note though, that if the user
does not give the JVM more memory, the query should (in theory) still work--see
below--but it might take a performance hit at execution time.
Lastly, what is the symptom if the user sets this too high? If
they tell the optimizer that it's allowed to make, for example,
a 200 Mb hash table by setting this value to 200,000, then what
happens if the runtime evaluation of the query plan finds that
it can't allocate that much memory? Does the query fail? Does
Derby crash?
Yet another very good question. I haven't done thorough testing, but my *guess*
is that this issue is indirectly addressed by some "follow-up" changes that I
posted for DERBY-1007: in particular, see the BackingStoreHashtable changes in
d1007_followup_v1.patch, which is attached to that issue. The changes there do
a very rough (and only slightly meaningful, unit-wise) comparison of estimated
row count to max in-memory size, and if it thinks there's not enough memory in
the JVM, it will create a smaller hash table and then spill the excess to disk.
I looked at the relevant code in the BackingStoreHashtable and the value of
max_inmemory_size is set as follows:
if( max_inmemory_rowcnt > 0)
max_inmemory_size = Long.MAX_VALUE;
else
max_inmemory_size = Runtime.getRuntime().totalMemory()/100;
where max_inmemory_rowcnt is received from the optimizer. So far as I can tell
from the quick tests I did, in cases where we're creating a hash table for a
hash join as determined by the optimizer, max_inmemory_rowcnt is always -1 and
thus max_inmemory_size is set based on the available JVM memory at the time the
backing store hash table is created. In such a case the BackingStoreHashtable
will receive the estimated row count from the optimizer. If the
maxMemoryPerTable was set "too high", then the estimated row count that we get
could be insanely high, as well (if maxMemoryPerTable was lower, the optimizer
would have rejected the hash join and we never would have made it here). That
said, the DERBY-1007 follow-up changes added logic to change the way a hash
table is built if the estimated row count is "too high": namely, if it's equal
to or larger than the max in-memory bytes, we'll create a hash table that is
only as large as { max in-memory bytes / estimated size of first row }.
And that, I think, means that we should only create a hash table that will
actually fit in the available JVM memory; if we need a larger hash table, then
we'll spill to disk and take the performance hit, but the query should still
execute. In theory.
Of course, all of that is assuming that the "red flag" for a large hash table is
a high row count. If it turns out that we have a low row count but each row is
extremely large, the changes for DERBY-1007 will not be triggered. I think,
however, that we should still be okay, but for a different reason. In this
scenario, the hash table itself will not be very large, so we should have enough
memory to create it (empty). Then, the BackingStoreHashtable code keeps track
of how much JVM memory is available after each insertion into the hash table.
So if we have a couple of very large rows, the available memory will decrease
with each row and the optimizer will start spilling to disk before the hash
table is full--which should keep us from running out of memory...
I think. If I've got any of this wrong, someone please feel free to correct me!
So to get back to your final question of "what is the symptom if the user sets
this too high?", the theoretical answer is that
[jira] Updated: (DERBY-1413) SQL State STORE_XA_XAER_DUPID does not have a matching message
[ http://issues.apache.org/jira/browse/DERBY-1413?page=all ] Mike Matrigali updated DERBY-1413: -- Assign To: (was: Mike Matrigali) As described above I looked at creating a message for this, but my take is that one exists. I am taking myself off the issue. > SQL State STORE_XA_XAER_DUPID does not have a matching message > -- > > Key: DERBY-1413 > URL: http://issues.apache.org/jira/browse/DERBY-1413 > Project: Derby > Type: Bug > Components: Store > Versions: 10.1.2.3 > Reporter: David Van Couvering > Fix For: 10.2.0.0 > > STORE_XA_XAER_DUPID is used by impl.store.raw.xact.XactFactory and Xact, and > in derby.jdbc.EmbedXAResource, but it has no message associated with it. > This is a real problem as all the user will get is the word "UNKNOWN" and > whatever parameters are associated with the message. Uncovered by the test > i18n/MessageBundleTest.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1392) Corner case behaviour in RAFContainer#writePage() can cause invalid data to be written to data files
[ http://issues.apache.org/jira/browse/DERBY-1392?page=all ] Mike Matrigali resolved DERBY-1392: --- Fix Version: 10.1.3.1 Resolution: Fixed I merged/resolved conflicts from this change in the trunk to the 10.1 branch and committed as follows: m101_142:56>svn commit Sending java\engine\org\apache\derby\impl\store\raw\data\RAFContainer.java Transmitting file data . Committed revision 414853. > Corner case behaviour in RAFContainer#writePage() can cause invalid data to > be written to data files > > > Key: DERBY-1392 > URL: http://issues.apache.org/jira/browse/DERBY-1392 > Project: Derby > Type: Bug > Components: Store > Versions: 10.2.0.0, 10.1.2.0 > Environment: Platforms that throw an IOException when writing beyond the > EOF, but permit the write to proceed if the file is padded, then written. > Reporter: Anders Morken > Assignee: Anders Morken > Priority: Minor > Fix For: 10.2.0.0, 10.1.3.1 > Attachments: DERBY-1392-1.patch > > java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java#writePage(...) > will > attempt to retry a write if an IOException is thrown on the first attempt. > However, the next > attempt does not add container header data to the first page, nor does it > encrypt the data > if the database is encrypted. > I'd expect this bug to be case silent corruption of encrypted databases if > the code path > was actually exercised. The fact that this bug still lives and nobody has > discovered it is > possibly an indication of how uncommon this code path is. Since the comment > in the code > says nothing about exactly what platforms the workaround was intended for, I > don't know if > these platforms are still supported for Derby. There's also a workaround for > an EPOC Java > bug earlier in the code - EPOC only had a Java 1.1 VM, which is no longer > supported. > I'll attach a patch for the issue, but I wonder if we might as well remove > the "retry code path" > if it is never used? > (If you're paranoid, this could also be considered a security issue. If > someone could > cause IO errors for Derby at will, they could make Derby write the database > without > encryption - but there are far easier ways to attack Derby if you've got that > kind of > access, so I'm discounting that. =) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1326) Network server may abandon sessions when Derby system is shutdown and this causes intermittent hangs in the client
John H. Embretsen (JIRA) wrote: I don't know if this is very helpful with regards to this Jira issue. Thanks, John; this is definitely helpful. I'm a little worried that DERBY-1326 and DERBY-51 are getting inter-twined, though; it seems like your comments are very applicable to DERBY-51. I need to spend some time trying to break the DERBY-1326 changes into smaller pieces so that we can make progress in little steps. Network Server startup and shutdown are quite complicated! thanks, bryan
Possible CPU loop in testProtocol in cross-release scenario?
I was trying to verify that the changes in DERBY-920 hadn't introduced any new compatibility problems (they shouldn't, because we were changing an internal class, but I wanted to make sure). So I was trying to follow some old tips about how to run tests with an old client against a new server, as documented in: http://wiki.apache.org/db-derby/TestingOldClientNewServer However, when I did this, the test "testProtocol" did not terminate. Instead, it entered a hard CPU loop consuming 100% of my machine, until I killed the test process. Can somebody please try these steps (from the wiki page) against the current trunk and see whether or not you get the same CPU loop problem that I got? thanks, bryan
[jira] Assigned: (DERBY-1421) ResultSet.updateBinaryStream fails when the result type is TYPE_SCROLL_INSENSITIVE
[ http://issues.apache.org/jira/browse/DERBY-1421?page=all ] Fernanda Pizzorno reassigned DERBY-1421: Assign To: Fernanda Pizzorno > ResultSet.updateBinaryStream fails when the result type is > TYPE_SCROLL_INSENSITIVE > -- > > Key: DERBY-1421 > URL: http://issues.apache.org/jira/browse/DERBY-1421 > Project: Derby > Type: Bug > Components: JDBC > Reporter: V.Narayanan > Assignee: Fernanda Pizzorno > Attachments: TestUpdateBinaryStream.java > > Attaching test program for the above bug. The program however works fine when > the ResultSetType is TYPE_FORWARD_ONLY. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1421) ResultSet.updateBinaryStream fails when the result type is TYPE_SCROLL_INSENSITIVE
[ http://issues.apache.org/jira/browse/DERBY-1421?page=all ] V.Narayanan updated DERBY-1421: --- Attachment: TestUpdateBinaryStream.java The above program fails with the following message Exception in thread "main" org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED statementContext is not expected to equal statementContexts[0] at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:119) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.popStatementContext(GenericLanguageConnectionContext.java:2027) at org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3577) at TestUpdateBinaryStream.main(TestUpdateBinaryStream.java:43) Java Result: 1 > ResultSet.updateBinaryStream fails when the result type is > TYPE_SCROLL_INSENSITIVE > -- > > Key: DERBY-1421 > URL: http://issues.apache.org/jira/browse/DERBY-1421 > Project: Derby > Type: Bug > Components: JDBC > Reporter: V.Narayanan > Attachments: TestUpdateBinaryStream.java > > Attaching test program for the above bug. The program however works fine when > the ResultSetType is TYPE_FORWARD_ONLY. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1421) ResultSet.updateBinaryStream fails when the result type is TYPE_SCROLL_INSENSITIVE
ResultSet.updateBinaryStream fails when the result type is TYPE_SCROLL_INSENSITIVE -- Key: DERBY-1421 URL: http://issues.apache.org/jira/browse/DERBY-1421 Project: Derby Type: Bug Components: JDBC Reporter: V.Narayanan Attaching test program for the above bug. The program however works fine when the ResultSetType is TYPE_FORWARD_ONLY. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
[ http://issues.apache.org/jira/browse/DERBY-137?page=comments#action_12416518 ] Knut Anders Hatlen commented on DERBY-137: -- I have (or more precisely, a test program of mine has) gone through all the DatabaseMetaData methods and compared them to the JDBC 4 spec. This is what I found: 1) Columns are missing from getColumns(), getTables() and getUDTs(). 2) Some columns that the spec says should be "int" are returned as "SMALLINT", and some columns that should be "short" are returned as "INTEGER". What's the best solution for 2? Changing all queries so that short maps to SMALLINT and int to INTEGER? Or should we accept other types as long as they could contain all values of the specified type (that is, allow short to be returned as INTEGER, but not int as SMALLINT)? > Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result > sets are required. > > > Key: DERBY-137 > URL: http://issues.apache.org/jira/browse/DERBY-137 > Project: Derby > Type: Bug > Components: JDBC > Reporter: A B > Assignee: Knut Anders Hatlen > Priority: Critical > > BACKGROUND: > Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns > result sets that are defined by the SQL queries in > impl/jdbc/metadata.properties. > PROBLEM: > The current queries in the metadata.properties file are for JDBC 2 only. The > queries do NOT account for the result sets as defined by JDBC 3, and thus > even when JDBC 3 result sets should be returned, a user will get metadata > correlating to the JDBC 2 standard. > Just for reference, here are a couple of examples of changes that have been > made from JDBC 2 to JDBC 3: > 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four > extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and > SOURCE_DATA_TYPE). > 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five > extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, > and REF_GENERATION). > 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a "short"; JDBC > 3 specifies that DATA_TYPE is an "int". > NOTES: > JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to > just modify metadata.properties to return JDBC 3 result sets... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-920) small delta's to replace cloudscape etc with derby in comments/code
[ http://issues.apache.org/jira/browse/DERBY-920?page=all ] Bryan Pendleton resolved DERBY-920: --- Fix Version: 10.2.0.0 Resolution: Fixed Committed to subversion as revision 414832. http://svn.apache.org/viewcvs?rev=414832&view=rev Thanks Scott for the patch. > small delta's to replace cloudscape etc with derby in comments/code > --- > > Key: DERBY-920 > URL: http://issues.apache.org/jira/browse/DERBY-920 > Project: Derby > Type: Task > Environment: N/A > Reporter: scott hutinger > Assignee: Bryan Pendleton > Priority: Trivial > Fix For: 10.2.0.0 > Attachments: sysinfo-main.diff.gz, updatedDiff.txt > > Smaller delta's to modify older source code comments which in some cases > should be updated. Many cases older owners of the source should be kept > intact, as it refers to past or future tenses in a context where changes are > not needed/wanted. > Smaller delta's so this might happen some day :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-920) small delta's to replace cloudscape etc with derby in comments/code
[ http://issues.apache.org/jira/browse/DERBY-920?page=all ] Bryan Pendleton updated DERBY-920: -- Derby Info: (was: [Patch Available]) > small delta's to replace cloudscape etc with derby in comments/code > --- > > Key: DERBY-920 > URL: http://issues.apache.org/jira/browse/DERBY-920 > Project: Derby > Type: Task > Environment: N/A > Reporter: scott hutinger > Assignee: Bryan Pendleton > Priority: Trivial > Attachments: sysinfo-main.diff.gz, updatedDiff.txt > > Smaller delta's to modify older source code comments which in some cases > should be updated. Many cases older owners of the source should be kept > intact, as it refers to past or future tenses in a context where changes are > not needed/wanted. > Smaller delta's so this might happen some day :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=all ] Ole Solberg updated DERBY-989: -- Attachment: 989-411220-derbyall_derbyall_unit_unit_derby.log Mike Matrigali wrote: Re: are actual result files for sun's DBTG test runs kept around? > I am looking at DERBY-989 and it would help to see the derby.log file > from the reported diff. I looked at the public web site: > http://www.multinet.no/~solberg/public/Apache/, but I could > only find reports on the results, not the actual results. I could very > well have missed something, and also would not be surprised if for > space these were not kept. > I have attached derby.log for one case. I also put the full dump of the test run in http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/411220.zip (temporarily). > unit/daemonService.unit fails intermittently: 'ran out of time' > --- > > Key: DERBY-989 > URL: http://issues.apache.org/jira/browse/DERBY-989 > Project: Derby > Type: Test > Components: Regression Test Failure > Versions: 10.2.0.0 > Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: > Sun Microsystems Inc. 1.5.0_04 > OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun > Microsystems Inc. 1.5.0_03 > OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux > 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun > Microsystems Inc. 1.5.0_03 > Reporter: Ole Solberg > Priority: Minor > Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log > > "Signature": > * Diff file unit/unit/daemonService.diff > *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** > 2 del > < -- Unit Test T_DaemonService finished > 2 add > > ran out of time > > Shutting down due to unit test failure. > > Exit due to time bomb > Test Failed. > *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** > http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html > [SunOS-5.10 i86pc-i386] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1326) Network server may abandon sessions when Derby system is shutdown and this causes intermittent hangs in the client
[
http://issues.apache.org/jira/browse/DERBY-1326?page=comments#action_12416494 ]
John H. Embretsen commented on DERBY-1326:
--
> Deepa Remesh commented:
> ---
[snip]
> From current behaviour, we do not shutdown network server when we shutdown
> Derby. Does anyone know if there is any plan to do as indicated by the
> comment: "Want to use Monitor.startModule, so it can all get shutdown when
> cloudscape shuts down, but can't get it working right now." ?
Speaking of current behaviour, here are some observations I have made recently:
a) In the "embedded server using properties" scenario, the Network Server
starts when the embedded driver is loaded and stops when it is "unloaded", i.e.
when the Derby system is shut down:
DriverManager.getConnection("jdbc:derby:;shutdown=true");
b) In the "embedded server using NetworkServerControl API" scenario, the
Network server of course starts when NetworkServerControl.start() is called,
and stops when shutdown() is called. However, if the Derby system is shut down
(by loading the embedded driver and doing as shown above), clients can no
longer connect (getting "No suitable driver". Why?). The Network Server port
seems to be listening on the same port still, though, according to netstat.
Then, if I try to restart the server using the API (without calling shutdown()
first), I get the message "Could not listen on port 1527 on host 0.0.0.0.".
This makes sense, since the port is already in use. However, after start() is
called the second time, clients _are_ in fact able to connect. There seems to
be something happening when start() is called, even if the port is busy, that
is needed to make the server able to accept connections again.
I have not done any code inspection in these cases, so I don't know if this is
very helpful with regards to this Jira issue. I just reacted when I saw the
above comment.
> Network server may abandon sessions when Derby system is shutdown and this
> causes intermittent hangs in the client
> --
>
> Key: DERBY-1326
> URL: http://issues.apache.org/jira/browse/DERBY-1326
> Project: Derby
> Type: Bug
> Components: Network Server
> Reporter: Deepa Remesh
> Assignee: Bryan Pendleton
> Attachments: repro1326.java, resolve_DRDConnThread_conflict.diff,
> sessionMgmt1.diff, sessionMgmt1_and_nosessionsforclosedthreads.diff,
> unify_NSImpl_instances.diff, withNewThreadAndNoShutdownOfCurrentSession.diff
>
> This issue was found when working on DERBY-1219. More details can be found in
> the comments at http://issues.apache.org/jira/browse/DERBY-1219
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Copyrights redux
Hi Jean, While I'm on the topic: I asked these questions in the context of 10.2, but it seems that issue (2) may apply to 10.1.3 as well. Do the copyright notices for the 10.1.3 release need to conform to the pattern in (2)? Thanks, -Rick Rick Hillegas wrote: Hi Jean, I wanted to confirm with you what we should do about copyright notices. Copyright notices seem to appear in three places: 1) On the Derby website 2) In the published user guides which we bundle with releases 3) In the Derby source code, including the source code for the web site and the user guides Here's what I think you have discovered: 1) We do NOT have to change the copyright notices which appear on the web site. 2) The copyright notices which appear in the user guides need to change from "Copyright 1997, 2005 The Apache Software Foundation or its licensors, as applicable." to "Copyright 1997, 2005-2006 The Apache Software Foundation or its licensors, as applicable." 3) We need to rototill the copyright notices in the source code as described in DERBY-1377. Does this sound right to you? Thanks, -Rick
Copyrights redux
Hi Jean, I wanted to confirm with you what we should do about copyright notices. Copyright notices seem to appear in three places: 1) On the Derby website 2) In the published user guides which we bundle with releases 3) In the Derby source code, including the source code for the web site and the user guides Here's what I think you have discovered: 1) We do NOT have to change the copyright notices which appear on the web site. 2) The copyright notices which appear in the user guides need to change from "Copyright 1997, 2005 The Apache Software Foundation or its licensors, as applicable." to "Copyright 1997, 2005-2006 The Apache Software Foundation or its licensors, as applicable." 3) We need to rototill the copyright notices in the source code as described in DERBY-1377. Does this sound right to you? Thanks, -Rick
Regression Test Failure! - TinderBox_Derby 414797 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 414797/2006-06-16 12:22:27 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1676675 2 142.82% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-414797.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/414797.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/414797.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Resolved: (DERBY-501) Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery()
[ http://issues.apache.org/jira/browse/DERBY-501?page=all ] Knut Anders Hatlen resolved DERBY-501: -- Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 414795. > Client and embedded drivers differ on invoking a procedure that returns a > single Dynamic resultSet using CallableStatement.executeQuery() > - > > Key: DERBY-501 > URL: http://issues.apache.org/jira/browse/DERBY-501 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.1.1.0, 10.0.2.1 > Environment: All Platforms > Reporter: Satheesh Bandaram > Assignee: Knut Anders Hatlen > Fix For: 10.2.0.0 > Attachments: Test.java, Test1.java, derby-501-v1.diff, derby-501-v1.stat, > derby-501-v2.diff, derby-501-v2.stat, derby-501-v3.diff, derby-501-v3.stat > > It is possible to invoke a stored procedure that returns a single dynamic > result using CallableStatement.executeQuery using Derby Client. The embedded > JDBC driver, however, throws an exception like: > Test starting ...url = jdbc:derby:tdb > Exception in thread "main" ERROR X0Y78: Statement.executeQuery() cannot be > called with a statement that returns a row count. > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) > at > org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:434) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1142) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1323) > at > org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(EmbedCallableStatement.java:109) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:241) > at Test1.main(Test1.java:26) > I think the embedded driver behavior is incorrect here, though I would double > check that the JDBC spec says. > To reproduce the problem, > 1) Create a database called 'tdb' and a table called COMPANY as create table > COMPANY(name char(10)); > 2) Insert two rows as: insert into COMPANY values 'IBM', 'SUN'; > 3) register a procedure as: > CREATE PROCEDURE GETALLCOMPANIES() PARAMETER STYLE JAVA LANGUAGE JAVA READS > SQL DATA DYNAMIC RESULT SETS 1 EXTERNAL NAME 'Test.getAllCompanies' > 4) Set server classpath > 5) Compile two attached java programs, Test and Test1 > 6) Execute 'java Test1 1' to run as a client program and 'java Test1 2' to > run as an embedded program. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1388) Integrate processing code of two writeScalarStream methods.
[ http://issues.apache.org/jira/browse/DERBY-1388?page=all ] Tomohito Nakayama resolved DERBY-1388: -- Resolution: Fixed > Integrate processing code of two writeScalarStream methods. > --- > > Key: DERBY-1388 > URL: http://issues.apache.org/jira/browse/DERBY-1388 > Project: Derby > Type: Sub-task > Components: Network Client > Reporter: Tomohito Nakayama > Assignee: Tomohito Nakayama > Attachments: DERBY-1388.patch > > Reading the two of writeScalarStream methods in > org.apache.derby.client.net.Request class, > I found that one is for InputStream and another is for Reader and > that they are independent methods. > I think these two methods should share integrated method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Sun DBTG testing for 10.1.3.0
Sun DBTG testing for the 10.1.3.0 release will start today and results will be published under http://www.multinet.no/~solberg/public/Apache/index.html . Our testcycle and analysis are expected to be finished early next week. -- With kind regards, Henri van de Scheur QA - Database Technology Group Sun Microsystems Trondheim
Regression Test Failure! - Derby 414643 - Sun DBTG
[Auto-generated mail] *Derby* 414643/2006-06-15 19:46:09 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 16713697 0 115.76% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-414643.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/414643.html *Jvm: 1.5* 4673669 2 109.14% CYGWIN_NT-5.1_i686-unknown 3673670 2 116.51% CYGWIN_NT-5.2_i686-unknown 1673672 2 117.20% Linux-2.6.14-1.1644_FC4_i686-i686 1673672 2 105.74% Linux-2.6.9-34.ELsmp_x86_64-x86_64 2673671 2 176.59% SunOS-5.10_i86pc-i386 1673672 2 136.29% SunOS-5.10_sun4u-sparc 5673668 2 108.17% SunOS-5.11_i86pc-i386 1673672 2 115.07% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-414643.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/414643.html *Jvm: 1.4* 2667665 4 102.73% CYGWIN_NT-5.1_i686-unknown 2667665 4 114.16% Linux-2.6.14-1.1644_FC4_i686-i686 1667666 4 106.18% Linux-2.6.9-34.ELsmp_x86_64-x86_64 2667665 4 211.42% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-414643.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/414643.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/414643.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: Did the MessageBundleTest pass before it was made part of derbyall?
On 6/15/06, David Van Couvering <[EMAIL PROTECTED]> wrote: I ran derbyall on my machine prior to checkin and it worked. But this checkin was the first time derbyall included MessageBundleTest. It did not pass before then. I must have not properly checked in the output file, is all I can think of. I'll look into this, apologies. The problem is that MessageBundleTest has a direct reference to the class file for the SQLState class (org.apache.derby.shared.common.reference.SQLState.class), which, during compilation, compiles in a reference to the actual class and not one of the public final strings defined by the SQLState class. During compilation, the SQLState class is normally factored out by the compiler, since the Strings it contains can be placed directly into the constant pool of classes that reference it. However, since MessageBundleTest contains a direct reference to SQLState.class, a reference to the fully qualified class file SQLState.class remains in MessageBundleTest.class. This means that the class file for SQLState needs to be present at runtime (e.g., in derbyTesting.jar), or the direct reference to SQLState.class in MessageBundleTest:54 needs to be removed, for the test to pass. andrew
[jira] Assigned: (DERBY-1064) Delete cascade causes NULL values inserted into table when after delete Trigger fires
[ http://issues.apache.org/jira/browse/DERBY-1064?page=all ] Fernanda Pizzorno reassigned DERBY-1064: Assign To: Fernanda Pizzorno > Delete cascade causes NULL values inserted into table when after delete > Trigger fires > - > > Key: DERBY-1064 > URL: http://issues.apache.org/jira/browse/DERBY-1064 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.1.1.0 > Reporter: Susan Cline > Assignee: Fernanda Pizzorno > > When an after delete trigger which inserts into a table is created on a table > that has a foreign key that references a primary key and uses the on delete > cascade constraint, nulls are inserted into the table by the trigger. > The SQL below shows that the cascade delete works correctly: > ij> CREATE TABLE TABLE1 ( X INT PRIMARY KEY ); > 0 rows inserted/updated/deleted > ij> CREATE TABLE TABLE1_DELETIONS ( X INT ); > 0 rows inserted/updated/deleted > ij> CREATE TABLE TABLE2 ( > Y INT, > CONSTRAINT Y_AND_X FOREIGN KEY(Y) REFERENCES TABLE1(X) ON DELETE CASCADE > ); > 0 rows inserted/updated/deleted > ij> CREATE TABLE TABLE2_DELETIONS ( Y INT ); > 0 rows inserted/updated/deleted > ij> INSERT INTO TABLE1 VALUES (0); > 1 row inserted/updated/deleted > ij> INSERT INTO TABLE2 VALUES (0); > 1 row inserted/updated/deleted > ij> INSERT INTO TABLE1 VALUES (1); > 1 row inserted/updated/deleted > ij> INSERT INTO TABLE2 VALUES (1); > 1 row inserted/updated/deleted > ij> select * from table1; > X > --- > 0 > 1 > 2 rows selected > ij> select * from table2; > Y > --- > 0 > 1 > 2 rows selected > ij> DELETE FROM TABLE1; > 2 rows inserted/updated/deleted > ij> select * from table1; > X > --- > 0 rows selected > ij> select * from table2; > Y > --- > 0 rows selected > Now insert the rows again, create the triggers, delete the rows from the > primary key table, verify the cascade delete worked and observe the values in > the tables used by the triggers: > ij> INSERT INTO TABLE1 VALUES(0); > 1 row inserted/updated/deleted > ij> INSERT INTO TABLE2 VALUES(0); > 1 row inserted/updated/deleted > ij> INSERT INTO TABLE1 VALUES(1); > 1 row inserted/updated/deleted > ij> INSERT INTO TABLE2 VALUES(1); > 1 row inserted/updated/deleted > ij> CREATE TRIGGER TRIGGER1 > AFTER DELETE ON TABLE1 > REFERENCING OLD AS OLD_ROW > FOR EACH ROW MODE DB2SQL > INSERT INTO TABLE1_DELETIONS VALUES (OLD_ROW.X); > 0 rows inserted/updated/deleted > ij> CREATE TRIGGER TRIGGER2 > AFTER DELETE ON TABLE2 > REFERENCING OLD AS OLD_ROW > FOR EACH ROW MODE DB2SQL > INSERT INTO TABLE2_DELETIONS VALUES (OLD_ROW.Y); > 0 rows inserted/updated/deleted > ij> DELETE FROM TABLE1; > 2 rows inserted/updated/deleted > ij> select * from TABLE1; > X > --- > 0 rows selected > ij> select * from TABLE2; > Y > --- > 0 rows selected > ij> SELECT * FROM TABLE1_DELETIONS; > X > --- > 0 > 1 > 2 rows selected > ij> SELECT * FROM TABLE2_DELETIONS; > Y > --- > NULL > NULL > The TABLE2_DELETIONS table contains NULLs instead of the correct values which > should be 0 and 1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1032) Create new scripts which follow common practice at Apache
[ http://issues.apache.org/jira/browse/DERBY-1032?page=comments#action_12416463 ] Andrew McIntyre commented on DERBY-1032: For this change, I propose the following: * create new scripts which replicate the functionality provided by the scripts in the frameworks directories with new scripts which all reside in a single new directory in the -bin distribution: /bin * use the environment variable DERBY_HOME to indicate the location of the Derby installation instead of DERBY_INSTALL. A check to verify that the value is valid, for example verifying that DERBY_HOME/lib/derby.jar exists, might be used. However there are some situation where a simple check may not be desired, for example, if NetworkServerControl is being used in an environment without derby.jar. I need to think about this check a little further. * use the JAVA_HOME variable to determine the location of the Java installation, instead of relying on the java executable being in the path, and provide appropriate warnings if the variable is not set. If JAVA_HOME is not set or the java executable is not on the path, fail with an error. * for maintainability, refactor setup and environment validation to a shared file used by all scripts, although there will be two of these files: one for the set of batch scripts and one for the set of shell scripts. * remove the extension for the Unix shell scripts so that the utilities can be executed by their name. e.g. on a Unix system, instead of the current 'ij.ksh', only 'ij' would need to be typed to execute ij if the PATH contains $DERBY_HOME/bin. * provide a DERBY_OPTS variable that would allow overriding JVM options and setting Derby JVM properties in the use of the scripts, similar to the ANT_OPTS environment variable. (See DERBY-345) The contents of the bin directory would include: dblook(.bat) derby_common(.sh|.bat) ij(.bat) NetworkServerControl(.bat) setEmbeddedCP(.bat) setNetworkClientCP(.bat) setNetworkServerCP(.bat) startNetworkServer(.bat) stopNetworkServer(.bat) sysinfo(.bat) The (.bat) above indicates that for each Unix shell script without an extension, there will be a corresponding Windows batch file. The script which shares the common setup and environment validation logic, derby_common, will have the .sh extension on Unix to prevent accidental execution in Unix shell environments, even though such execution would be harmless. The portability goal for the shell scripts is that they be able to run in any fairly recent shell environment: bash, tcsh, ksh, and zsh on Solaris, Mac OS X, AIX, Linux, and Cygwin and MKS on Windows. Since batch files run only on Windows/DOS, it is only necessary that they meet the requirements listed above. Note that my plan is not to remove the scripts in the frameworks directory at this time, since there may be downstream projects that currently use the scripts. However, the scripts in the frameworks directory should be clearly marked as deprecated and that in the future downstream projects should use the scripts in the bin directory instead. It should also be suggested that the utilities can be invoked directly from a command line with 'java -jar' via the new derbyrun.jar. Please let me know if you see any problems with this proposal. Otherwise, I will post a patch shortly that contains the new scripts for the top-level bin directory. > Create new scripts which follow common practice at Apache > - > > Key: DERBY-1032 > URL: http://issues.apache.org/jira/browse/DERBY-1032 > Project: Derby > Type: Improvement > Components: Demos/Scripts > Versions: 10.2.0.0 > Reporter: Andrew McIntyre > Assignee: Andrew McIntyre > Priority: Minor > > Scripts for Derby should be written to follow common practice at Apache. This > means locating them in a bin directory, and self configuring from the minimum > amount of information necessary: installation location and in our case, the > location of Java, from the variables DERBY_HOME and JAVA_HOME respectively. > If these variables are not set, we should report this to the user. Good > examples are available in Ant, Forrest, and Maven, and much of the same setup > code can be reused from those projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
