[jira] Commented: (DERBY-658) test harness improvements required for running on non-ASCII systems
[ http://issues.apache.org/jira/browse/DERBY-658?page=comments#action_12373581 ] Myrna van Lunteren commented on DERBY-658: -- While I am getting closer to finish steps 2-5, I have some questions re step 6. Currently, I think the easiest way to implement it is to read the .out file generated in local encoding (which is how it's always been) back in and write it out in fixed encoding. I was thinking of adding a property, say, generateUTF8Out, into RunTest, which would create an additional file, .utf8out. Basically, the harness would do what native2ascii does. It would mean that a developer would have to run an individual test with the generateUTF8Out property on the command line (not in properties files), then copy the .utf8out to the location for the .out in the source tree, instead of the .out, as we'd do currently. All this would only be necessary if you're working in a non-UTF-8 compatible encoding, I think. Is this an OK approach? Myrna > test harness improvements required for running on non-ASCII systems > --- > > Key: DERBY-658 > URL: http://issues.apache.org/jira/browse/DERBY-658 > Project: Derby > Type: Bug > Components: Test > Versions: 10.1.1.0 > Environment: all but especially testing should be done on zOS > Reporter: Myrna van Lunteren > Assignee: Myrna van Lunteren > Priority: Minor > Fix For: 10.2.0.0 > > The current functionTests test harness needs adjustment for running on > non-ASCII systems like zOS. > Currently, when using derbyTesting.jar built for instance on a windows or > linux system on zOS the tests do not run, because the properties and runall > files cannot be understood. > Until now, testers on zOS had to unjar derbyTesting.jar, then run > native2ascii -Cp 1047 -reverse on all appropriate files (.sql, .txt, .out, > .properties, .runall, .asc, .exclude, etc). > This is a labor intensive and error prone process. Furthermore, it causes > test failures such as reported with DERBY-575, because tests may assume a > certain file to be a specific length, which no longer holds true after the > native2ascii conversion. > The test harness should get modified to always read the files in the same > encoding. > Note however, that the comparison of actual .out and the master should still > result in files readable on the local system, to enable a human to evaluate > failures and results. At the same time, this raises the concern that someone > might check-in an update to the master with an incorrect encoding. > To resolve the main issue, I propose the following: > - Set the default encoding in the harness. > - for each test > 1) determine if the test encoding is set. We can probably use ij.ui.codeset > - otherwise a new property is needed. > Note that this means that .properties, .runall and .exclude files are > always read in fixed/default encoding. > 2) read the master/sql files in in the default/fixed encoding unless the > encoding property is set for a test > 3) Write the output out in the local encoding (the way is done currently) > unless the encoding property is set (if set, write out in that encoding) > 4) Change the code that creates tmpmstr to always apply instead of only for > networkserver. tmpmstr files will be created in the local encoding. > 5) Have FileCompare read tmpmstr in in the local encoding for the comparison. > 6) either document that test development/adjustment need to be at least be > verified on an ascii system, or add another property that causes a copy of > the actual output to be created in the default/fixed encoding. -- 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
Regression Test Failure! - TinderBox_Derby 392148 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 392148/2006-04-07 03:23:01 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2647645 0 244.36% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-392148.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/392148.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/392148.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
New query language
Hi, SQL has a lot of problems; it is incomplete, unfriendly, unsound, too huge, confusing, inconsistent, etc. [1, 2, 3] It is the more ugly language that I ever see. For many reasons, it seems that no DBMS vendor is interested to create a better language. So my question: why don't we - the open source community - take the lead and create a new language that could be the basis for a future standard? Regards, -Jean [1] http://web.onetel.com/~hughdarwen/TheThirdManifesto/HAVING-A-Blunderful-Time.html [2] http://www.thethirdmanifesto.com/ [3] http://www.ipipan.waw.pl/~subieta/artykuly/CritiqObjAlg.html
Re: Upgrade Testing - more tests needed for 10.2 ?
> Is there a document for developers somewhere that explains the kinds of > changes that impact upgrade, and how you go about writing a test an > upgrade-impacting change? I'm a bit mystified myself right now... > (although I'm pretty darn sure i18n changes in the client don't impact > upgrade :) ). I don't think there is a document which summarizes the kinds of changes that may impact upgrade. I think this article helps: http://db.apache.org/derby/papers/versionupgrade.html. Other than that, the various discussions are spread out in the mails. For adding tests, please look at the case* methods in org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester. I'll try to add information about the test to a Wiki page. Thanks, Deepa
Regression Test Failure! - TinderBox_Derby 392061 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 392061/2006-04-06 22:22:23 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2647645 0 245.66% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-392061.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/392061.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/392061.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Updated: (DERBY-1184) 'CallableStatement.registerOutParameter(int,int,String)' does nothing in client driver
[ http://issues.apache.org/jira/browse/DERBY-1184?page=all ] Bryan Pendleton updated DERBY-1184: --- Attachment: derby_1184_with_test.diff Here's my proposal for a regression test. Attached file 'derby_1184_with_test.diff' is an updated patch file which includes Kristian's original change to CallableStatement.java and also includes a change to derbynet/callable.java to add a simple regression test. > 'CallableStatement.registerOutParameter(int,int,String)' does nothing in > client driver > -- > > Key: DERBY-1184 > URL: http://issues.apache.org/jira/browse/DERBY-1184 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.2.0.0 > Environment: Derby network client > Reporter: Kristian Waagan > Assignee: Bryan Pendleton > Priority: Minor > Attachments: derby-1184-1a.diff, derby-1184-1a.stat, > derby_1184_with_test.diff > > The method 'CallableStatement.registerOutParameter(int,int,String)' does > nothing in the client driver. As stated in DERBY-447, the method throws a > not-implemented exception in the embedded driver. The method should be > changed to do this on the client side as well. -- 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-514) Integrate upgrade tests into test suite
[ http://issues.apache.org/jira/browse/DERBY-514?page=all ] Deepa Remesh updated DERBY-514: --- Attachment: derby-514-patch3-v1.diff derby-514-patch3-v1.status Kathey, Thanks for committing the previous patches. I have noted your concern about error reporting but not yet made that change in this next patch. 'derby-514-patch3-v1.diff' patch changes the build script to use a property which points to the location of old jars. With this change, it should be possible to run the upgrade test using RunTest without any additional command-line flags. It requires a property to be set in ant.properties which will be used at build time. Summary: * Changes the build to use a property derbyTesting.jar.path and use it's value for the location of the jar files from previous release. This property has to be set in ant.propeties and is optional. It is required to run the upgrade tests. * Updates building.txt with the information about new property * During build, the new property will be read and used to set the property in the test properties file. Currently, it sets a property in Upgrade_10_1_10_2_app.properties. This needs to be generalized as more upgrade combinations will be tested. But I am having trouble doing it in a separate property file as it does not get loaded by harness. I will continue to look into this. * Changes UpgradeTester to use the new property. UpgradeTester finds out the location of old and new jars and hence these need not be passed into the class. I ran the upgrade test with and without setting "derbyTesting.jar.path" property and it works as expected. I have not yet tried with Andrew's changes for derby-1049. Please take a look at this patch. Thanks. > Integrate upgrade tests into test suite > --- > > Key: DERBY-514 > URL: http://issues.apache.org/jira/browse/DERBY-514 > Project: Derby > Type: Test > Components: Test > Versions: 10.1.2.0, 10.2.0.0 > Reporter: Kathey Marsden > Assignee: Deepa Remesh > Fix For: 10.2.0.0 > Attachments: derby-514-buildfiles-v1.diff, derby-514-buildfiles-v1.status, > derby-514-patch1-v1.diff, derby-514-patch1-v1.status, > derby-514-patch2-runtest-v1.diff, derby-514-patch2-runtest-v1.status, > derby-514-patch3-v1.diff, derby-514-patch3-v1.status > > Currently there are no upgrade tests in the derbyAll suite. > The upgrade tests java/testing/org/apache/derbyTesting are run by script and > require that the version to be tested by specified on the command line so > that the classpath can be changed. > # runphases old_major old_minor old_engine new_engine > # > # e.g. > # > # runphases 10 0 c:/derby/10.0.2.1/lib c:/derby/trunk/jars/sane > Perhaps this script can be rewritten in Java using class loaders and > previous Derby verssions such as 10.0 and 10.1 be checked in so that this > testing can be incorporated into the derbyAll test suite. -- 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-775) Network client: Add support for scrollable, updatable, insensitive result sets
[ http://issues.apache.org/jira/browse/DERBY-775?page=all ] Dag H. Wanvik updated DERBY-775: Attachment: derby-775-3.stat derby-775-3.diff Here are answers to Øysteins comments and questions. A new version of the patch (#3) reflecting those answers has been uploaded. In this version, some too long lines added or changed have also been normalized (<= 80 chars wide). I also fixed added or changed lines to comply with surrounding whitespace styles (tab or not). I ran derbyall using Solaris 10/x86 Sun JRE 1.4.2 with no untoward results. > "Øystein" == Øystein Grøvlen (JIRA) wrote: Øystein> 1. metadata_net.properties: Øystein> Øystein> - Is the format and constant values used here documented anywhere? As part of DERBY-965, I added some comments explaining the syntax of the fields I touched, please see the file from line 197 onwards. I am not aware of any other documentation. Øystein> 2. DRDAConnThread Øystein> Øystein> - parseSQLATTR(): Variable insensitive can be removed entirely. It Øystein> serves no purpose anymore. Agreed, removed. Øystein> Øystein> 3. NetResultSet/NetResultSet40 Øystein> Øystein> - Parameters of constructor has comments with possible values. This Øystein> needs to be updated to include QRYSNSSTC. Agreed, done. Øystein> 4. NetCursor Øystein> Øystein> - The writeup says the purpose is to pop warnings, but the code seems Øystein> to only handle a single warning. Currently, chained warnings are not being sent over DRDA. I know Fernanda is working on a patch for that. Eventually is will be a "pop", right now maximum one warning is being transmitted. Øystein> - Why do you have to delay the call to setIsUpdataDeleteHole until Øystein> later and not do it when testing for warnings? The existing code checked for update/delete holes by relying only nulldata, which is parsed later than the warning. For SUR, in addition to nulldata, we send a warning (SQLState.ROW_DELETED) since this is required by DRDA, cf the write-up section on this. The existing code is probably non-compliant. Rather than calling setIsUpdataDeleteHole() in two places, we chose to use the existing code location for calling it, using the helper variable receivedDeleteHoleWarning in the SUR case. I agree the code could be simplified by removing the old logic (relying only on nulldata), but we chose the conservative approach. Øystein> Øystein> 5. NetStatementReply Øystein> Øystein> - Call to ClientJDBCObjectFactory.newNetResultSet() lists possible Øystein> values. This needs to be updated to include QRYSNSSTC. Agreed, done. Øystein> Øystein> 6. Statement Øystein> Øystein> - Why have you made warnings_ protected? It seems like it is package Øystein> private that is needed. Why not keep it private and supply a Øystein> get-method? Agreed, done. The old code is too not good on encapsulation, so it leads one astray ;-) Introduced a protected method Statement#getWarnings_, an accessor for warnings_, which is now private. Øystein> Øystein> 7. ResultSet Øystein> Øystein> - Why have you made suggestedFetchSize_ public? It seems like it Øystein> could be protected. Yes. I made it protected. Øystein> Øystein> - Comments for fetchSize_ and suggestedFetchSize_ are a bit brief. Expanded those comments, included here for your convenience: // Gets its initial value from the statement when the result set is created. // It can be modified by setFetchSize and retrieved via getFetchSize. protected int suggestedFetchSize_; // Set by the net layer based on suggestedFetchSize_, protocol // type, scrollability and presence of lobs. public int fetchSize_; Øystein> (And if they are to be public, you should supply javadoc). Øystein> Øystein> - relativex(): Why do not the isBeforeFirstX()/isAfterLastX() test for Øystein> all result sets? For SUR, the check is performed by the getAbsoluteRowset. Øystein> - relativex(): It seems like the code to call getAbsoluteResultSet is Øystein> duplicated. I do not think the second call will ever be executed. Yes, you are right. Vestige from a re-write. I removed this. Øystein> Øystein> - rowUpdated(): Why not always call getIsRowUpdated? I would Øystein> think it was valid for all result sets. This method used to return false for all result sets, since detectability was not implemented in Derby (for any result set). This patch implements it for SUR, so getIsRowUpdated is only called for SUR. I changed this as you suggest, making sure it will return false in non-SUR cases. Øystein> Øystein> - rowUpdated()/rowDeleted(): Thss methods are a bit asymmetric. Øystein> rowUpdated() calls a get-method while rowDeleted accesses Øystein> isUpdateDeleteHole_ directly. The old code had the isUpdateDeleteHole as "public" and I tried to make patch as small as possible, but I agree it's asymmetric. I changed the access into using a getter method. Øystein> - updat
[jira] Commented: (DERBY-658) test harness improvements required for running on non-ASCII systems
[ http://issues.apache.org/jira/browse/DERBY-658?page=comments#action_12373558 ] Myrna van Lunteren commented on DERBY-658: -- Note that with DERBY-683, now derbyTesting.encoding can be used as a property to run with a different encoding, although there is trouble when running with jvms other than jdk15...(see https://issues.apache.org/jira/browse/DERBY-1027). So, in principle, step 1 is done. > test harness improvements required for running on non-ASCII systems > --- > > Key: DERBY-658 > URL: http://issues.apache.org/jira/browse/DERBY-658 > Project: Derby > Type: Bug > Components: Test > Versions: 10.1.1.0 > Environment: all but especially testing should be done on zOS > Reporter: Myrna van Lunteren > Assignee: Myrna van Lunteren > Priority: Minor > Fix For: 10.2.0.0 > > The current functionTests test harness needs adjustment for running on > non-ASCII systems like zOS. > Currently, when using derbyTesting.jar built for instance on a windows or > linux system on zOS the tests do not run, because the properties and runall > files cannot be understood. > Until now, testers on zOS had to unjar derbyTesting.jar, then run > native2ascii -Cp 1047 -reverse on all appropriate files (.sql, .txt, .out, > .properties, .runall, .asc, .exclude, etc). > This is a labor intensive and error prone process. Furthermore, it causes > test failures such as reported with DERBY-575, because tests may assume a > certain file to be a specific length, which no longer holds true after the > native2ascii conversion. > The test harness should get modified to always read the files in the same > encoding. > Note however, that the comparison of actual .out and the master should still > result in files readable on the local system, to enable a human to evaluate > failures and results. At the same time, this raises the concern that someone > might check-in an update to the master with an incorrect encoding. > To resolve the main issue, I propose the following: > - Set the default encoding in the harness. > - for each test > 1) determine if the test encoding is set. We can probably use ij.ui.codeset > - otherwise a new property is needed. > Note that this means that .properties, .runall and .exclude files are > always read in fixed/default encoding. > 2) read the master/sql files in in the default/fixed encoding unless the > encoding property is set for a test > 3) Write the output out in the local encoding (the way is done currently) > unless the encoding property is set (if set, write out in that encoding) > 4) Change the code that creates tmpmstr to always apply instead of only for > networkserver. tmpmstr files will be created in the local encoding. > 5) Have FileCompare read tmpmstr in in the local encoding for the comparison. > 6) either document that test development/adjustment need to be at least be > verified on an ascii system, or add another property that causes a copy of > the actual output to be created in the default/fixed encoding. -- 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-1189) latch self deadlock when running inplace compress
[ http://issues.apache.org/jira/browse/DERBY-1189?page=all ]
Mike Matrigali updated DERBY-1189:
--
It is likely this is the same problem as DERBY-1118, but I have reported as a
separate issue as I did not reproduce the
Cache errors reported in that issue. Once this fix is made to the trunk I
hope that the DERBY-1118 reporter can rerun
their tests to see if it is also fixed.
> latch self deadlock when running inplace compress
> -
>
> Key: DERBY-1189
> URL: http://issues.apache.org/jira/browse/DERBY-1189
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2,
> 10.1.2.3, 10.2.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Fix For: 10.2.0.0
>
> The following script , before the fix, causes online compress to attempt to
> latch the same page twice in a nested user transaction causing a self
> deadlock of the form:
> ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> ERROR 40001: A lock could not be obtained due to a deadlock, cycle of locks
> and
> waiters is:
> Lock : LATCH, T1, Page(35,Container(0, 1728))
> Waiting XID : {385920, BaseContainerHandle:(Container(0, 1728))} , APP,
> CALL S
> YSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1)
> Granted XID : {385920, BaseContainerHandle:(Container(0, 1728))}
> . The selected victim is XID : 385920.
> script that reproduces it:
> drop table t1;
> create table t1 (i integer primary key, j integer, c char(200));
> insert into t1 values (1, 1, 'a');
> insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
> insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
> insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
> insert into t1 (select t1.i + 16, t1.j + 16, t1.c from t1);
> insert into t1 (select t1.i + 32, t1.j + 32, t1.c from t1);
> insert into t1 (select t1.i + 64, t1.j + 64, t1.c from t1);
> insert into t1 (select t1.i + 128, t1.j + 128, t1.c from t1);
> insert into t1 (select t1.i + 256, t1.j + 256, t1.c from t1);
> insert into t1 (select t1.i + 512, t1.j + 512, t1.c from t1);
> insert into t1 (select t1.i + 1024, t1.j + 1024, t1.c from t1);
> delete from t1 where j=1;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> delete from t1 where j=2;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> delete from t1 where i > 1024;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> delete from t1 where i < 512;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 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] Created: (DERBY-1189) latch self deadlock when running inplace compress
latch self deadlock when running inplace compress
-
Key: DERBY-1189
URL: http://issues.apache.org/jira/browse/DERBY-1189
Project: Derby
Type: Bug
Components: Store
Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2,
10.1.2.3, 10.2.0.0
Reporter: Mike Matrigali
Assigned to: Mike Matrigali
Fix For: 10.2.0.0
The following script , before the fix, causes online compress to attempt to
latch the same page twice in a nested user transaction causing a self deadlock
of the form:
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
ERROR 40001: A lock could not be obtained due to a deadlock, cycle of locks and
waiters is:
Lock : LATCH, T1, Page(35,Container(0, 1728))
Waiting XID : {385920, BaseContainerHandle:(Container(0, 1728))} , APP, CALL S
YSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1)
Granted XID : {385920, BaseContainerHandle:(Container(0, 1728))}
. The selected victim is XID : 385920.
script that reproduces it:
drop table t1;
create table t1 (i integer primary key, j integer, c char(200));
insert into t1 values (1, 1, 'a');
insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
insert into t1 (select t1.i + 16, t1.j + 16, t1.c from t1);
insert into t1 (select t1.i + 32, t1.j + 32, t1.c from t1);
insert into t1 (select t1.i + 64, t1.j + 64, t1.c from t1);
insert into t1 (select t1.i + 128, t1.j + 128, t1.c from t1);
insert into t1 (select t1.i + 256, t1.j + 256, t1.c from t1);
insert into t1 (select t1.i + 512, t1.j + 512, t1.c from t1);
insert into t1 (select t1.i + 1024, t1.j + 1024, t1.c from t1);
delete from t1 where j=1;
CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
delete from t1 where j=2;
CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
delete from t1 where i > 1024;
CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
delete from t1 where i < 512;
CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 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
Re: Preparing for potential Google Summer of Code
For your background information and to give you some ideas, here is the link to last year's summer of code http://code.google.com/summerofcode.html David W. Van Couvering wrote: Hi, all. It is possible that Google will want to do another Summer of Code this year. Google pays students to join open source communities as interns for the summer. While Google uses this as an opportunity to identify the best and brightest up-and-coming coders, it is also a useful opportunity for open source projects to get issues addressed, new avenues explored and bugs fixed - and potentially to recruit new community members and gain a raised public profile. It would be great if Apache Derby could participate in this. To do this we need to be ready with an answer to the question "what would one or more students do if they joined Derby for three months?" It's important to be prepared. With the Summer of Code site opens up, we need to register our community, identify a contact point for the project and mentors for the students and a list of potential projects. Last summer there were only about 48 hours to respond from the announcement before the program was fully subscribed. What I'd like to suggest is the following: - Who would like to be the contact point? I am thinking Jean Anderson, as our community liason extraordinaire. - Put together a Wiki page with potential projects and mentors for each project. It would be great to have this regardless, as a way to encourage participation. If this sounds good, I can start the Wiki page, and then anyone who has an idea for a project and/or is willing to mentor can update that page. David
[jira] Updated: (DERBY-1173) conglomerate (129) requested does not exist error on create table after aborting and rerunning jdbcapi/checkDataSource test with client.
[ http://issues.apache.org/jira/browse/DERBY-1173?page=all ]
Mike Matrigali updated DERBY-1173:
--
If anyone gets a chance to look at the stack trace error above here is the info
I think would be interesting:
1) what is the stack traces of the server threads when the "timeout/deadlock"
happens. I believe this is a single user, but
multi-connection test.
2) are connections getting cleaned up on the server side after the control c
of the client. Note there are likely multiple
connections in the client some of which are guaranteed not to have been
active when the client went away.
3) what is container 129 in this db. In a freshly created db it is the
SYSTABLES_INDEX2 table. So it not existing is a
serious issue. This has the feel of some lock/latch issue which has not
been cleaned up and then prevents subsequent
access to the system.
4) what does a lock table query return after reconnecting to the server? The
repro is kill the client, leave the server. Then
reconnect to the existing server.
> conglomerate (129) requested does not exist error on create table after
> aborting and rerunning jdbcapi/checkDataSource test with client.
> ---
>
> Key: DERBY-1173
> URL: http://issues.apache.org/jira/browse/DERBY-1173
> Project: Derby
> Type: Bug
> Components: Network Client, Store
> Versions: 10.0.2.1
> Reporter: Kathey Marsden
> Priority: Critical
> Fix For: 10.2.0.0
>
> I had been working on the checkDataSource test a few weeks ago, to get it
> working with client but did not bring it into a suite at that time
> unfortunately.
> jdbcapi/checkDataSource.java now hangs with client. If I abort the test with
> c and rerun it fails on create table with:
> Booting Derby version The Apache Software Foundation - Apache Derby -
> 10.2.0.0 alpha - (1): instance c013800d-010a-51bb-ae54-048a8d0f
> on database directory D:\testout4\DerbyNetClient\checkDataSource\wombat
> Database Class Loader started - derby.database.classpath=''
> Could not listen on port 1527 on host localhost.
> 2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200),
> (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
> NF01.G90E-1097469790362120575{12}), Cleanup action starting
> 2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200),
> (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
> NF01.G90E-1097469790362120575{12}), Failed Statement is: create table y(i
> int)
> ERROR XSAI2: The conglomerate (129) requested does not exist.
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java:311)
> at
> org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(B2IFactory.java:241)
> at
> org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.java:484)
> at
> org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction.java:389)
> at
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1315)
> at
> org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRowListImpl(TabInfoImpl.java:525)
> at
> org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRow(TabInfoImpl.java:419)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptorNow(DataDictionaryImpl.java:1637)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(DataDictionaryImpl.java:1624)
> at
> org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(CreateTableConstantAction.java:223)
> at
> org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1160)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:158)
> at
> org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:4395)
> at
> org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:645)
> at
> org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:236)
> Cleanup action completed
> Apache Derby Network Server - 10.2.0.0 alpha shutdown at 2006-03-31
> 19:18:48.601 GMT
> There is some relevant revison history:
> At r 380672 I made some changes to the test and the test passed with client
> At r 387611 I made some comment changes and accidently enabled one of the
> failing client cases.
> At r 390481 I disabled the test for DERBY-10
[jira] Resolved: (DERBY-1049) make existing derby release jars available for upgrade testing and client/server compatibility testing with derbyall
[ http://issues.apache.org/jira/browse/DERBY-1049?page=all ] Andrew McIntyre resolved DERBY-1049: Fix Version: 10.2.0.0 Resolution: Fixed Assign To: Andrew McIntyre Added jars to repository with revision 392111. To fetch the jars into your current subversion view in tools/testing/derby/10.1.1.0, do the following from the top of the tree: svn propedit svn:externals tools/testing this will bring up an empty document in your editor. Then add this line and save the document: derby/10.1.1.0 https://svn.apache.org/repos/asf/db/derby/jars/10.1.1.0 The next time you perform a sync, the jars will be fetched from the repository into the proper directory. When the upgrade tests are in place and working, we should commit the setting of this property to the repository so that all subversion clients fetch the jars needed by the upgrade tests. > make existing derby release jars available for upgrade testing and > client/server compatibility testing with derbyall > > > Key: DERBY-1049 > URL: http://issues.apache.org/jira/browse/DERBY-1049 > Project: Derby > Type: Task > Components: Build tools > Reporter: Kathey Marsden > Assignee: Andrew McIntyre > Fix For: 10.2.0.0 > > DERBY-514 : integrate upgrade testing into derbyall > DERBY-1048 : Include run of jdbcapi/Compatibility test with first client > release in derbyall > compatibility testing with derbyall, both require that the previous derby > releases be available in svn workspaces, either by checking in the jars or by > some other method. > We need at least: > 10.1.1.0 - First client release (for DERBY-1048) > I am not sure abou these: > 10.0.2.1 - First derby release (incubator) > 10.1.2.1 - 10.1 Maintenance release -- 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-1188) enhance derby inplace compress defragment phase to hold locks for less time.
enhance derby inplace compress defragment phase to hold locks for less time. Key: DERBY-1188 URL: http://issues.apache.org/jira/browse/DERBY-1188 Project: Derby Type: Improvement Components: Store Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2, 10.1.2.3, 10.2.0.0 Reporter: Mike Matrigali Priority: Minor Currently the truncate defragment pass holds locks until it commits. It would be better if it committed more often. To do this the loop must be enhanced to pick up ddl level state change when the commits happen and release locks. It may be that work being done in 10.2 for scrollable updatable result sets across commits in open cursors will help with this. -- 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-1187) defragment of inplace compress pass for described dataset is not freeing up empty pages.
[ http://issues.apache.org/jira/browse/DERBY-1187?page=all ]
Mike Matrigali updated DERBY-1187:
--
Description:
For the following script defragment pass is not freeing up the free pages:
drop table t1;
create table t1 (i integer primary key, j integer, c char(200));
insert into t1 values (1, 1, 'a');
insert into t1 (select t1.i + 1,t1.j + 1,t1.c from t1);
insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
insert into t1 (select t1.i + 16, t1.j + 16, t1.c from t1);
insert into t1 (select t1.i + 32, t1.j + 32, t1.c from t1);
insert into t1 (select t1.i + 64, t1.j + 64, t1.c from t1);
insert into t1 (select t1.i + 128, t1.j + 128, t1.c from t1);
insert into t1 (select t1.i + 256, t1.j + 256, t1.c from t1);
insert into t1 (select t1.i + 512, t1.j + 512, t1.c from t1);
delete from t1 where i < 512;
select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
Here is example output from a run on the trunk:
ij> drop table t1;
0 rows inserted/updated/deleted
ij> create table t1 (i integer primary key, j integer, c char(200));
0 rows inserted/updated/deleted
ij> insert into t1 values (1, 1, 'a');
1 row inserted/updated/deleted
ij> insert into t1 (select t1.i + 1,t1.j + 1,t1.c from t1);
1 row inserted/updated/deleted
ij> insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
2 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
4 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
8 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 16, t1.j + 16, t1.c from t1);
16 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 32, t1.j + 32, t1.c from t1);
32 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 64, t1.j + 64, t1.c from t1);
64 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 128, t1.j + 128, t1.c from t1);
128 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 256, t1.j + 256, t1.c from t1);
256 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 512, t1.j + 512, t1.c from t1);
512 rows inserted/updated/deleted
ij> delete from t1 where i < 512;
511 rows inserted/updated/deleted
ij> select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
TABNAME |ISIND&|ALLOC |NUMFREEPAGES|UNFILLED |PAGESIZE |EST
IMSPACESAVING
-
SQL060406034|1 |7 |0 |0 |4096 |0
T1 |0 |60 |9 |0 |4096 |368
64
2 rows selected
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
TABNAME |ISIND&|ALLOC |NUMFREEPAGES|UNFILLED |PAGESIZE |EST
IMSPACESAVING
-
SQL060406034|1 |7 |0 |1 |4096 |0
T1 |0 |69 |0 |0 |4096 |0
2 rows selected
ij>
was:
For the following script defragement pass is not freeing up the free pages:
drop table t1;
create table t1 (i integer primary key, j integer, c char(200));
insert into t1 values (1, 1, 'a');
insert into t1 (select t1.i + 1
[jira] Assigned: (DERBY-1187) defragment of inplace compress pass for described dataset is not freeing up empty pages.
[ http://issues.apache.org/jira/browse/DERBY-1187?page=all ]
Mike Matrigali reassigned DERBY-1187:
-
Assign To: Mike Matrigali
> defragment of inplace compress pass for described dataset is not freeing up
> empty pages.
>
>
> Key: DERBY-1187
> URL: http://issues.apache.org/jira/browse/DERBY-1187
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2,
> 10.1.2.3, 10.2.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Priority: Minor
> Fix For: 10.2.0.0
>
> For the following script defragement pass is not freeing up the free pages:
> drop table t1;
> create table t1 (i integer primary key, j integer, c char(200));
> insert into t1 values (1, 1, 'a');
> insert into t1 (select t1.i + 1,t1.j + 1,t1.c from t1);
> insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
> insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
> insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
> insert into t1 (select t1.i + 16, t1.j + 16, t1.c from t1);
> insert into t1 (select t1.i + 32, t1.j + 32, t1.c from t1);
> insert into t1 (select t1.i + 64, t1.j + 64, t1.c from t1);
> insert into t1 (select t1.i + 128, t1.j + 128, t1.c from t1);
> insert into t1 (select t1.i + 256, t1.j + 256, t1.c from t1);
> insert into t1 (select t1.i + 512, t1.j + 512, t1.c from t1);
> delete from t1 where i < 512;
> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages as int) as unfilled,
> pagesize,
> estimspacesaving
> from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages as int) as unfilled,
> pagesize,
> estimspacesaving
> from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages as int) as unfilled,
> pagesize,
> estimspacesaving
> from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
> Here is example output from a run on the trunk:
> ij> drop table t1;
> 0 rows inserted/updated/deleted
> ij> create table t1 (i integer primary key, j integer, c char(200));
> 0 rows inserted/updated/deleted
> ij> insert into t1 values (1, 1, 'a');
> 1 row inserted/updated/deleted
> ij> insert into t1 (select t1.i + 1,t1.j + 1,t1.c from t1);
> 1 row inserted/updated/deleted
> ij> insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
> 2 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
> 4 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
> 8 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 16, t1.j + 16, t1.c from t1);
> 16 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 32, t1.j + 32, t1.c from t1);
> 32 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 64, t1.j + 64, t1.c from t1);
> 64 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 128, t1.j + 128, t1.c from t1);
> 128 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 256, t1.j + 256, t1.c from t1);
> 256 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 512, t1.j + 512, t1.c from t1);
> 512 rows inserted/updated/deleted
> ij> delete from t1 where i < 512;
> 511 rows inserted/updated/deleted
> ij> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages as int) as unfilled,
> pagesize,
> estimspacesaving
> from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
> TABNAME |ISIND&|ALLOC |NUMFREEPAGES|UNFILLED |PAGESIZE
> |EST
> IMSPACESAVING
>
> -
> SQL060406034|1 |7 |0 |0 |4096 |0
> T1 |0 |60 |9 |0 |4096
> |368
> 64
> 2 rows selected
> ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> 0 rows inserted/updated/deleted
> ij> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages a
[jira] Created: (DERBY-1187) defragment of inplace compress pass for described dataset is not freeing up empty pages.
defragment of inplace compress pass for described dataset is not freeing up
empty pages.
Key: DERBY-1187
URL: http://issues.apache.org/jira/browse/DERBY-1187
Project: Derby
Type: Bug
Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2,
10.1.2.3, 10.2.0.0
Reporter: Mike Matrigali
Priority: Minor
Fix For: 10.2.0.0
For the following script defragement pass is not freeing up the free pages:
drop table t1;
create table t1 (i integer primary key, j integer, c char(200));
insert into t1 values (1, 1, 'a');
insert into t1 (select t1.i + 1,t1.j + 1,t1.c from t1);
insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
insert into t1 (select t1.i + 16, t1.j + 16, t1.c from t1);
insert into t1 (select t1.i + 32, t1.j + 32, t1.c from t1);
insert into t1 (select t1.i + 64, t1.j + 64, t1.c from t1);
insert into t1 (select t1.i + 128, t1.j + 128, t1.c from t1);
insert into t1 (select t1.i + 256, t1.j + 256, t1.c from t1);
insert into t1 (select t1.i + 512, t1.j + 512, t1.c from t1);
delete from t1 where i < 512;
select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
Here is example output from a run on the trunk:
ij> drop table t1;
0 rows inserted/updated/deleted
ij> create table t1 (i integer primary key, j integer, c char(200));
0 rows inserted/updated/deleted
ij> insert into t1 values (1, 1, 'a');
1 row inserted/updated/deleted
ij> insert into t1 (select t1.i + 1,t1.j + 1,t1.c from t1);
1 row inserted/updated/deleted
ij> insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
2 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
4 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
8 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 16, t1.j + 16, t1.c from t1);
16 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 32, t1.j + 32, t1.c from t1);
32 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 64, t1.j + 64, t1.c from t1);
64 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 128, t1.j + 128, t1.c from t1);
128 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 256, t1.j + 256, t1.c from t1);
256 rows inserted/updated/deleted
ij> insert into t1 (select t1.i + 512, t1.j + 512, t1.c from t1);
512 rows inserted/updated/deleted
ij> delete from t1 where i < 512;
511 rows inserted/updated/deleted
ij> select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
TABNAME |ISIND&|ALLOC |NUMFREEPAGES|UNFILLED |PAGESIZE |EST
IMSPACESAVING
-
SQL060406034|1 |7 |0 |0 |4096 |0
T1 |0 |60 |9 |0 |4096 |368
64
2 rows selected
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> select
cast(conglomeratename as char(12)) as tabname,
isindex,
cast(numallocatedpages as int) as alloc,
numfreepages,
cast(numunfilledpages as int) as unfilled,
pagesize,
estimspacesaving
from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
TABNAME |ISIND&|ALLOC |NUMFREEPAGES|UNFILLED |PAGESIZE |EST
IMSPACESAVING
-
SQL060406034|1 |7 |0 |1 |4096 |0
T1
Re: Upgrade Testing - more tests needed for 10.2 ?
Thanks for this important effort, Deepa. Is there a document for developers somewhere that explains the kinds of changes that impact upgrade, and how you go about writing a test an upgrade-impacting change? I'm a bit mystified myself right now... (although I'm pretty darn sure i18n changes in the client don't impact upgrade :) ). David Deepa Remesh wrote: Hi, I have been working on making the upgrade tests run as part of derbyall and noticed that there is only one test (caseReusableRecordIdSequenceNumber) which has been specifically added for 10.2. The javadoc comment for UpgradeTester class lists what is tested for 10.1. I think we need a similar list for 10.2 and maybe, more tests for any new features. Andrew mentioned he is working on getting the jars in the repository and I am working on using these repository jars and defining a standard way to run the test so that it can run as part of derbyall. I plan to document this in readme/building.txt once everything is in place. For now, to run upgrade tests, we need to pass in the location of previous version jar (10.1.2.1) as follows: java -Djvmflags=-DderbyTesting.oldJarLocation= org.apache.derbyTesting.functionTests.harness.RunTest upgradeTests/Upgrade_10_1_10_2.java NOTE: Test runs with jar files in the classpath. It does not run with classes folder. Please feel free to add more 10.2 tests to UpgradeTester while rest of the testing infrastructure is being set up. Thanks, Deepa
Re: Does in-place compress really defragment?
Oystein Grovlen - Sun Norway wrote:
OK, here is a replay of just step 7 and 8 including queries of the space
table vti:
ij> create table t1 (i integer primary key, j integer, c varchar(300));
0 rows inserted/updated/deleted
ij> insert into t1 select * from t;
1536 rows inserted/updated/deleted
ij> select conglomeratename, isindex, numallocatedpages, numfreepages,
pagesize, estimspacesaving from new
org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
CONGLOMERATENAME
|ISIND&|NUMALLOCATEDPAGES |NUMFREEPAGES|PAGESIZE
|ESTIMSPACESAVING
--
SQL060404033237400
|1 |10
|0 |4096 |0
T1 |0 |103
|0 |4096 |0
2 rows selected
ij> delete from t1 where i < 512;
512 rows inserted/updated/deleted
ij> select conglomeratename, isindex, numallocatedpages, numfreepages,
pagesize, estimspacesaving from new
org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
CONGLOMERATENAME
|ISIND&|NUMALLOCATEDPAGES |NUMFREEPAGES|PAGESIZE
|ESTIMSPACESAVING
--
SQL060404033237400
|1 |8
|2 |4096 |8192
T1 |0 |70
|33 |4096 |135168
2 rows selected
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> select conglomeratename, isindex, numallocatedpages, numfreepages,
pagesize, estimspacesaving from new
org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
CONGLOMERATENAME
|ISIND&|NUMALLOCATEDPAGES |NUMFREEPAGES|PAGESIZE
|ESTIMSPACESAVING
--
SQL060404033237400
|1 |8
|2 |4096 |8192
T1 |0 |103
|0 |4096 |0
2 rows selected
Looks like compress reuses the empty pages without freeing other pages.
This looks like a bug, I will report and am actively looking at it.
Upgrade Testing - more tests needed for 10.2 ?
Hi, I have been working on making the upgrade tests run as part of derbyall and noticed that there is only one test (caseReusableRecordIdSequenceNumber) which has been specifically added for 10.2. The javadoc comment for UpgradeTester class lists what is tested for 10.1. I think we need a similar list for 10.2 and maybe, more tests for any new features. Andrew mentioned he is working on getting the jars in the repository and I am working on using these repository jars and defining a standard way to run the test so that it can run as part of derbyall. I plan to document this in readme/building.txt once everything is in place. For now, to run upgrade tests, we need to pass in the location of previous version jar (10.1.2.1) as follows: java -Djvmflags=-DderbyTesting.oldJarLocation= org.apache.derbyTesting.functionTests.harness.RunTest upgradeTests/Upgrade_10_1_10_2.java NOTE: Test runs with jar files in the classpath. It does not run with classes folder. Please feel free to add more 10.2 tests to UpgradeTester while rest of the testing infrastructure is being set up. Thanks, Deepa
Re: How to start and stop Derby from within a test
Olav Sandstaa wrote: Rick Hillegas <[EMAIL PROTECTED]> wrote: java.sql.SQLException: Java exception: 'access denied (java.io.FilePermission /export/home/tmp/derbyjdbc4/DerbyNetClient/TestConnectionMethods/wombat/log/logmirror.ctrl read): java.security.AccessControlException'. at java.security.AccessControlContext.checkPermission(AccessControlContext.java:321) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:731) at org.apache.derby.impl.store.raw.log.LogToFile.boot(LogToFile.java:2940) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(BaseDataFileFactory.java:1762) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(BaseDataFileFactory.java:1218) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:250) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:987) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:542) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:738) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:178) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1831) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1697) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1577) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1586) at org.apache.derby.impl.jdbc.EmbedConnection.(EmbedConnection.java:216) at org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:72) at org.apache.derby.impl.jdbc.EmbedConnection40.(EmbedConnection40.java:48) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:62) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:199) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:231) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1147) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1125) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:2709) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:987) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:830) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:236) The security exception is raised when Derby tries to get access to the log/logmirror.ctrl file during the second startup of the database. I would have expected that since this file was created earlier during the initial startup of the test, the test should already have the required security permissions to access it during the second startup? Anyway, the best solution to this problem would be to be able to reuse functionality that already might exist in the test framework. Any suggestions are appreciated. Regards, Olav By looking at the stack it looks like log/logmirror.ctrl is not getting accessed in the privileged block at line 2940 in LogToFile.java. if
Re: Preparing for potential Google Summer of Code
Thanks David. Susan --- "David W. Van Couvering" <[EMAIL PROTECTED]> wrote: > You're right Susan, thanks. I'd be happy to volunteer for this role. > > David > > Susan Cline wrote: > > --- "David W. Van Couvering" <[EMAIL PROTECTED]> wrote: > > > > > >>Hi, all. It is possible that Google will want to do another Summer of > >>Code this year. Google pays students to join open source communities as > >>interns for the summer. While Google uses this as an opportunity to > >>identify the best and brightest up-and-coming coders, it is also a > >>useful opportunity for open source projects to get issues addressed, new > >>avenues explored and bugs fixed - and potentially to recruit new > >>community members and gain a raised public profile. > >> > >>It would be great if Apache Derby could participate in this. > > > > > > I think this is a great idea, and I hope we participate in it. > > > > [ snip ] > > > > > >>What I'd like to suggest is the following: > >> > >>- Who would like to be the contact point? I am thinking Jean Anderson, > >>as our community liason extraordinaire. > > > > > > Instead of suggesting who might be appropriate for this, how about if we > > ask for a volunteer, instead? Jean may be willing to take this on, but > > I think in the spirit of "scratching your own itch" it's feels better > > to volunteer for a task without feeling like it may have been assigned to > > you. > > > > Susan >
Re: Preparing for potential Google Summer of Code
You're right Susan, thanks. I'd be happy to volunteer for this role. David Susan Cline wrote: --- "David W. Van Couvering" <[EMAIL PROTECTED]> wrote: Hi, all. It is possible that Google will want to do another Summer of Code this year. Google pays students to join open source communities as interns for the summer. While Google uses this as an opportunity to identify the best and brightest up-and-coming coders, it is also a useful opportunity for open source projects to get issues addressed, new avenues explored and bugs fixed - and potentially to recruit new community members and gain a raised public profile. It would be great if Apache Derby could participate in this. I think this is a great idea, and I hope we participate in it. [ snip ] What I'd like to suggest is the following: - Who would like to be the contact point? I am thinking Jean Anderson, as our community liason extraordinaire. Instead of suggesting who might be appropriate for this, how about if we ask for a volunteer, instead? Jean may be willing to take this on, but I think in the spirit of "scratching your own itch" it's feels better to volunteer for a task without feeling like it may have been assigned to you. Susan
[jira] Created: (DERBY-1186) Add a test to i18n that verifies that there are no duplicate message ids in messages.properties
Add a test to i18n that verifies that there are no duplicate message ids in messages.properties --- Key: DERBY-1186 URL: http://issues.apache.org/jira/browse/DERBY-1186 Project: Derby Type: Sub-task Reporter: David Van Couvering Priority: Minor Ensure that the same message id is not being used for two different messages. Also it would be worthwhile to write a test that reports any instances where SQLState.java has two constants with the same message id. This may not be a bug, but it is worth catching and calling out just in case. -- 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: Preparing for potential Google Summer of Code
--- "David W. Van Couvering" <[EMAIL PROTECTED]> wrote: > Hi, all. It is possible that Google will want to do another Summer of > Code this year. Google pays students to join open source communities as > interns for the summer. While Google uses this as an opportunity to > identify the best and brightest up-and-coming coders, it is also a > useful opportunity for open source projects to get issues addressed, new > avenues explored and bugs fixed - and potentially to recruit new > community members and gain a raised public profile. > > It would be great if Apache Derby could participate in this. I think this is a great idea, and I hope we participate in it. [ snip ] > What I'd like to suggest is the following: > > - Who would like to be the contact point? I am thinking Jean Anderson, > as our community liason extraordinaire. Instead of suggesting who might be appropriate for this, how about if we ask for a volunteer, instead? Jean may be willing to take this on, but I think in the spirit of "scratching your own itch" it's feels better to volunteer for a task without feeling like it may have been assigned to you. Susan
[jira] Resolved: (DERBY-1185) Move all client messages to messages.properties
[ http://issues.apache.org/jira/browse/DERBY-1185?page=all ] David Van Couvering resolved DERBY-1185: Resolution: Fixed Committed revision 392060, passes derbyall > Move all client messages to messages.properties > --- > > Key: DERBY-1185 > URL: http://issues.apache.org/jira/browse/DERBY-1185 > Project: Derby > Type: Sub-task > Reporter: David Van Couvering > Assignee: David Van Couvering > Priority: Minor > > Right now messages that are deemed network client specific are placed > manually in clientmessages.properties. This is a JIRA for moving these > messages to messages.properties and using splitmessages.java to copy over the > messages the client needs to clientmessages.properties at build time. The > goal is to reduce the overall complexity of adding messages to the client,and > also to help ensure that messages across client and embedded drivers are > consistent and coherent. -- 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] Assigned: (DERBY-1185) Move all client messages to messages.properties
[ http://issues.apache.org/jira/browse/DERBY-1185?page=all ] David Van Couvering reassigned DERBY-1185: -- Assign To: David Van Couvering > Move all client messages to messages.properties > --- > > Key: DERBY-1185 > URL: http://issues.apache.org/jira/browse/DERBY-1185 > Project: Derby > Type: Sub-task > Reporter: David Van Couvering > Assignee: David Van Couvering > Priority: Minor > > Right now messages that are deemed network client specific are placed > manually in clientmessages.properties. This is a JIRA for moving these > messages to messages.properties and using splitmessages.java to copy over the > messages the client needs to clientmessages.properties at build time. The > goal is to reduce the overall complexity of adding messages to the client,and > also to help ensure that messages across client and embedded drivers are > consistent and coherent. -- 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-1185) Move all client messages to messages.properties
Move all client messages to messages.properties --- Key: DERBY-1185 URL: http://issues.apache.org/jira/browse/DERBY-1185 Project: Derby Type: Sub-task Reporter: David Van Couvering Priority: Minor Right now messages that are deemed network client specific are placed manually in clientmessages.properties. This is a JIRA for moving these messages to messages.properties and using splitmessages.java to copy over the messages the client needs to clientmessages.properties at build time. The goal is to reduce the overall complexity of adding messages to the client,and also to help ensure that messages across client and embedded drivers are consistent and coherent. -- 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-1147) Implement miscellaneous CallableStatement methods added by JDBC4
[ http://issues.apache.org/jira/browse/DERBY-1147?page=all ] Kristian Waagan updated DERBY-1147: --- Attachment: derby-1147-2a-getcharacterstream.stat derby-1147-2a-getcharacterstream.diff 'derby-1147-2a-getcharacterstream.diff' is a *preliminary* patch implementing CallableStatement.getCharacterStream(int). Since I have little knowledge about this part of Derby, I would like to get some feedback from people more familiar with this code. The method is implemented for both client and embedded mode, and I have written some tests. The implementation is based on existing code in other parts of Derby. The supported types are taken from table B-6 of the JDBC4 spec, and seems to be in agreement with existing Derby methods. Some questions and obervations: 1) testGetCharacterStreamIntOnInParameterOfInvalidType fails for embedded (see point 7 below). 2) I have not taken maximum length into consideration (data truncation), as I read the JavaDoc as setMaxField only applies to ResultSet. Correct me if this is wrong. 3) Is the usage of setupContextStack/restoreContextStack correct and necessary? Why? 4) Should the embedded implementation be moved to EmbedCallableStatement20? 5) Have I forgotten some internal variables that must be maintained? 6) Support for Clob and Blob are included, although these types are not allowed (yet) as parameters in CallableStatement in Derby. 7) Due to a bit different designs/implementations, getCharacterStream will throw different exceptions when calling it on an IN parameter of a non-supported type (for instance DOUBLE). On the client side it will correctly state that the parameter is not an OUT/INOUT parameter, while the embedded side complains about a data conversion error. There are at least two ways to fix this: A) duplicate check code from GenericParameterValueSet.getParameterForGet and call it before switch block in getCharacterStream B) call GenericParameterValueSet.getParameterForGet before switch block in getCharacterStream, even for invalid data types Any opinions on the best way to solve this? Have I overlooked some existing functionality I can use? I will keep working on this, and feedback and pieces of advice is appreciated. > Implement miscellaneous CallableStatement methods added by JDBC4 > > > Key: DERBY-1147 > URL: http://issues.apache.org/jira/browse/DERBY-1147 > Project: Derby > Type: Improvement > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Kristian Waagan > Attachments: derby-1147-1a-missing-methods.diff, > derby-1147-1a-missing-methods.stat, derby-1147-2a-getcharacterstream.diff, > derby-1147-2a-getcharacterstream.stat > > These are described in the overview section 3.1 of the JDBC4 spec: > "Added the methods getRowId, setRowId, getNClob, getNString, > getCharacterStream, getNCharacterStream, setNString, > setNCharacterStream, setNClob, getSQLXML, setSQLXML. > Overloaded the setClob and setBlob methods." > Most of these methods will throw SQLFeatureNotSupporteException because our > client drivers do not support the ROWID, National String, and XML datatypes. > However, we should implement the getCharacterStream() method and the > setClob() and setBlob() overloads. -- 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: Preparing for potential Google Summer of Code
David W. Van Couvering wrote: > > - Put together a Wiki page with potential projects and mentors for > each project. It would be great to have this regardless, as a way to > encourage participation. Good idea. I can suggest several projects in the area of 'Optimizer', like large query optimization or multi-index scan for a table (for OR/IN processing or for processing T1.a=5 OR T1.b=6) Optimizer projects are always appealing to students and a good way to test their coding skills :) Other projects I can think of include XQuery integration with Derby or Lucene text search integration. Satheesh > If this sounds good, I can start the Wiki page, and then anyone who > has an idea for a project and/or is willing to mentor can update that > page. > > David > > >
[jira] Closed: (DERBY-1101) ResultSet.getHoldabilty will return incorrect value when the ResultSet is obtained from a procedure call
[ http://issues.apache.org/jira/browse/DERBY-1101?page=all ] Daniel John Debrunner closed DERBY-1101: Closed - Actually I only realised once I was adding the contribution line in the commit message that this was a patch provided by a committer. For some reason I thought it was someone else. Since I'd got so far I thought I might as well continue. :-) > ResultSet.getHoldabilty will return incorrect value when the ResultSet is > obtained from a procedure call > > > Key: DERBY-1101 > URL: http://issues.apache.org/jira/browse/DERBY-1101 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.2.0.0 > Reporter: Daniel John Debrunner > Assignee: Knut Anders Hatlen > Priority: Minor > Fix For: 10.2.0.0 > Attachments: derby-1101-testcase-v1.diff, derby-1101-v1.diff, > derby-1101-v1.stat, testderby1101.java > > EmbedResultSet40.getHoldability returns the holdability of the statement > returned by ResultSet.getStatement(). > When a ResultSet is created by a procedure call, its holdability may not > match the holdability of the Statement that called the procedure, which is > probably what ResultSet.getStatement() should return. > This may not be exposed as a bug yet, but I think this method should be > directly obtaining the holdability of the ResultSet using the > Activation.getResultSetHoldability() method, rather than through a Statement. > Seems a safer approach. -- 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
Preparing for potential Google Summer of Code
Hi, all. It is possible that Google will want to do another Summer of Code this year. Google pays students to join open source communities as interns for the summer. While Google uses this as an opportunity to identify the best and brightest up-and-coming coders, it is also a useful opportunity for open source projects to get issues addressed, new avenues explored and bugs fixed - and potentially to recruit new community members and gain a raised public profile. It would be great if Apache Derby could participate in this. To do this we need to be ready with an answer to the question "what would one or more students do if they joined Derby for three months?" It's important to be prepared. With the Summer of Code site opens up, we need to register our community, identify a contact point for the project and mentors for the students and a list of potential projects. Last summer there were only about 48 hours to respond from the announcement before the program was fully subscribed. What I'd like to suggest is the following: - Who would like to be the contact point? I am thinking Jean Anderson, as our community liason extraordinaire. - Put together a Wiki page with potential projects and mentors for each project. It would be great to have this regardless, as a way to encourage participation. If this sounds good, I can start the Wiki page, and then anyone who has an idea for a project and/or is willing to mentor can update that page. David
[jira] Updated: (DERBY-1173) conglomerate (129) requested does not exist error on create table after aborting and rerunning jdbcapi/checkDataSource test with client.
[ http://issues.apache.org/jira/browse/DERBY-1173?page=all ]
Kathey Marsden updated DERBY-1173:
--
Summary: conglomerate (129) requested does not exist error on create
table after aborting and rerunning jdbcapi/checkDataSource test with client.
(was: Possible regression: jdbcapi/checkDataSource test hangs with client.
After test is aborted, if rerun it gives he conglomerate (129) requested does
not exist.)
Component: Store
(was: JDBC)
> conglomerate (129) requested does not exist error on create table after
> aborting and rerunning jdbcapi/checkDataSource test with client.
>
>
> Key: DERBY-1173
> URL: http://issues.apache.org/jira/browse/DERBY-1173
> Project: Derby
> Type: Bug
> Components: Network Client, Store
> Versions: 10.0.2.1
> Reporter: Kathey Marsden
> Priority: Critical
> Fix For: 10.2.0.0
>
> I had been working on the checkDataSource test a few weeks ago, to get it
> working with client but did not bring it into a suite at that time
> unfortunately.
> jdbcapi/checkDataSource.java now hangs with client. If I abort the test with
> c and rerun it fails on create table with:
> Booting Derby version The Apache Software Foundation - Apache Derby -
> 10.2.0.0 alpha - (1): instance c013800d-010a-51bb-ae54-048a8d0f
> on database directory D:\testout4\DerbyNetClient\checkDataSource\wombat
> Database Class Loader started - derby.database.classpath=''
> Could not listen on port 1527 on host localhost.
> 2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200),
> (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
> NF01.G90E-1097469790362120575{12}), Cleanup action starting
> 2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200),
> (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
> NF01.G90E-1097469790362120575{12}), Failed Statement is: create table y(i
> int)
> ERROR XSAI2: The conglomerate (129) requested does not exist.
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java:311)
> at
> org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(B2IFactory.java:241)
> at
> org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.java:484)
> at
> org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction.java:389)
> at
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1315)
> at
> org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRowListImpl(TabInfoImpl.java:525)
> at
> org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRow(TabInfoImpl.java:419)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptorNow(DataDictionaryImpl.java:1637)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(DataDictionaryImpl.java:1624)
> at
> org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(CreateTableConstantAction.java:223)
> at
> org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1160)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:158)
> at
> org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:4395)
> at
> org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:645)
> at
> org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:236)
> Cleanup action completed
> Apache Derby Network Server - 10.2.0.0 alpha shutdown at 2006-03-31
> 19:18:48.601 GMT
> There is some relevant revison history:
> At r 380672 I made some changes to the test and the test passed with client
> At r 387611 I made some comment changes and accidently enabled one of the
> failing client cases.
> At r 390481 I disabled the test for DERBY-1047 with client again, so the
> tests at 380672 (which passed) and the current test are the same.
> With the following patch for DERBY-1144 the test does not normally hang. I
> don't know why and am a bit hesitant to check this patch in since it might be
> masking something serious.
> Index: java/client/org/apache/derby/client/ClientPooledConnection.java
> ===
> --- java/client/org/apache/derby/client/ClientPooledConnection.java
> (revision
> 387603)
> +++ java/client/org/apache/derby/client/Cl
[jira] Commented: (DERBY-1173) Possible regression: jdbcapi/checkDataSource test hangs with client. After test is aborted, if rerun it gives he conglomerate (129) requested does not exist.
[
http://issues.apache.org/jira/browse/DERBY-1173?page=comments#action_12373522 ]
Kathey Marsden commented on DERBY-1173:
---
Just some more clues for anyone who might be trying to get a better repro for
this issue:
Likely the fix for DERBY-1144 changed the isolation level of some of the test
cases and caused previous lock timeouts or deadlocks to not occur. To get the
checkDataSource30 test running reliably. I set its derby properites to :
derby.locks.deadlockTimeout=1
derby.locks.waitTimeout=2
Without these set, I found that I did upon repeated runs get what appeared to
be a hang but perhaps was just a lock timeout. Then I aborted and rerun and
got the conglomerate (129) requested does not exist. error on create table.
(This was with the fix for DERBY-1144 in place.)
So short story, there is probably a good standalone repro that can be made
for this issue, by creating the deadlock or locktimeout scenario, but still
probably the easiest first step for anyone doing that would be to back out the
fix for DERBY-1144 to see the issue and narrow it down.
Also I no longer think this is a regression but probably started happenning
because some other locking behaviour or holdability changes that went in and
caused the test to expose this issue.
> Possible regression: jdbcapi/checkDataSource test hangs with client. After
> test is aborted, if rerun it gives he conglomerate (129) requested does not
> exist.
> --
>
> Key: DERBY-1173
> URL: http://issues.apache.org/jira/browse/DERBY-1173
> Project: Derby
> Type: Bug
> Components: JDBC, Network Client
> Versions: 10.0.2.1
> Reporter: Kathey Marsden
> Priority: Critical
> Fix For: 10.2.0.0
>
> I had been working on the checkDataSource test a few weeks ago, to get it
> working with client but did not bring it into a suite at that time
> unfortunately.
> jdbcapi/checkDataSource.java now hangs with client. If I abort the test with
> c and rerun it fails on create table with:
> Booting Derby version The Apache Software Foundation - Apache Derby -
> 10.2.0.0 alpha - (1): instance c013800d-010a-51bb-ae54-048a8d0f
> on database directory D:\testout4\DerbyNetClient\checkDataSource\wombat
> Database Class Loader started - derby.database.classpath=''
> Could not listen on port 1527 on host localhost.
> 2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200),
> (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
> NF01.G90E-1097469790362120575{12}), Cleanup action starting
> 2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200),
> (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
> NF01.G90E-1097469790362120575{12}), Failed Statement is: create table y(i
> int)
> ERROR XSAI2: The conglomerate (129) requested does not exist.
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java:311)
> at
> org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(B2IFactory.java:241)
> at
> org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.java:484)
> at
> org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction.java:389)
> at
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1315)
> at
> org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRowListImpl(TabInfoImpl.java:525)
> at
> org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRow(TabInfoImpl.java:419)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptorNow(DataDictionaryImpl.java:1637)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(DataDictionaryImpl.java:1624)
> at
> org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(CreateTableConstantAction.java:223)
> at
> org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1160)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:158)
> at
> org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:4395)
> at
> org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:645)
> at
> org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:236)
> Cleanup action completed
> Apache Derby Network Server - 10.2.0.0 alpha shutdown at 2006-03-31
> 19:18:48.601 G
Re: [jira] Commented: (DERBY-1164) 'show tables' and 'describe' commands in ij
Daniel John Debrunner (JIRA) wrote (2006-04-06 18:25:43): > ij is intended as a fairly neutral JDBC client that works against > any database engine. While it may be ok to tailor ij for Derby, Actually, I think should be an requrement that even if ij is somewhat tailored to Derby, it should remain database independent. That's one of the really nice features of ij. > having to need a specific version of ij to talk to a specific > version of Derby will cause problems. Agree! When testing/experimenting I often find myself having two connections in ij, one to a db from trunk and another which is 10.1. I would consider vetoing an ij tie in to specific Derby versions. > It would be interesting for you to provide a patch that uses the > DatabaseMetData methods directly and displays the resultant > ResultSets using the standard ij code. The we could think about the > "nice layout", what's nice to you maybe horrible to someone else. JDBC should provide enough metadata for this. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: Digital signature
[jira] Commented: (DERBY-1164) 'show tables' and 'describe' commands in ij
[ http://issues.apache.org/jira/browse/DERBY-1164?page=comments#action_12373519 ] Daniel John Debrunner commented on DERBY-1164: -- Copying the metadata queries into ij ties ij directly to a specific version of the database engine. I don't believe this is a good direction. ij is intended as a fairly neutral JDBC client that works against any database engine. While it may be ok to tailor ij for Derby, having to need a specific version of ij to talk to a specific version of Derby will cause problems. It would be interesting for you to provide a patch that uses the DatabaseMetData methods directly and displays the resultant ResultSets using the standard ij code. The we could think about the "nice layout", what's nice to you maybe horrible to someone else. > 'show tables' and 'describe' commands in ij > --- > > Key: DERBY-1164 > URL: http://issues.apache.org/jira/browse/DERBY-1164 > Project: Derby > Type: New Feature > Components: Tools > Reporter: Håvard Mork > Priority: Trivial > Attachments: 1164.diff, 1164_2.diff > > New users migrating from mysql are familiar with commands 'show tables' and > 'describe' to respectively display all permanent tables, and show fields in > a given table. These are not standard sql, but I suggest to implement them > only in the IJ tool for user-friendliness. > As suggested in db-dev, using DatabaseMetaData should provide the necessary > query strings. -- 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-1164) 'show tables' and 'describe' commands in ij
[ http://issues.apache.org/jira/browse/DERBY-1164?page=all ] Håvard Mork updated DERBY-1164: --- Attachment: 1164_2.diff Thank you for all your feedback. I've thought more about this, but I've been unable to find a good way to using the returned resultsets from DatabaseMetaData directly, while still getting a nice layout. In the attached patch, I have made local versions of the DatabaseMetaData query strings. Where possible, I've tried to cast data types so rows will fit on 80-char display widths. As for the querying parts, I'm unsure wether this is the best approach. > 'show tables' and 'describe' commands in ij > --- > > Key: DERBY-1164 > URL: http://issues.apache.org/jira/browse/DERBY-1164 > Project: Derby > Type: New Feature > Components: Tools > Reporter: Håvard Mork > Priority: Trivial > Attachments: 1164.diff, 1164_2.diff > > New users migrating from mysql are familiar with commands 'show tables' and > 'describe' to respectively display all permanent tables, and show fields in > a given table. These are not standard sql, but I suggest to implement them > only in the IJ tool for user-friendliness. > As suggested in db-dev, using DatabaseMetaData should provide the necessary > query strings. -- 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] Assigned: (DERBY-1184) 'CallableStatement.registerOutParameter(int,int,String)' does nothing in client driver
[ http://issues.apache.org/jira/browse/DERBY-1184?page=all ] Bryan Pendleton reassigned DERBY-1184: -- Assign To: Bryan Pendleton Thanks for contributing the patch, Kristian. I will see if there is a simple way for me to add a test for this change; I think I can see a way to do it. Unless there are any other comments on this issue, I'll commit this change once I get the test in place. > 'CallableStatement.registerOutParameter(int,int,String)' does nothing in > client driver > -- > > Key: DERBY-1184 > URL: http://issues.apache.org/jira/browse/DERBY-1184 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.2.0.0 > Environment: Derby network client > Reporter: Kristian Waagan > Assignee: Bryan Pendleton > Priority: Minor > Attachments: derby-1184-1a.diff, derby-1184-1a.stat > > The method 'CallableStatement.registerOutParameter(int,int,String)' does > nothing in the client driver. As stated in DERBY-447, the method throws a > not-implemented exception in the embedded driver. The method should be > changed to do this on the client side as well. -- 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-326) Improve streaming of large objects for network server and client
[ http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12373502 ] Kathey Marsden commented on DERBY-326: -- The response by mail was that yes traditional way for blob meant that BLOB's would still be materialized into memory on the server.The description of the performance degredation for BLOB's made it sound like it was not severe. I think a slight performance degradation for BLOB's is an exceptable trade off for not having them materialized into memory. > Improve streaming of large objects for network server and client > > > Key: DERBY-326 > URL: http://issues.apache.org/jira/browse/DERBY-326 > Project: Derby > Type: Improvement > Components: Network Server, Network Client, Performance > Reporter: Kathey Marsden > Assignee: Tomohito Nakayama > Attachments: ClobTest.zip, DERBY-326.patch, DERBY-326_2.patch, > DERBY-326_3.patch, DERBY-326_4.patch, DERBY-326_5.patch, > DERBY-326_5_indented.patch, DERBY-326_6.patch, > ReEncodedInputStream.java.modifiedForLongRun > > Currently the stream writing methods in network server and client require a > length parameter. This means that we have to get the length of the stream > before sending it. For example in network server in EXTDTAInputStream we have > to use getString and getbytes() instead of getCharacterStream and > getBinaryStream so that we can get the length. > SQLAM Level 7 provides for the enhanced LOB processing to allow streaming > without indicating the length, so, the writeScalarStream methods in > network server DDMWriter.java and network client Request.java can be changed > to not require a length. > Code inspection of these methods seems to indicate that while the length is > never written it is used heavily in generating the DSS. One strange thing is > that it appears on error, the stream is padded out to full length with zeros, > but an actual exception is never sent. Basically I think perhaps these > methods need to be rewritten from scratch based on the spec requirements for > lobs. > After the writeScalarStream methods have been changed, then EXTDAInputStream > can be changed to properly stream LOBS. See TODO tags in this file for more > info. I am guessing similar optimizations available in the client as well, > but am not sure where that code is. -- 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: Regression Test Failure! - TinderBox_Derby 391903 - Sun DBTG
The checkDataSource failures are a bit disconcerting. Does anyone have any ideas for the cause? David [EMAIL PROTECTED] wrote: [Auto-generated mail] *TinderBox_Derby* 391903/2006-04-06 07:22:18 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2647645 0 243.63% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-391903.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/391903.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/391903.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client
Hello. Seeing the code around DERBY-326, I guess that what makes the difference is that stream from clob is re-encoded to UTF-8. Original implementation expands stream from clob to memory entirely as character, and encode expanded characters to bytes array again. I think saving the processes that expand large objects entirely to memory twice improved the performance of streaming clob. Best regards. Oystein Grovlen - Sun Norway wrote: TomohitoNakayama wrote: Hello. Yes for blob. What makes blob different from clob? I would have guessed that the implementation of clobs and blobs should be very similar. -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Regression Test Failure! - TinderBox_Derby 391903 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 391903/2006-04-06 07:22:18 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2647645 0 243.63% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-391903.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/391903.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/391903.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Regression Test Failure! - Derby 391687 - Sun DBTG
[Auto-generated mail] *Derby* 391687/2006-04-05 19:45:56 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 6645639 0 111.69% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-391687.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/391687M.html *Jvm: 1.5* 3646643 0 104.12% CYGWIN_NT-5.1_i686-unknown 2646644 0 115.89% CYGWIN_NT-5.2_i686-unknown 0646646 0 119.22% Linux-2.6.14-1.1644_FC4_i686-i686 1646645 0 103.96% Linux-2.6.9-34.ELsmp_x86_64-x86_64 0646646 0 112.39% SunOS-5.10_i86pc-i386 0646646 0 133.93% SunOS-5.10_sun4u-sparc 2646644 0 108.94% SunOS-5.11_i86pc-i386 1646645 0 108.69% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-391687.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/391687.html *Jvm: 1.4* 3643640 2 100.81% CYGWIN_NT-5.1_i686-unknown 1643642 2 112.42% Linux-2.6.14-1.1644_FC4_i686-i686 0643643 2 100.57% Linux-2.6.9-34.ELsmp_x86_64-x86_64 0643643 2 110.49% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-391687.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/391687.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/391687.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client
TomohitoNakayama wrote: Hello. Yes for blob. What makes blob different from clob? I would have guessed that the implementation of clobs and blobs should be very similar. -- Øystein
