[jira] Updated: (DERBY-3162) Create a framework for replication tests
[ https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Solberg updated DERBY-3162: --- Derby Info: [Patch Available] Create a framework for replication tests Key: DERBY-3162 URL: https://issues.apache.org/jira/browse/DERBY-3162 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Ole Solberg Assignee: Ole Solberg Priority: Minor Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt, derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt, derby-3162.3-v4d.stat.txt, derby-3162.4-v1.diff.txt, derby-3162.4-v1.stat.txt, derby-3162.4-v2.diff.txt, derby-3162.4-v2.stat.txt Handle - starting and stopping Derby servers to have the master and slave replication roles, - doing administrative commands like startreplication, startslave, stopreplication, failover, - performing consistency checks on the slave vs. the master, - running load clients against master and slave in the various states of replication, - provoking error situations on master and slave, and network, - ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3322) Server guide refers to phantom property in template policy file for the Network Server
[
https://issues.apache.org/jira/browse/DERBY-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576897#action_12576897
]
John H. Embretsen commented on DERBY-3322:
--
Thanks for committing, Dyre!
Hmm, I don't see the committed changes in the published version of the docs at
http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html.
Is something wrong with syncing to the web?
Server guide refers to phantom property in template policy file for the
Network Server
--
Key: DERBY-3322
URL: https://issues.apache.org/jira/browse/DERBY-3322
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.3.1.4, 10.3.2.1
Environment: N/A
Reporter: John H. Embretsen
Assignee: John H. Embretsen
Priority: Trivial
Fix For: 10.4.0.0
Attachments: d3322v01.diff, tadminnetservcustom.html
The Server and Administration guide contains a section about customizing the
Network Server's security policy, based on the template policy:
http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html
This section mentions that the variable ${derby.security.host} should be
replaced with a suitable value.
However, the template policy, at /demo/templates/server.policy (released
binaries) or java/drda/org/apache/derby/drda/template.policy (SVN codeline),
does not refer to any variable or property called ${derby.security.host}.
Instead, the policy file specifies the wildcard address, with appropriate
comments:
quote
// Accept connections from any host. Derby is listening to the host
// interface specified via the -h option to NetworkServerControl
// start on the command line, via the address parameter to the
// org.apache.derby.drda.NetworkServerControl constructor in the API
// or via the property derby.drda.host; the default is localhost.
// You may want to restrict allowed hosts, e.g. to hosts in a specific
// subdomain, e.g. *.acme.com.
permission java.net.SocketPermission *, accept;
/quote
See also
http://www.nabble.com/Customizing-the-Network-Server%27s-security-policy-%28docs-vs.-reality%29-td14841290.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result
[ https://issues.apache.org/jira/browse/DERBY-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576898#action_12576898 ] Thomas Nielsen commented on DERBY-2351: --- I agree, 'modifySynonymResult.diff' is worthy of commit. ORDER BY with expression with distinct in the select list returns incorrect result -- Key: DERBY-2351 URL: https://issues.apache.org/jira/browse/DERBY-2351 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4 Environment: Any Reporter: Yip Ng Assignee: Bryan Pendleton Fix For: 10.3.2.2, 10.4.0.0 Attachments: d2351_aliasing.diff, d2351_aliasing.diff, d2351_aliasing_checkQualifiedName.diff, derby_2351.diff, derby_2351_v2.diff, modifySynonymResults.diff, reproTests.diff When distinct is in the select list and the query has order by with expression, the resultset produced contains an additional column. ij create table t1 (c1 int, c2 varchar(10)) 0 rows inserted/updated/deleted ij insert into t1 values (1,'a'),(2,'b'),(3,'c'); 3 rows inserted/updated/deleted select distinct c1, c2 from t1 order by c1; C1 |C2 -- 1 |a 2 |b 3 |c 3 rows selected ij select distinct c1, c2 from t1 order by c1+1; C1 |C2|3 =returns 3 columns, incorrect result returned -- 1 |a |2 2 |b |3 3 |c |4 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3518) Getting started guide: Incomplete instructions for compiling WwdEmbedded.java
Getting started guide: Incomplete instructions for compiling WwdEmbedded.java - Key: DERBY-3518 URL: https://issues.apache.org/jira/browse/DERBY-3518 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.2.1 Reporter: John H. Embretsen Priority: Minor In the Getting Started with Derby manual's Self-study tutorial for users new to Derby, there is an Activity 3 which describes how to run a JDBC program using the embedded driver: http://db.apache.org/derby/docs/dev/getstart/twwdactivity3_Setup.html . In step 2, the guide says: quote Compile the WwdEmbedded.java program. javac WwdEmbedded.java /quote Since WwdEmbedded.java (available from bin-installation/demo/programs/workingwithderby/) references the WwdUtils class, WwdUtils.java needs to be copied and compiled as well. Otherwise, compiling will fail with: WwdEmbedded.java:80: cannot resolve symbol symbol : variable WwdUtils location: class WwdEmbedded if (! WwdUtils.wwdChk4Table(conn)) ^ WwdEmbedded.java:92: cannot resolve symbol symbol : variable WwdUtils location: class WwdEmbedded answer = WwdUtils.getWishItem(); ^ 2 errors The manual should be updated to reflect this requirement. This issue was first reported on the derby-user mailing list 2008-03-06 by Tosca Lahiri, see http://www.nabble.com/javac-WwdEmbedded.java-td15924527.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3518) Getting started guide: Incomplete instructions for compiling WwdEmbedded.java
[ https://issues.apache.org/jira/browse/DERBY-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576910#action_12576910 ] John H. Embretsen commented on DERBY-3518: -- Activity 4, Step 1 f (compiling WwdClient.java) should probably clarify this as well. Getting started guide: Incomplete instructions for compiling WwdEmbedded.java - Key: DERBY-3518 URL: https://issues.apache.org/jira/browse/DERBY-3518 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.2.1 Reporter: John H. Embretsen Priority: Minor In the Getting Started with Derby manual's Self-study tutorial for users new to Derby, there is an Activity 3 which describes how to run a JDBC program using the embedded driver: http://db.apache.org/derby/docs/dev/getstart/twwdactivity3_Setup.html . In step 2, the guide says: quote Compile the WwdEmbedded.java program. javac WwdEmbedded.java /quote Since WwdEmbedded.java (available from bin-installation/demo/programs/workingwithderby/) references the WwdUtils class, WwdUtils.java needs to be copied and compiled as well. Otherwise, compiling will fail with: WwdEmbedded.java:80: cannot resolve symbol symbol : variable WwdUtils location: class WwdEmbedded if (! WwdUtils.wwdChk4Table(conn)) ^ WwdEmbedded.java:92: cannot resolve symbol symbol : variable WwdUtils location: class WwdEmbedded answer = WwdUtils.getWishItem(); ^ 2 errors The manual should be updated to reflect this requirement. This issue was first reported on the derby-user mailing list 2008-03-06 by Tosca Lahiri, see http://www.nabble.com/javac-WwdEmbedded.java-td15924527.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3374) Hang in master server if startMaster command is given twice
[ https://issues.apache.org/jira/browse/DERBY-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland resolved DERBY-3374. -- Resolution: Fixed Fix Version/s: 10.4.0.0 Assignee: V.Narayanan I tried to reproduce the bug with no luck: [after starting slave] ij connect 'jdbc:derby:test;startMaster=true;slaveHost=khepri05'; ij(CONNECTION1) connect 'jdbc:derby:test;startMaster=true;slaveHost=khepri05'; ERROR XRE22: Replication master has already been booted for database 'test' As far as I can tell, the bug was fixed by Narayanan as part of DERBY-3358 patch 4. Hang in master server if startMaster command is given twice --- Key: DERBY-3374 URL: https://issues.apache.org/jira/browse/DERBY-3374 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0 Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b Reporter: Ole Solberg Assignee: V.Narayanan Fix For: 10.4.0.0 master and slave servers started. startSlave: ij CONNECT 'jdbc:derby://urd12:/test;startSlave=true;slaveHost=urd12;slavePort=8989'; ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC: Replication slave mode started successfully for database 'test'. Connection refused because the database is in replication slave mode. slave derby.log: Replication slave role started for database 'test'. startMaster: ij CONNECT 'jdbc:derby://urd11:/test;startMaster=true;slaveHost=urd12;slavePort=8989'; ij master derby.log: Replication master role started for database 'null'. 2. startMaster: ij CONNECT 'jdbc:derby://urd11:/test;startMaster=true;slaveHost=urd12;slavePort=8989'; ij does not return. No output to master OR slave derby.log. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Regression Test Report - Daily 635013 - Sun DBTG
On most platforms suitesAll was hanging and causing the machines to get in a state not able to run the next testbatches. This is now being investigated and we hope to be able to start a daily tests tonight with better results. So sorry for the inconvenience! Especially when such things happen tin a weekend, it has a much bigger impact. Henri [EMAIL PROTECTED] wrote: [Auto-generated mail] *Daily* 635013/2008-03-08 18:01:05 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 1274273 094.12% derbyall 01041610416 0 1593.56% suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 0274274 0 114.40% derbyall 01041610416 0 1802.34% suitesAll solN+1 NA NA NANA derbyall NA NA NANA suitesAll sparc NA NA NANA derbyall NA NA NANA suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 NA NA NANA derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-635013.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/635013_bySig.html *Jvm: 1.5* lin 1275274 086.36% derbyall NA NA NANA suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 0275275 080.20% derbyall NA NA NANA suitesAll solN+1 NA NA NANA derbyall NA NA NANA suitesAll sparc NA NA NANA derbyall NA NA NANA suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 NA NA NANA derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-635013.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/635013_bySig.html *Jvm: 1.4* lin NA NA NANA derbyall NA NA NANA suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol NA NA NANA derbyall NA NA NANA suitesAll solN+1 NA NA NANA derbyall NA NA NANA suitesAll sparc NA NA NANA derbyall NA NA NANA suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 NA NA NANA derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-635013.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/635013_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/635013.txt ( All results in http://dbtg.thresher.com/derby/test/ ) -- With regards, Henri van de Scheur, Database Technology Group, Sun Microsystems, Trondheim, Norway
[jira] Commented: (DERBY-3373) SQL distinct and order by needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576926#action_12576926 ] Thomas Nielsen commented on DERBY-3373: --- I agree it would probably be good to allow the legal queries once again, even if the expense is allowing an illegal one. That said we should ultimately reject the bad illegal ones. If that's our understanding, the patch looks ok. The changed test run successfully. If I understand correctly what you're looking for in the removed if statement is something like if none of the columns in the orderby column list are in the target.rcl, and the target is a distinct query, then throw exception ? Didn't the removed if statement really said the inverse? if there is a column in the orderby columns that isn't in the target.rcl, and target is a distinct, then throw exception SQL distinct and order by needed together - Key: DERBY-3373 URL: https://issues.apache.org/jira/browse/DERBY-3373 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.2.1 Environment: Solaris Dev Express, Java 5 Reporter: Thomas Vatter Assignee: Bryan Pendleton Priority: Blocker Fix For: 10.3.2.2 Attachments: allowExpressions.diff I am pasting here the communication from the mailinglist. I am having a blocking and large problem with it because I have to make a release that needs the specified SQL query. tom_ wrote: The errormessage is The ORDER BY clause may not specify an expression, since the query specifies DISTINCT [Error Code: 2] [SQL State: 4287A] The statement is select distinct t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 from t1, t2, t3 where ... order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) Dyre.Tjeldvoll wrote: tom_ [EMAIL PROTECTED] writes: I am using disctinct because of some self-joins and also needed to add an order by clause. An error is shown. Is it not possible to use distinct and order by together? I think it is allowed. Executing select distinct * from sys.systables order by tablename; in ij works just fine. Could you show the error message you get, and perhaps what the table looks like? -- dt « [hide part of quote] Hi Tom - I see what you mean using the demo DB toursDB: ij select * from airlines order by lower(airline_full); A|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT |BUSINESS_LEVEL_FACTOR |FIRSTCLASS_LEVEL_FACT|ECONOMY_SE|BUSINESS_S|FIRSTCLASS --- AA|Amazonian Airways |0.18 |0.03 |0.5 |1.5 |20 |10 |5 US|Union Standard Airlines |0.19 |0.05 |0.4 |1.6 |20 |10 |5 2 rows selected ij select distinct * from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij select distinct airline_full from airlines order by lower(airline_full); ERROR 4287A: The ORDER BY clause may not specify an expression, since the query specifies DISTINCT. ij I didn't find a JIRA enhancement to remove this restriction. I suggest you file an Enhancement request to remove the restriction reported by ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2872) Add Replication functionality to Derby
[ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-2872: - Attachment: replication_funcspec_v10.html Funcspec v10: Replication system privilege not included in 10.4 Add Replication functionality to Derby -- Key: DERBY-2872 URL: https://issues.apache.org/jira/browse/DERBY-2872 Project: Derby Issue Type: New Feature Components: Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: master_classes_1.pdf, poc_master_v2.diff, poc_master_v2.stat, poc_master_v2b.diff, poc_slave_v2.diff, poc_slave_v2.stat, poc_slave_v2b.diff, poc_slave_v2c.diff, proof-of-concept_v2b-howto.txt, proof_of_concept_master.diff, proof_of_concept_master.stat, proof_of_concept_slave.diff, proof_of_concept_slave.stat, replication_funcspec.html, replication_funcspec_v10.html, replication_funcspec_v10.html, replication_funcspec_v2.html, replication_funcspec_v3.html, replication_funcspec_v4.html, replication_funcspec_v5.html, replication_funcspec_v6.html, replication_funcspec_v7.html, replication_funcspec_v8.html, replication_funcspec_v9.html, replication_script.txt, ReplicationDesign.pdf, ReplicationWriteup.txt, slave_classes_1.pdf It would be nice to have replication functionality to Derby; many potential Derby users seem to want this. The attached functional specification lists some initial thoughts for how this feature may work. Dag Wanvik had a look at this functionality some months ago. He wrote a proof of concept patch that enables replication by copying (using file system copy) and redoing the existing Derby transaction log to the slave (unfortunately, I can not find the mail thread now). DERBY-2852 contains a patch that enables replication by sending dedicated logical log records to the slave through a network connection and redoing these. Replication has been requested and discussed previously in multiple threads, including these: http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/[EMAIL PROTECTED] http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: They all seem like bug fixes that would need to be merged to the new branch so unless I hear otherwise, I plan to cut the branch(es) from revision 635183. I plan to do this early on Monday (CET). Done: r635491 | dyre | 2008-03-10 09:59:34 +0100 (Mon, 10 Mar 2008) | 1 line Created 10.4 source branch r635492 | dyre | 2008-03-10 10:00:21 +0100 (Mon, 10 Mar 2008) | 1 line Created 10.4 doc branch The wiki page for how to bump the version number on trunk was a bit out-dated, but I think I got it to work. I'm currently running the tests to make sure. Will commit the version bump as soon as they have finished (if everything is ok). -- dt
[jira] Resolved: (DERBY-3497) OOME at slave during replication
[ https://issues.apache.org/jira/browse/DERBY-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland resolved DERBY-3497. -- Resolution: Fixed Fix Version/s: 10.4.0.0 OOME at slave during replication Key: DERBY-3497 URL: https://issues.apache.org/jira/browse/DERBY-3497 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0 Environment: trunk at revision 633807 Reporter: Øystein Grøvlen Assignee: Jørgen Løland Fix For: 10.4.0.0 Attachments: derby-3497-1a.diff, derby-3497-1a.stat After deleting and inserting more than 1 million records during replication, I got java.lang.OutOfMemoryError: Java heap space. The heap dump shows that almost the entire heap is byte arrays, and it seems most of them are referred to by ReplicationMessage objects. An inspection of the heap dump in VisualVM it seems that it is references rooted in SocketConnection#objInputStream that keeps them from being garbage collected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2872) Add Replication functionality to Derby
[ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-2872: - Attachment: replication_funcspec_v10.html Attached new funcspec (v10). It includes 'slave crashes' failure scenario, new default replication port (4851) and camel-cased slaveHost/slavePort Add Replication functionality to Derby -- Key: DERBY-2872 URL: https://issues.apache.org/jira/browse/DERBY-2872 Project: Derby Issue Type: New Feature Components: Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: master_classes_1.pdf, poc_master_v2.diff, poc_master_v2.stat, poc_master_v2b.diff, poc_slave_v2.diff, poc_slave_v2.stat, poc_slave_v2b.diff, poc_slave_v2c.diff, proof-of-concept_v2b-howto.txt, proof_of_concept_master.diff, proof_of_concept_master.stat, proof_of_concept_slave.diff, proof_of_concept_slave.stat, replication_funcspec.html, replication_funcspec_v10.html, replication_funcspec_v2.html, replication_funcspec_v3.html, replication_funcspec_v4.html, replication_funcspec_v5.html, replication_funcspec_v6.html, replication_funcspec_v7.html, replication_funcspec_v8.html, replication_funcspec_v9.html, replication_script.txt, ReplicationDesign.pdf, ReplicationWriteup.txt, slave_classes_1.pdf It would be nice to have replication functionality to Derby; many potential Derby users seem to want this. The attached functional specification lists some initial thoughts for how this feature may work. Dag Wanvik had a look at this functionality some months ago. He wrote a proof of concept patch that enables replication by copying (using file system copy) and redoing the existing Derby transaction log to the slave (unfortunately, I can not find the mail thread now). DERBY-2852 contains a patch that enables replication by sending dedicated logical log records to the slave through a network connection and redoing these. Replication has been requested and discussed previously in multiple threads, including these: http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/[EMAIL PROTECTED] http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: {VOTE] Kim Haase as a committer
Rick Hillegas wrote: Please vote on whether we should make Kim Haase a committer. +1 -- Kristian
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576944#action_12576944 ] Jørgen Løland commented on DERBY-3169: -- Hi Kim, A few more comments now that the 10.4 branch has been cut: * The system privileges did not make it into 10.4 (see funcspec v 10) * The funcspec v10 contains a new failure handling scenario: 'slave crashes'. * We have decided to use slaveHost and slavePort attribute names (were: slavehost and slaveport) for uniformity. * The default replication port has been changed from 8001 to 4851 - this port number was given to us by IANA. * There are now four configurable properties for replication: - derby.replication.verbose - true/false - whether or not replication messages are written to log (default: true) - derby.replication.logBufferSize - the size of the replication log buffers in bytes. These buffers store the log on the master side while waiting to be shipped to the slave. There are a total of 10 such buffers. Large buffers increase the memory usage but reduces the chance that the buffer gets full (in turn increasing response time for transactions on master, as described in funcspec Handling failure scenarios - The master Derby instance is not able to send log to the slave at the same pace as log is generated...). Default: 32768 (32KB). Minimum value: 8192 (8 KB), maximum value: 1048576 (1 MB) - derby.replication.minLogShippingInterval - the shortest interval between two consecutive log shipments - derby.replication.maxLogShippingInterval - the longest interval between two consecutive log shipments (a soft guarantee that the slave will not deviate more than this amount of millis from the master) Add documentation for replication - Key: DERBY-3169 URL: https://issues.apache.org/jira/browse/DERBY-3169 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Kim Haase Attachments: DERBY-3169-2.diff, DERBY-3169-2.stat, DERBY-3169-2.zip, DERBY-3169-3.diff, DERBY-3169-3.zip, DERBY-3169.diff, DERBY-3169.stat, DERBY-3169.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3507) startNetworkServer and stopNetworkServer don't pass arguments
[ https://issues.apache.org/jira/browse/DERBY-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galinette updated DERBY-3507: - Description: The help scripts $DERBY_HOME/bin/startNetworkServer and $DERBY_HOME/bin/stopNetworkServer don't pass arguments (as -h or -p) to class org.apache.derby.drda.NetworkServerControl. Solution: append command line with $@ before: derby_exec_command=exec \$JAVACMD\ $DERBY_OPTS -classpath \$LOCALCLASSPATH\ org.apache.derby.drda.NetworkServerControl start after: derby_exec_command=exec \$JAVACMD\ $DERBY_OPTS -classpath \$LOCALCLASSPATH\ org.apache.derby.drda.NetworkServerControl start $@ was: The help scripts $DERBY_HOME/bin/startNetworkServer and $DERBY_HOME/bin/stopNetworkServer don't pass arguments (as -h or -p) to class org.apache.derby.drda.NetworkServerControl. Solution: append command line with $@ before: derby_exec_command=exec \$JAVACMD\ $DERBY_OPTS -classpath \$LOCALCLASSPATH\ org.apache.derby.drda.NetworkServerControl shutdown after: derby_exec_command=exec \$JAVACMD\ $DERBY_OPTS -classpath \$LOCALCLASSPATH\ org.apache.derby.drda.NetworkServerControl shutdown $@ startNetworkServer and stopNetworkServer don't pass arguments - Key: DERBY-3507 URL: https://issues.apache.org/jira/browse/DERBY-3507 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.3.1.4, 10.3.2.1 Environment: not applicable Reporter: Galinette Original Estimate: 0.08h Remaining Estimate: 0.08h The help scripts $DERBY_HOME/bin/startNetworkServer and $DERBY_HOME/bin/stopNetworkServer don't pass arguments (as -h or -p) to class org.apache.derby.drda.NetworkServerControl. Solution: append command line with $@ before: derby_exec_command=exec \$JAVACMD\ $DERBY_OPTS -classpath \$LOCALCLASSPATH\ org.apache.derby.drda.NetworkServerControl start after: derby_exec_command=exec \$JAVACMD\ $DERBY_OPTS -classpath \$LOCALCLASSPATH\ org.apache.derby.drda.NetworkServerControl start $@ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: They all seem like bug fixes that would need to be merged to the new branch so unless I hear otherwise, I plan to cut the branch(es) from revision 635183. I plan to do this early on Monday (CET). The wiki page for how to bump the version number on trunk was a bit out-dated, but I think I got it to work. I'm currently running the tests to make sure. Will commit the version bump as soon as they have finished (if everything is ok). r63 | dyre | 2008-03-10 14:46:28 +0100 (Mon, 10 Mar 2008) | 2 lines Bumping the minor version number on trunk. New version number is 10.5. Those who follow the Wiki updates closely will have seen that my understanding has changed throughout the day :( http://wiki.apache.org/db-derby/DerbySnapshotOrRelease describes my current understanding of the version bumping process. Please comment if I have messed something up. The update of the maint property on the 10.4 branch will hopefully happen soon... -- dt
[jira] Commented: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes
[ https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576992#action_12576992 ] Knut Anders Hatlen commented on DERBY-2911: --- I improved some comments in revision 635556 to address 1a and 1d. 1b and 1c were addressed in revision 635183 as part of DERBY-3493. Implement a buffer manager using java.util.concurrent classes - Key: DERBY-2911 URL: https://issues.apache.org/jira/browse/DERBY-2911 Project: Derby Issue Type: Improvement Components: Performance, Services Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, d2911-10.diff, d2911-10.stat, d2911-11.diff, d2911-2.diff, d2911-3.diff, d2911-4.diff, d2911-5.diff, d2911-6.diff, d2911-6.stat, d2911-7.diff, d2911-7a.diff, d2911-9.diff, d2911-9.stat, d2911-enable.diff, d2911-entry-javadoc.diff, d2911-unused.diff, d2911-unused.stat, d2911perf.java, derby-2911-8.diff, derby-2911-8.stat, perftest.diff, perftest.pdf, perftest.stat, perftest2.diff, perftest6.pdf, poisson_patch8.tar There are indications that the buffer manager is a bottleneck for some types of multi-user load. For instance, Anders Morken wrote this in a comment on DERBY-1704: With a separate table and index for each thread (to remove latch contention and lock waits from the equation) we (...) found that org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 times more contention than the synchronization in LockSet.lockObject() and LockSet.unlock(). That might be an indicator of where to apply the next push. It would be interesting to see the scalability and performance of a buffer manager which exploits the concurrency utilities added in Java SE 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3503) Change stress.multi to dump thread stacks before killing off testers with jdk 1.5 and higher
[
https://issues.apache.org/jira/browse/DERBY-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577002#action_12577002
]
Knut Anders Hatlen commented on DERBY-3503:
---
Thanks for updating the patch. Looks much better now!
Just to continue the nit-picking (sorry...), you missed one occurrence of
incorrect indentation in a comment in MultiTest (probably a tab size issue).
Also, in this code:
+ if (j.atLeast(1,5))
+ {
+ Class c =
Class.forName(org.apache.derbyTesting.functionTests.util.ThreadDump);
and in this code:
+ catch (Exception e)
+ {
+ // if we get an exception trying to get a
thread dump. Just print it to the log and continue.
I guess you intended to move all but the first line one indentation level left
to save some space.
And, talking about saving space, I don't think I would have bothered unwrapping
the PrivilegedActionException and the InvocationTargetException, as the
original exception is in the chain and its stack trace is printed anyway. Not a
big deal, but it would perhaps make the code a bit cleaner.
And, since you're using Emacs... :) I have this function in ~/.emacs:
(defun kah:clean-patch ()
(interactive)
(save-excursion
(query-replace-regexp ^\\+\\(\\([^\n]*[^ \t\n]\\)\\|\\)[ \t]+$ +\\1
nil (point-min) (point-max
Each time after I download a patch (or before I upload a patch), I open the
patch in Emacs and type M-x kah:clean-patch to get rid of trailing spaces.
Change stress.multi to dump thread stacks before killing off testers with jdk
1.5 and higher
Key: DERBY-3503
URL: https://issues.apache.org/jira/browse/DERBY-3503
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.4.0.0
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Priority: Minor
Attachments: derby-3503_diff.txt, derby-3503_diff.txt
Jdk 1.5 introduced Thread.getAllStackTraces() which can be used to print a
thread dump programatically. The test stress.multi kills off its testers if
it reaches a deadlock or the testers can't complete on their own. It would be
helpful in this case to get a thread dump automatically. The code could only
be enabled for jdk 1.5 and higher.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3162) Create a framework for replication tests
[ https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Solberg updated DERBY-3162: --- Attachment: derby-3162.4-v3.stat.txt derby-3162.4-v3.diff.txt Patch derby-3162.4-v3 replaces derby-3162.4-v2. This patch uses the complete classpath without attempting to run with a minimal classpath when starting servers etc. I have successfully run ReplicationSuite against jar files AND against class files. The patch still disables ReplicationSuite.suite() in suites.All. Create a framework for replication tests Key: DERBY-3162 URL: https://issues.apache.org/jira/browse/DERBY-3162 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Ole Solberg Assignee: Ole Solberg Priority: Minor Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt, derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt, derby-3162.3-v4d.stat.txt, derby-3162.4-v1.diff.txt, derby-3162.4-v1.stat.txt, derby-3162.4-v2.diff.txt, derby-3162.4-v2.stat.txt, derby-3162.4-v3.diff.txt, derby-3162.4-v3.stat.txt Handle - starting and stopping Derby servers to have the master and slave replication roles, - doing administrative commands like startreplication, startslave, stopreplication, failover, - performing consistency checks on the slave vs. the master, - running load clients against master and slave in the various states of replication, - provoking error situations on master and slave, and network, - ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2559) recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan resolved DERBY-2559. Resolution: Fixed Thank you Army. The revision you mention updates the documentation, but does not fix the JavaDoc error (didn't notice...). I didn't merge it right away because I got conflicts for 10.2, but it applies fine for 10.3. Merged patch 3b to 10.3 with revision 635567, and also fixed the JavaDoc error in the same commit. Resolving issue, reopen to merge the fixes back to 10.2. Will close the issue in a few days. recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails Key: DERBY-2559 URL: https://issues.apache.org/jira/browse/DERBY-2559 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Myrna van Lunteren Assignee: Kristian Waagan Fix For: 10.3.2.2, 10.4.0.0 Attachments: derby-2559-1a.diff, derby-2559-2a-defenses.diff, derby-2559-3a-documentation.diff, derby-2559-3b-documentation.diff Consider the following code snippet from test DataSourceReferenceTest: Referenceable refDS = (Referenceable) ds; Reference dsAsReference = refDS.getReference(); String factoryClassName = dsAsReference.getFactoryClassName(); ObjectFactory factory = (ObjectFactory) Class.forName(factoryClassName).newInstance(); Object recreatedDS = factory.getObjectInstance(dsAsReference, null, null, null); - When ds is a ClientDataSource40 (i.e. when running with jdk16), recreatedDS is null. Note, that this showed up only after converting the test to junit, because the original test hardcoded the ds to be a ClientDataSource. I confirmed this not to be related to my changes for DERBY-2296 (which prompted me to convert the test), by backing out my changes to ClientBaseDataSource and client/am/Connection and rerunning the test (needed some minor adjustments of expected values table/array). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3162) Create a framework for replication tests
[ https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Øystein Grøvlen updated DERBY-3162: --- Derby Info: (was: [Patch Available]) Thanks, Ole. Patch derby-3162.4-v3 committed as revision 635575. Create a framework for replication tests Key: DERBY-3162 URL: https://issues.apache.org/jira/browse/DERBY-3162 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Ole Solberg Assignee: Ole Solberg Priority: Minor Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt, derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt, derby-3162.3-v4d.stat.txt, derby-3162.4-v1.diff.txt, derby-3162.4-v1.stat.txt, derby-3162.4-v2.diff.txt, derby-3162.4-v2.stat.txt, derby-3162.4-v3.diff.txt, derby-3162.4-v3.stat.txt Handle - starting and stopping Derby servers to have the master and slave replication roles, - doing administrative commands like startreplication, startslave, stopreplication, failover, - performing consistency checks on the slave vs. the master, - running load clients against master and slave in the various states of replication, - provoking error situations on master and slave, and network, - ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Not able to get in-place compression to release space to file system
I have been experimenting a bit with in-place compression on a large
table, but I have not been successful in getting it to give back space
to the file system. I have table that I have done a lot of bulk
changes to over time. It is now much smaller than it was at its peak
size, but I am not able to reduce the size of the corresponding files
by in-place compression. My last attempt:
ij select conglomeratename, isindex, numallocatedpages, numfreepages,
pagesize, estimspacesaving from new
org.apache.derby.diag.SpaceTable('T') t order by conglomeratename;
CONGLOMERATENAME
|ISIND|NUMALLOCATEDPAGES |NUMFREEPAGES|PAGESIZE
|ESTIMSPACESAVING
--
T
|0 |8671
|411071 |4096 |1683746816
X_I
|1 |757
|19535 |4096 |80015360
2 rows selected
ij CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('OYSTEIN', 'T', 1, 1, 1);
0 rows inserted/updated/deleted
ij select conglomeratename, isindex, numallocatedpages, numfreepages,
pagesize, estimspacesaving from new
org.apache.derby.diag.SpaceTable('T') t order by conglomeratename;
CONGLOMERATENAME
|ISIND|NUMALLOCATEDPAGES |NUMFREEPAGES|PAGESIZE
|ESTIMSPACESAVING
--
T
|0 |7843
|411899 |4096 |1687138304
X_I
|1 |757
|19479 |4096 |79785984
2 rows selected
As you can see, there is a lot of free pages, both before and after
the compress, and the total number of pages has not been changed.
Some more details:
The table has two columns an integer and a varchar(1024) column. All
values for the varchar column is the same 640 characters. (The
varchar column was added by alter table.) I have a unique index on the
integer column. I have populated the index by repeatedly doubling its
size by 'insert into T select i+k, c from T', where k is the current
number of records in the table. I have also deleted rows and
reinserted the values, usually the rows with highest integer values,
but at one point I executed 'delete from T where random() 0.25'. I
have also reinserted some of the rows that was deleted by that query.
After the random deletions I have several times tried to compress the
table with no luck. Finally, I deleted all rows with an integer value
higher than 65536, but compress does still not release pages as shown
above.
--
Øystein
[jira] Commented: (DERBY-3162) Create a framework for replication tests
[ https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577027#action_12577027 ] Jørgen Løland commented on DERBY-3162: -- I encountered an issue with the classpath. I use this setup in all my sandboxes: sandbox |-- test | |-- oldharness | `-- junit `-- trunk When I run the replication test suite from the junit directory with classpath=../../trunk/jars/sane, I get a java.lang.NoClassDefFoundError: org/apache/derby/drda/NetworkServerControl If I replace the classpath with the absolute path ( /home/.../trunk/jars/sane), the problem goes away. Create a framework for replication tests Key: DERBY-3162 URL: https://issues.apache.org/jira/browse/DERBY-3162 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Ole Solberg Assignee: Ole Solberg Priority: Minor Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt, derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt, derby-3162.3-v4d.stat.txt, derby-3162.4-v1.diff.txt, derby-3162.4-v1.stat.txt, derby-3162.4-v2.diff.txt, derby-3162.4-v2.stat.txt, derby-3162.4-v3.diff.txt, derby-3162.4-v3.stat.txt Handle - starting and stopping Derby servers to have the master and slave replication roles, - doing administrative commands like startreplication, startslave, stopreplication, failover, - performing consistency checks on the slave vs. the master, - running load clients against master and slave in the various states of replication, - provoking error situations on master and slave, and network, - ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: {VOTE] Kim Haase as a committer
Rick Hillegas wrote: Please vote on whether we should make Kim Haase a committer. The vote will close at 5:00 pm San Francisco time on Monday March 10. Kim has made an outstanding contribution to Derby's documentation effort. With commit privileges, she will be even more effective. Regards, -Rick +1 -jean
[jira] Commented: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes
[ https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577030#action_12577030 ] Knut Anders Hatlen commented on DERBY-2911: --- Improved some more comments in revision 635577. This should address 4c, 5a and 5b. Implement a buffer manager using java.util.concurrent classes - Key: DERBY-2911 URL: https://issues.apache.org/jira/browse/DERBY-2911 Project: Derby Issue Type: Improvement Components: Performance, Services Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, d2911-10.diff, d2911-10.stat, d2911-11.diff, d2911-2.diff, d2911-3.diff, d2911-4.diff, d2911-5.diff, d2911-6.diff, d2911-6.stat, d2911-7.diff, d2911-7a.diff, d2911-9.diff, d2911-9.stat, d2911-enable.diff, d2911-entry-javadoc.diff, d2911-unused.diff, d2911-unused.stat, d2911perf.java, derby-2911-8.diff, derby-2911-8.stat, perftest.diff, perftest.pdf, perftest.stat, perftest2.diff, perftest6.pdf, poisson_patch8.tar There are indications that the buffer manager is a bottleneck for some types of multi-user load. For instance, Anders Morken wrote this in a comment on DERBY-1704: With a separate table and index for each thread (to remove latch contention and lock waits from the equation) we (...) found that org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 times more contention than the synchronization in LockSet.lockObject() and LockSet.unlock(). That might be an indicator of where to apply the next push. It would be interesting to see the scalability and performance of a buffer manager which exploits the concurrency utilities added in Java SE 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (13 issues) Subscriber: derby-dev Key Summary DERBY-3503 Change stress.multi to dump thread stacks before killing off testers with jdk 1.5 and higher https://issues.apache.org/jira/browse/DERBY-3503 DERBY-3169 Add documentation for replication https://issues.apache.org/jira/browse/DERBY-3169 DERBY-3447 Shutdown on a database without stopping replication hangs https://issues.apache.org/jira/browse/DERBY-3447 DERBY-3491 Change SystemPermission to be a two arguement permission with a name (object the permission is on) and an action. https://issues.apache.org/jira/browse/DERBY-3491 DERBY-3448 Allow the MailJdbc system test to run under junit. https://issues.apache.org/jira/browse/DERBY-3448 DERBY-3460 SQL roles: patch to mask off roles on 10.4 release branch https://issues.apache.org/jira/browse/DERBY-3460 DERBY-3327 SQL roles: Implement authorization stack (and SQL session context to hold it) https://issues.apache.org/jira/browse/DERBY-3327 DERBY-2871 XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. https://issues.apache.org/jira/browse/DERBY-2871 DERBY-3409 Remove JDBC 2.0-specific topics from Reference Manual and merge implementation notes as needed https://issues.apache.org/jira/browse/DERBY-3409 DERBY-3379 No Current connection on PooledConnection.getConnection() if pooled connection is reused during connectionClosed processing https://issues.apache.org/jira/browse/DERBY-3379 DERBY-2954 Add commands to NetworkServerControl for interacting with the replication functionality https://issues.apache.org/jira/browse/DERBY-2954 DERBY-2953 Dump the information about rollbacks of the global transaction (introduced in DERBY-2220 and DERBY-2432) to derby.log https://issues.apache.org/jira/browse/DERBY-2953 DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
[jira] Updated: (DERBY-3517) testReplication_Local(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local)java.lang.StringIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/DERBY-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3517: -- tests on sun public posted nightly test results seeing same error, see - i believe these are jar runs so now don't think this error is specific to classes environments: http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/testlog/w2003/635283-suitesAll_diff.txt http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/testlog/vista/635283-suitesAll_diff.txt testReplication_Local(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local)java.lang.StringIndexOutOfBoundsException - Key: DERBY-3517 URL: https://issues.apache.org/jira/browse/DERBY-3517 Project: Derby Issue Type: Bug Components: Regression Test Failure, Replication Affects Versions: 10.4.0.0 Environment: windows XP, classes, SANE build, ibm15 jvm Reporter: Mike Matrigali I get the following junit errors while running against ibm15 jvm, SANE build, classes, built from clean version of trunk as of build 634891 .E.E.E.E.E.E Time: 2.734 There were 6 errors: 1) testReplication_Local(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local)java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1088) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.initEnvironment(ReplicationRun.java:1801) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) 2) testReplication_Local_StateTest_part1(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1)java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1088) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.initEnvironment(ReplicationRun.java:1801) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1.testReplication_Local_StateTest_part1(ReplicationRun_Local_StateTest_part1.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) 3) testReplication_Local_StateTest_part1_1(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1_1)java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1088) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.initEnvironment(ReplicationRun.java:1801) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1_1.testReplication_Local_StateTest_part1_1(ReplicationRun_Local_StateTest_part1_1.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) 4) testReplication_Local_StateTest_part1_2(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1_2)java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1088) at
[jira] Created: (DERBY-3519) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was
junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 --- Key: DERBY-3519 URL: https://issues.apache.org/jira/browse/DERBY-3519 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: Mike Matrigali see ibm15 trunk testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 8740, Failures: 2, Errors: 6 Also failed on j2me testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.1/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at
[jira] Commented: (DERBY-3458) dblook fails on TERRITORY_BASED databases
[ https://issues.apache.org/jira/browse/DERBY-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577056#action_12577056 ] Mamta A. Satoor commented on DERBY-3458: Migrated the changes into 10.3 codeline with revision 635588. dblook fails on TERRITORY_BASED databases - Key: DERBY-3458 URL: https://issues.apache.org/jira/browse/DERBY-3458 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.2.1 Reporter: Stephan van Loendersloot Assignee: Stephan van Loendersloot Priority: Minor Fix For: 10.4.0.0 Attachments: DERBY-3458_patch_1.stat, DERBY-3458_patch_1.txt, DERBY-3458_patch_2.stat, DERBY-3458_patch_2.txt, DERBY-3458_patch_3.stat, DERBY-3458_patch_3.txt, DERBY-3458_patch_3_function_tests.txt, DERBY-3458_patch_4.stat, DERBY-3458_patch_4.txt, DERBY-3458_patch_4_function_tests.txt I've created small patches for myself by replacing all related queries in the 'tools' section with CASTs to CHARs and VARCHARs and would like to contribute these to the community in case anyone else can confirm this is a bug. A small test case to reproduce the problem is provided below, the version of Derby that provides the stacktrace is 10.3.2.1. Regards, Stephan van Loendersloot. Reproduction steps: -- 1: create_territory_db.sql -- CONNECT 'jdbc:derby://localhost/dutch;user=dutch;password=dutch;create=true;territory=nl_NL;collation=TERRITORY_BASED'; AUTOCOMMIT OFF; CREATE TABLE AIRLINES ( AIRLINE CHAR(2) NOT NULL , AIRLINE_FULL VARCHAR(24), BASIC_RATE DOUBLE PRECISION, DISTANCE_DISCOUNT DOUBLE PRECISION, BUSINESS_LEVEL_FACTOR DOUBLE PRECISION, FIRSTCLASS_LEVEL_FACTOR DOUBLE PRECISION, ECONOMY_SEATS INTEGER, BUSINESS_SEATS INTEGER, FIRSTCLASS_SEATS INTEGER ); COMMIT; DISCONNECT; EXIT; -- 2: use dbloook -- dblook -d jdbc:derby://localhost/dutch;user=dutch;password=dutch -o dutch.sql -- 3: stacktrace -- java.sql.SQLSyntaxErrorException: Comparisons between 'CHAR (UCS_BASIC)' and 'CHAR (TERRITORY_BASED)' are not supported. Types must be comparable. String types must also have matching collation. If collation does not match, a possible solution is to cast operands to force them to the default collation (e.g. select tablename from sys.systables where CAST(tablename as VARCHAR(128)) = 'T1') at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.Statement.executeQuery(Unknown Source) at org.apache.derby.tools.dblook.prepForDump(Unknown Source) at org.apache.derby.tools.dblook.go(Unknown Source) at org.apache.derby.tools.dblook.init(Unknown Source) at org.apache.derby.tools.dblook.main(Unknown Source) Caused by: org.apache.derby.client.am.SqlException: Comparisons between 'CHAR (UCS_BASIC)' and 'CHAR (TERRITORY_BASED)' are not supported. Types must be comparable. String types must also have matching collation. If collation does not match, a possible solution is to cast operands to force them to the default collation (e.g. select tablename from sys.systables where CAST(tablename as VARCHAR(128)) = 'T1') at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown Source) at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown Source) at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.am.Statement.flowExecute(Unknown Source) at org.apache.derby.client.am.Statement.executeQueryX(Unknown Source) ... 5 more -- **-- DEBUG: Comparisons between 'CHAR (UCS_BASIC)' and 'CHAR (TERRITORY_BASED)' are not supported. Types must be comparable. String types must also have matching collation. If collation does not match, a possible solution is to cast operands to force them to the default collation (e.g. select tablename from sys.systables where CAST(tablename as VARCHAR(128)) = 'T1') -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3519) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was
[ https://issues.apache.org/jira/browse/DERBY-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3519: -- I am also seeing these failures consistently in a sane, classes run against ibm15 on a laptop. I saw it 9 out of 9 times running full suite in this environment. There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTe st)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertT imeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTi meValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testIne rtTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTe st)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertT imeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTi meValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testIne rtTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 --- Key: DERBY-3519 URL: https://issues.apache.org/jira/browse/DERBY-3519 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: Mike Matrigali see ibm15 trunk testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at
[jira] Commented: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result
[ https://issues.apache.org/jira/browse/DERBY-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577058#action_12577058 ] A B commented on DERBY-2351: modifySynonymResult.diff looks good to me. Might be nice if the whitespace inconsistencies could be patched up a bit, but functionally I think the patch is good. Two minor suggestions: 1) Could the logic in ColumnReference.columnNameMatches() use the new getSourceColumnName() method, instead of duplicating the instanceof ColumnReference check? 2) Do you think it would be worth it add some sanity queries for table aliasing, as well? Ex, I ran the following: -- All succeed. select distinct i a from t1 hmm order by i; select distinct i a from t1 hmm order by a; select distinct i a from t1 hmm order by hmm.i; -- All throw an error. select distinct i a from t1 hmm order by t1.i; select distinct i a from t1 hmm order by t1.a; select distinct i a from t1 hmm order by hmm.a; From what I can tell treatment of all of the above queries is correct, so this would just be a matter of adding them to the test script. That could come as a separate patch, though. Thanks for your persistence on this one, Bryan! ORDER BY with expression with distinct in the select list returns incorrect result -- Key: DERBY-2351 URL: https://issues.apache.org/jira/browse/DERBY-2351 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4 Environment: Any Reporter: Yip Ng Assignee: Bryan Pendleton Fix For: 10.3.2.2, 10.4.0.0 Attachments: d2351_aliasing.diff, d2351_aliasing.diff, d2351_aliasing_checkQualifiedName.diff, derby_2351.diff, derby_2351_v2.diff, modifySynonymResults.diff, reproTests.diff When distinct is in the select list and the query has order by with expression, the resultset produced contains an additional column. ij create table t1 (c1 int, c2 varchar(10)) 0 rows inserted/updated/deleted ij insert into t1 values (1,'a'),(2,'b'),(3,'c'); 3 rows inserted/updated/deleted select distinct c1, c2 from t1 order by c1; C1 |C2 -- 1 |a 2 |b 3 |c 3 rows selected ij select distinct c1, c2 from t1 order by c1+1; C1 |C2|3 =returns 3 columns, incorrect result returned -- 1 |a |2 2 |b |3 3 |c |4 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Junit hang
I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in 2) random theories which may occur to you This is how I run the full suite: java -Xmx600m -DderbyTesting.oldReleasePath=/Users/rh161140/derby/upgradeReleases junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All Thanks, -Rick
[jira] Commented: (DERBY-3519) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but w
[ https://issues.apache.org/jira/browse/DERBY-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577063#action_12577063 ] Daniel John Debrunner commented on DERBY-3519: -- I saw this on runs over the weekend but it seemed to only occur on Sunday, maybe related to the daylight savings change on Sunday in the US? junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 --- Key: DERBY-3519 URL: https://issues.apache.org/jira/browse/DERBY-3519 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0, 10.5.0.0 Reporter: Mike Matrigali see ibm15 trunk testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 8740, Failures: 2, Errors: 6 Also failed on j2me testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.1/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at
[jira] Commented: (DERBY-3515) 23 timeouts encountered while running management junit suite as part of full nightly runs.
[ https://issues.apache.org/jira/browse/DERBY-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577064#action_12577064 ] Daniel John Debrunner commented on DERBY-3515: -- I ran several suites.All over the weekend with sane classes and never saw any of these jmx timeouts (with the committed 10second timeout for the network server start). 23 timeouts encountered while running management junit suite as part of full nightly runs. -- Key: DERBY-3515 URL: https://issues.apache.org/jira/browse/DERBY-3515 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: windows XP, laptop, ibm15 Reporter: Mike Matrigali Attachments: summary.out While running full nightly test suite on a classes,SANE build got 23 failures in management test suite as follows. Tried again in same codeline just running the management test suite and it worked 50 times in a row. Maybe issue is similar to DERBY-3514, where a previous test is leaving a bad state and now that timeout has been reduced again to where it was known to cause nightly test failures in some environments those issues are resurfacing. I am trying another full suite run to see if it reproduces in my environment, if others are seeing this issue, please add a comment. I will attach full log of errors, but here is the first few: There were 23 errors: 1) testDerbyRegisteredMBeansSimpleInfo(org.apache.derbyTesting.functionTests.tests.management.JMXTest)java.rmi.ConnectIOException: Exception creating connection to: 192.168.0.188; nested exception is: java.net.SocketException: Operation timed out: connect:could be due to invalid address at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:603) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:109) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:52) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2244) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:286) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263) at org.apache.derbyTesting.functionTests.tests.management.RemoteConnectionGetter.getMBeanServerConnection(RemoteConnectionGetter.java:49) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getMBeanServerConnection(MBeanTest.java:177) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getApplicationManagementMBean(MBeanTest.java:252) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.enableManagement(MBeanTest.java:201) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.setUp(MBeanTest.java:155) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: java.net.SocketException: Operation timed out: connect:could be due to invalid address at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:541) at java.net.Socket.connect(Socket.java:491) at java.net.Socket.init(Socket.java:399) at java.net.Socket.init(Socket.java:208) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:41) at
Re: Junit hang
Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in Use any test runner apart from the textui one, that one is really the most basic with little helpful information. The swingui one indicates which test is running and shows which have passed or failed so far. Similar for the junit runner in eclipse. Also now suites.All can be run using ant, via the junit-single target. I haven't tried the latter but running through ant retains a lot of information. 2) random theories which may occur to you This is how I run the full suite: java -Xmx600m -DderbyTesting.oldReleasePath=/Users/rh161140/derby/upgradeReleases junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All Dan.
Re: Junit hang
Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in 2) random theories which may occur to you This is how I run the full suite: java -Xmx600m -DderbyTesting.oldReleasePath=/Users/rh161140/derby/upgradeReleases junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All Hi Rick, have you tried running with -Dderby.tests.trace=true added to your commandline? Vemund
[jira] Commented: (DERBY-3519) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but w
[ https://issues.apache.org/jira/browse/DERBY-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577067#action_12577067 ] Mamta A. Satoor commented on DERBY-3519: I saw the same error on my 10.3 codeline yesterday and I agree with Dan, I think it may have been related to daylight savings change. junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 --- Key: DERBY-3519 URL: https://issues.apache.org/jira/browse/DERBY-3519 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.2.2, 10.4.0.0, 10.5.0.0 Reporter: Mike Matrigali see ibm15 trunk testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 8740, Failures: 2, Errors: 6 Also failed on j2me testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.1/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at
[jira] Updated: (DERBY-3519) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was
[ https://issues.apache.org/jira/browse/DERBY-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-3519: --- Affects Version/s: 10.3.2.2 junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 --- Key: DERBY-3519 URL: https://issues.apache.org/jira/browse/DERBY-3519 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.2.2, 10.4.0.0, 10.5.0.0 Reporter: Mike Matrigali see ibm15 trunk testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 8740, Failures: 2, Errors: 6 Also failed on j2me testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.1/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at
Re: Junit hang
Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in Hi Rick, A simple hack is to print something in BaseTestCase.runBare, somewhere before line 101. There is already some tracing code in there (but it doesn't trace the start of a test at the moment), and if you want to contribute the code you could possibly do so by attaching your changes to DERBY-2667. If you have the time and energy, you could also give your comments on the patch derby-2667-WriteExceptionsToFileAsTheyHappen.diff ;) regards, -- Kristian [ snip ]
Regression Test Report - Daily 635283 - Sun DBTG
[Auto-generated mail] *Daily* 635283/2008-03-09 18:01:04 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin NA NA NANA derbyall NA NA NANA suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 0274274 076.65% derbyall F:1,E:01046010459 0 1822.89% suitesAll solN+1 0274274 098.74% derbyall 01046010460 0 213.99% suitesAll sparc 0274274 066.86% derbyall 01046010460 0 392.35% suitesAll vista 0274274 094.42% derbyall UNKOWNUNKOWNUNKOWN UNKOWN 0.00% suitesAll w2003 NA NA NANA derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-635283.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/635283_bySig.html *Jvm: 1.5* lin NA NA NANA derbyall NA NA NANA suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 0275275 079.77% derbyall UNKOWNUNKOWNUNKOWN UNKOWN 0.00% suitesAll solN+1 0275275 090.23% derbyall NA NA NANA suitesAll sparc 0275275 067.72% derbyall NA NA NANA suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 0275275 075.55% derbyall F:0,E:676317625 0 266.33% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-635283.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/635283_bySig.html *Jvm: 1.4* lin NA NA NANA derbyall NA NA NANA suitesAll linN+1 NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol NA NA NANA derbyall NA NA NANA suitesAll solN+1 NA NA NANA derbyall NA NA NANA suitesAll sparc NA NA NANA derbyall NA NA NANA suitesAll vista 0272272 271.63% derbyall F:0,E:674797473 0 396.17% suitesAll w2003 NA NA NANA derbyall NA NA NANA suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-635283.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/635283_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/635283.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Re: Junit hang
Hi Rick, You probably already know how to run junit tests using swingui, but just in case, this is what I use $ java -Xmx1024m -cp '../../tools/java/junit.jar;../../classes' -DderbyTesting.oldReleasePath=C:/p4clients/jars junit.swingui.TestRunner -noloading thanks, Mamta On 3/10/08, Daniel John Debrunner [EMAIL PROTECTED] wrote: Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in Use any test runner apart from the textui one, that one is really the most basic with little helpful information. The swingui one indicates which test is running and shows which have passed or failed so far. Similar for the junit runner in eclipse. Also now suites.All can be run using ant, via the junit-single target. I haven't tried the latter but running through ant retains a lot of information. 2) random theories which may occur to you This is how I run the full suite: java -Xmx600m -DderbyTesting.oldReleasePath=/Users/rh161140/derby/upgradeReleases junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All Dan.
Re: Junit hang
Daniel John Debrunner wrote: Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in Use any test runner apart from the textui one, that one is really the most basic with little helpful information. The swingui one indicates which test is running and shows which have passed or failed so far. Similar for the junit runner in eclipse. Also now suites.All can be run using ant, via the junit-single target. I haven't tried the latter but running through ant retains a lot of information. 2) random theories which may occur to you This is how I run the full suite: java -Xmx600m -DderbyTesting.oldReleasePath=/Users/rh161140/derby/upgradeReleases junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All Dan. Thanks Dan and Vemund for the quick response. Regards, -Rick
[jira] Issue Comment Edited: (DERBY-3519) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expecte
[ https://issues.apache.org/jira/browse/DERBY-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577067#action_12577067 ] mamtas edited comment on DERBY-3519 at 3/10/08 9:56 AM: - I saw the same error on my 10.3 codeline yesterday and I agree with Dan, I think it may have been related to daylight savings change(although I haven't run the test today to verify that). was (Author: mamtas): I saw the same error on my 10.3 codeline yesterday and I agree with Dan, I think it may have been related to daylight savings change. junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 --- Key: DERBY-3519 URL: https://issues.apache.org/jira/browse/DERBY-3519 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.2.2, 10.4.0.0, 10.5.0.0 Reporter: Mike Matrigali see ibm15 trunk testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 8740, Failures: 2, Errors: 6 Also failed on j2me testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.1/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at
Re: Junit hang
Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. A little more complex than the other suggestions, but approach would be to install NetBeans 6.0 on your system, and add the source directory for Derby as a new project with an existing Ant build file. Don't worry, you're not going to be changing anything in this directory from NetBeans; doing this just allows NetBeans to resolve stacktraces later on. Then do what you need to do to make the JUnit JVM start with the following switches: -Xrunjdwp:transport=dt_socket,address=,server=y,suspend=n -Xdebug -Xnoagent -Djava.compiler=NONE can be any available port 1024. When you get the hang, open NetBeans, choose Attach Debugger, and give a host of localhost and the port you specified above. Once it attaches, click Pause. You should then be able to select threads (double-click) and open the Call Stack and Local Variable Debugging windows to see where you are.
[jira] Commented: (DERBY-3503) Change stress.multi to dump thread stacks before killing off testers with jdk 1.5 and higher
[ https://issues.apache.org/jira/browse/DERBY-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577072#action_12577072 ] Kathey Marsden commented on DERBY-3503: --- Knut said ... don't think I would have bothered unwrapping the PrivilegedActionException and the InvocationTargetException, as the original exception is in the chain and its stack trace is printed anyway. Not a big deal, but it would perhaps make the code a bit cleaner. hmmm the reason I was unwrapping it was because I was not seeing the chained exception print. It would be hard to reproduce now. Maybe that was with jdk 1.4.2, but anyway I think I will leave it as is. Thanks Knut for the review. Change stress.multi to dump thread stacks before killing off testers with jdk 1.5 and higher Key: DERBY-3503 URL: https://issues.apache.org/jira/browse/DERBY-3503 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Attachments: derby-3503_diff.txt, derby-3503_diff.txt Jdk 1.5 introduced Thread.getAllStackTraces() which can be used to print a thread dump programatically. The test stress.multi kills off its testers if it reaches a deadlock or the testers can't complete on their own. It would be helpful in this case to get a thread dump automatically. The code could only be enabled for jdk 1.5 and higher. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Problem with addSuiteByReflection() on phoneME advanced platform
The past few days it has not been possible to run suites.All on phoneME
advanced, junit will just exit with an InvocationTargetException when
trying to invoke the suites.All.suite() method. Unwrapping the exception
shows that the underlying reason is a NoClassDefFoundError from the
invoke() call in AllPackages.addSuiteByReflection() when trying to load
the new JMX suite.
Now, this suite is compiled into 1.5 classfiles, so the Class.forName()
call before the invoke() should have failed with
UnsupportedClassVersionError. It does fail as expected when running with
jdk 1.4, but on phoneME advanced it does not, I think it has to be a bug
in phoneME advanced.
Now, I was pondering if it would make sense to also catch
InvocationTargetException from the try block below, unwrap it and see if
it is an instance of LinkageError and if so skip the testsuite. This
would make it possible to run the tests on phoneME advanced, despite the
bug. Any reason why this would be a bad idea?
private static Test addSuiteByReflection(String className) throws Exception
{
try {
Class clz = Class.forName(className);
Method sm = clz.getMethod(suite, null);
return (Test) sm.invoke(null, null);
} catch (LinkageError e) {
return new TestSuite(SKIPPED: + className + - +
e.getMessage());
}
}
Re: {VOTE] Kim Haase as a committer
+1 Manjula On 3/3/08, Rick Hillegas [EMAIL PROTECTED] wrote: Rick Hillegas wrote: Please vote on whether we should make Kim Haase a committer. The vote will close at 5:00 pm San Francisco time on Monday March 10. Kim has made an outstanding contribution to Derby's documentation effort. With commit privileges, she will be even more effective. Regards, -Rick +1 -- Thanks, Manjula.
[jira] Commented: (DERBY-3517) testReplication_Local(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local)java.lang.StringIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/DERBY-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577104#action_12577104 ] Øystein Grøvlen commented on DERBY-3517: I have committed a patch (see DERBY-3162) that disables ReplicationSuite.suite() in suites.All for now. testReplication_Local(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local)java.lang.StringIndexOutOfBoundsException - Key: DERBY-3517 URL: https://issues.apache.org/jira/browse/DERBY-3517 Project: Derby Issue Type: Bug Components: Regression Test Failure, Replication Affects Versions: 10.4.0.0 Environment: windows XP, classes, SANE build, ibm15 jvm Reporter: Mike Matrigali I get the following junit errors while running against ibm15 jvm, SANE build, classes, built from clean version of trunk as of build 634891 .E.E.E.E.E.E Time: 2.734 There were 6 errors: 1) testReplication_Local(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local)java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1088) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.initEnvironment(ReplicationRun.java:1801) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) 2) testReplication_Local_StateTest_part1(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1)java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1088) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.initEnvironment(ReplicationRun.java:1801) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1.testReplication_Local_StateTest_part1(ReplicationRun_Local_StateTest_part1.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) 3) testReplication_Local_StateTest_part1_1(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1_1)java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1088) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.initEnvironment(ReplicationRun.java:1801) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1_1.testReplication_Local_StateTest_part1_1(ReplicationRun_Local_StateTest_part1_1.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) 4) testReplication_Local_StateTest_part1_2(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1_2)java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1088) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.initEnvironment(ReplicationRun.java:1801) at
[jira] Closed: (DERBY-3503) Change stress.multi to dump thread stacks before killing off testers with jdk 1.5 and higher
[ https://issues.apache.org/jira/browse/DERBY-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3503. - Resolution: Fixed Fix Version/s: 10.5.0.0 Committed revision 635625. Change stress.multi to dump thread stacks before killing off testers with jdk 1.5 and higher Key: DERBY-3503 URL: https://issues.apache.org/jira/browse/DERBY-3503 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Fix For: 10.5.0.0 Attachments: derby-3503_diff.txt, derby-3503_diff.txt Jdk 1.5 introduced Thread.getAllStackTraces() which can be used to print a thread dump programatically. The test stress.multi kills off its testers if it reaches a deadlock or the testers can't complete on their own. It would be helpful in this case to get a thread dump automatically. The code could only be enabled for jdk 1.5 and higher. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Junit hang
Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. Have you verified that you are not seeing the same timeout problem related to the new JMX test which Mike mentioned? Dyre
Re: Junit hang
Dyre Tjeldvoll wrote: Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. Have you verified that you are not seeing the same timeout problem related to the new JMX test which Mike mentioned? Note, that in the case I was seeing the full suite did finish, producing the errors I reported. I was running the test overnight so didn't really pay attention to how long it was taking. Dyre
[jira] Resolved: (DERBY-1626) TransactionTable.sql fails
[ https://issues.apache.org/jira/browse/DERBY-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali resolved DERBY-1626. --- Resolution: Fixed Fix Version/s: 10.4.0.0 10.3.2.2 applied fix to trunk and merged to 10.3 branch. TransactionTable.sql fails -- Key: DERBY-1626 URL: https://issues.apache.org/jira/browse/DERBY-1626 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.2.1.6 Environment: linux jdk1.4 Reporter: Rick Hillegas Assignee: Mike Matrigali Fix For: 10.3.2.2, 10.4.0.0 TransactionTable fails with the following diff: 226a227 NULL |SystemTransaction |IDLE|readonly|NULL Test Failed. *** End: TransactionTable jdk1.4.2_08 2006-08-01 12:47:35 *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Junit hang
Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in 2) random theories which may occur to you Posting the test fixture as a patch would allow others to see if there are any possible issues with it. Dan.
Re: Preparing to cut the 10.4 branch
[EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre
Re: {VOTE] Kim Haase as a committer
Rick Hillegas wrote: Please vote on whether we should make Kim Haase a committer. The vote will close at 5:00 pm San Francisco time on Monday March 10. Kim has made an outstanding contribution to Derby's documentation effort. With commit privileges, she will be even more effective. +1 Dan.
[jira] Created: (DERBY-3520) convert views.sql to junit
convert views.sql to junit -- Key: DERBY-3520 URL: https://issues.apache.org/jira/browse/DERBY-3520 Project: Derby Issue Type: Task Components: Test Affects Versions: 10.5.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor With the latest IBM 1.6 jvm I am seeing an ordering diff in the errors in drop table with views.sql so it would be good to convert to junit to avoid having separate jvm masters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3322) Server guide refers to phantom property in template policy file for the Network Server
[
https://issues.apache.org/jira/browse/DERBY-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577130#action_12577130
]
Dyre Tjeldvoll commented on DERBY-3322:
---
I can see the diff in the doc tree, but I cannot see the change in the link
that you mention. Should it be updated automatically or is some kind of manual
intervention required?
Server guide refers to phantom property in template policy file for the
Network Server
--
Key: DERBY-3322
URL: https://issues.apache.org/jira/browse/DERBY-3322
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.3.1.4, 10.3.2.1
Environment: N/A
Reporter: John H. Embretsen
Assignee: John H. Embretsen
Priority: Trivial
Fix For: 10.4.0.0
Attachments: d3322v01.diff, tadminnetservcustom.html
The Server and Administration guide contains a section about customizing the
Network Server's security policy, based on the template policy:
http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html
This section mentions that the variable ${derby.security.host} should be
replaced with a suitable value.
However, the template policy, at /demo/templates/server.policy (released
binaries) or java/drda/org/apache/derby/drda/template.policy (SVN codeline),
does not refer to any variable or property called ${derby.security.host}.
Instead, the policy file specifies the wildcard address, with appropriate
comments:
quote
// Accept connections from any host. Derby is listening to the host
// interface specified via the -h option to NetworkServerControl
// start on the command line, via the address parameter to the
// org.apache.derby.drda.NetworkServerControl constructor in the API
// or via the property derby.drda.host; the default is localhost.
// You may want to restrict allowed hosts, e.g. to hosts in a specific
// subdomain, e.g. *.acme.com.
permission java.net.SocketPermission *, accept;
/quote
See also
http://www.nabble.com/Customizing-the-Network-Server%27s-security-policy-%28docs-vs.-reality%29-td14841290.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577136#action_12577136 ] Mamta A. Satoor commented on DERBY-3320: Currently, I am thinking of concentrating only on making sure that Collator can be instantiated for the locale on a give JVM when a user is trying to create/boot a database with territory based collation. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Preparing to cut the 10.4 branch
On 3/10/08, Dyre Tjeldvoll [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre re master files: I removed the need for updating master files with DERBY-3088. Myrna
[jira] Resolved: (DERBY-3362) ControlRow NPE
[ https://issues.apache.org/jira/browse/DERBY-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali resolved DERBY-3362. --- Resolution: Fixed Fix Version/s: 10.3.2.2 fixed in trunk and backported to 10.3 branch. ControlRow NPE -- Key: DERBY-3362 URL: https://issues.apache.org/jira/browse/DERBY-3362 Project: Derby Issue Type: Bug Affects Versions: 10.3.2.1, 10.4.0.0 Reporter: James Alan Shepherd Assignee: Mike Matrigali Fix For: 10.3.2.2, 10.4.0.0 Attachments: b3362.diff, derbylog.zip I have a NPE in Derby 10.3.2.1 (10.3.1.4 does not show this behaviour) that is probably the same one discussed in DERBY-3216 FATAL 38406 [Main] (Start.java:153) - Start FAILED org.springframework.transaction.TransactionSystemException: Could not commit JDBC transaction; nested exception is java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:238) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199) at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:245) at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:651) at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:621) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:146) at com.aaa.bbb.cccFactory$ddd.add(cccFactory.java:324) at com.aaa.eee.fff.ggg.reload(ggg.java:44) at com.aaa.eee.fff.ggg.startup(ggg.java:57) at com.aaa.eee.fff.Start.startupEee(Start.java:170) at com.aaa.eee.fff.Start.startup(Start.java:146) at com.aaa.start.Starter.startup(Starter.java:264) at com.aaa.start.Main.startup(Main.java:270) at com.aaa.start.Main.main(Main.java:199) Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 21 more Caused by: java.lang.NullPointerException at org.apache.derby.impl.store.access.btree.ControlRow.getControlRowForPage(Unknown Source) at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source) at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.postTermination(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(Unknown Source) ... 15 more and derby.log: 2008-01-28 08:26:36.148 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), (DATABASE = directory:myDB), (DRDAID = null), Executing prepared statement: SELECT COUNT(*) FROM ZZZ WHERE nID IS NULL :End prepared statement 2008-01-28 08:26:36.150 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), (DATABASE = directory:myDB), (DRDAID = null), Committing 2008-01-28 08:26:36.188 GMT
Re: Junit hang
Daniel John Debrunner wrote: Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in 2) random theories which may occur to you Posting the test fixture as a patch would allow others to see if there are any possible issues with it. Dan. Thanks, Dan. It's the latest code patch on DERBY-3341: derby-3341-01-da-coerceWithTests.diff. Regards, -Rick
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577151#action_12577151 ] Mamta A. Satoor commented on DERBY-3320: Also, I am considering throwing an exception if the exact locale is not found. If anyone has any comments on this proposed behavior, please add a comment to this jira entry. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problem with addSuiteByReflection() on phoneME advanced platform
Vemund Ostgaard [EMAIL PROTECTED] writes: The past few days it has not been possible to run suites.All on phoneME advanced, junit will just exit with an InvocationTargetException when trying to invoke the suites.All.suite() method. Unwrapping the exception shows that the underlying reason is a NoClassDefFoundError from the invoke() call in AllPackages.addSuiteByReflection() when trying to load the new JMX suite. Now, this suite is compiled into 1.5 classfiles, so the Class.forName() call before the invoke() should have failed with UnsupportedClassVersionError. It does fail as expected when running with jdk 1.4, but on phoneME advanced it does not, I think it has to be a bug in phoneME advanced. Not sure if it's a bug in phoneME. It sounds like the VM is able to read the class file format of Java 1.5 and the class library is based on Java 1.4. Perhaps an odd combination, but not necessarily wrong. Now, I was pondering if it would make sense to also catch InvocationTargetException from the try block below, unwrap it and see if it is an instance of LinkageError and if so skip the testsuite. This would make it possible to run the tests on phoneME advanced, despite the bug. Any reason why this would be a bad idea? Sounds like a good idea to me. -- Knut Anders
Re: Junit hang
Dyre Tjeldvoll wrote: Rick Hillegas wrote: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. Have you verified that you are not seeing the same timeout problem related to the new JMX test which Mike mentioned? Dyre Thanks, yes, I'm confident it's not that issue. In my sandbox I removed the extra test case (retaining the changes to the engine itself) and ran the junit tests successfully. In the meantime, I have run the suite under the swing runner. I see that I'm getting an out of memory error in the replication tests. That puzzles me because I boosted the memory which I gave to the tests to start out with. Regards, -Rick
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577157#action_12577157 ] Knut Anders Hatlen commented on DERBY-3320: --- Wasn't the problem that if a locale wasn't supported, the Collator would be instantiated anyway and silently use en_US? If that was the problem, I don't think checking that the Collator can be instantiated will help. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Preparing to cut the 10.4 branch
Dyre Tjeldvoll wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre Hi Dyre, When you run sysinfo on the branch, what version number does it report? Thanks, -Rick
Re: Junit hang
Rick Hillegas [EMAIL PROTECTED] writes: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in A thread dump could possibly help, and it would show if there are any Java level deadlocks. Either do a kill -QUIT on the Java process, or use the jstack utility bundled with the JDK (I'm assuming that you're still using JDK 1.5 on Mac?). 2) random theories which may occur to you stress.multi hung in many runs last week because of a deadlock between TableDescriptorOIDCache and TableDescriptorNameCache. Should be fixed now, though. A thread dump would tell whether that's the problem. -- Knut Anders
Re: Preparing to cut the 10.4 branch
Myrna van Lunteren wrote: On 3/10/08, Dyre Tjeldvoll [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre re master files: I removed the need for updating master files with DERBY-3088. Thanks. I'll update the Wiki to reflect this. Dyre
Re: Preparing to cut the 10.4 branch
Rick Hillegas wrote: Dyre Tjeldvoll wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre Hi Dyre, When you run sysinfo on the branch, what version number does it report? Thanks, -Rick 10.4.0.1 I believe... Dyre
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577171#action_12577171 ] Mamta A. Satoor commented on DERBY-3320: Sorry for the brief comment making sure that Collator can be instantiated for the locale on a give JVM . Let me elaborate on what I am thinking of doing. Collator class has a method called getAvailableLocales which returns an array of locales which are the union of locales supported by the Java runtime and by installed CollatorProvider(a subclass of LocaleServiceProvider) implementations. Locale class also has a method called getAvailableLocales which returns an array of locales which are the union of locales supported by the Java runtime and by installed LocaleServiceProvider implementations. So, it appears that the locale arrary returned from Collator.getAvailableLocales will be a subset of locale array returned by Locale.getAvailableLocales What I was thinking of doing was adding a new method (don't know in which class at this point) which will go through the arrary returned by Collator.getAvailableLocales and see if the locale requested by the user is included in the locale arrary. If not, then throw an exception. I was planning on calling this method when I find at database create/boot time that user has asked for territory based collation. After thinking more about it, I think it will be better for us to make the new method more generic by going through Locale.getAvailableLocales rather than the Collator.getAvailableLocales. And then seee if the locale requested by the user is inclueded in the locale array. Making the method generic this way will enable us to use it for other Derby functionality that uses the database locale (some of this functionality has been identified by Dan in his earlier comment to this jira entry). Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577186#action_12577186 ] Knut Anders Hatlen commented on DERBY-3320: --- Thanks, that makes sense. After thinking more about it, I think it will be better for us to make the new method more generic by going through Locale.getAvailableLocales rather than the Collator.getAvailableLocales. What if Locale.getAvailableLocales() says that a locale is available and Collator.getAvailableLocales() says that we don't have collators for that locale? If we only look at Locale.getAvailableLocales(), won't we incorrectly conclude that we support collation for that locale and create an en_US Collator? Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3520) convert views.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3520: -- Derby Info: [Patch Available] derby-3520_diff.txt patch available convert views.sql to junit -- Key: DERBY-3520 URL: https://issues.apache.org/jira/browse/DERBY-3520 Project: Derby Issue Type: Task Components: Test Affects Versions: 10.5.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Attachments: derby-3520_diff.txt With the latest IBM 1.6 jvm I am seeing an ordering diff in the errors in drop table with views.sql so it would be good to convert to junit to avoid having separate jvm masters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3520) convert views.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3520: -- Attachment: derby-3520_diff.txt Attached is a patch for this issue. I used the SQLToJUnit program to do most of the conversion. I Addded a new method to BaseJDBCTestCase public static void assertStatementError(String[] sqlStates, Statement st, String query) to allow for checking of multiple SQLStates. I am running suites.All now. convert views.sql to junit -- Key: DERBY-3520 URL: https://issues.apache.org/jira/browse/DERBY-3520 Project: Derby Issue Type: Task Components: Test Affects Versions: 10.5.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Attachments: derby-3520_diff.txt With the latest IBM 1.6 jvm I am seeing an ordering diff in the errors in drop table with views.sql so it would be good to convert to junit to avoid having separate jvm masters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3520) convert views.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3520: -- Attachment: derby-3520_diff.txt updated patch. forgot to delete views.sql and views.out convert views.sql to junit -- Key: DERBY-3520 URL: https://issues.apache.org/jira/browse/DERBY-3520 Project: Derby Issue Type: Task Components: Test Affects Versions: 10.5.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Attachments: derby-3520_diff.txt, derby-3520_diff.txt With the latest IBM 1.6 jvm I am seeing an ordering diff in the errors in drop table with views.sql so it would be good to convert to junit to avoid having separate jvm masters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Preparing to cut the 10.4 branch
Dyre Tjeldvoll wrote: Rick Hillegas wrote: Dyre Tjeldvoll wrote: [EMAIL PROTECTED] wrote: The update of the maint property on the 10.4 branch will hopefully happen soon... There... r635654 | dyre | 2008-03-10 20:03:13 +0100 (Mon, 10 Mar 2008) | 2 lines Updating the maint property on the 10.4 branch I ran the tests successfully (on the 10.4 branch), but I did not modify the beta flag. Should I? And do I still need to update the master files if/when I do that? Dyre Hi Dyre, When you run sysinfo on the branch, what version number does it report? Thanks, -Rick 10.4.0.1 I believe... Dyre Hi Dyre, When I run sysinfo against the branch, it reports that the version id is 10.4.0.1 alpha - (635685). It think that you need to modify the 3rd digit in the release id. I believe that is the secret handshake which turns an alpha into a beta. Regards, -Rick
Re: Preparing to cut the 10.4 branch
Rick Hillegas wrote: When I run sysinfo against the branch, it reports that the version id is 10.4.0.1 alpha - (635685). It think that you need to modify the 3rd digit in the release id. I believe that is the secret handshake which turns an alpha into a beta. The secret handshake is documented here: http://db.apache.org/derby/papers/versionupgrade.html Dan.
[jira] Updated: (DERBY-3519) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was
[ https://issues.apache.org/jira/browse/DERBY-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3519: -- Priority: Trivial (was: Major) I have verified that test no longer fails on the Monday after daylight savings time change. Lowering priority. junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 --- Key: DERBY-3519 URL: https://issues.apache.org/jira/browse/DERBY-3519 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.2.2, 10.4.0.0, 10.5.0.0 Reporter: Mike Matrigali Priority: Trivial see ibm15 trunk testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 8740, Failures: 2, Errors: 6 Also failed on j2me testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.1/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577221#action_12577221 ] Daniel John Debrunner commented on DERBY-3320: -- Mamta see if the locale requested by the user is included in the locale arrary What does that mean, especially with regards to this comment: Vemund Something to consider is also whether you need an exact match to consider a locale supported for the purpose of the Collator, or if it is enough to get a language match? For instance, if looking for en_GB, is en_US good enough? Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2861) Thread safety issue in TableDescriptor
[ https://issues.apache.org/jira/browse/DERBY-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577233#action_12577233 ] Kathey Marsden commented on DERBY-2861: --- I can't seem to reproduce this on trunk or latest on 10.3. I get only lock timeouts. e.g. java.sql.SQLException: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:201) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2082) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1325) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:625) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555) at TestEmbeddedMultiThreading.executeStatement(TestEmbeddedMultiThreading.java:124) at TestEmbeddedMultiThreading.access$100(TestEmbeddedMultiThreading.java:25) at TestEmbeddedMultiThreading$ViewCreatorDropper.run(TestEmbeddedMultiThreading.java:189) at java.lang.Thread.run(Thread.java:803) Caused by: ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276) at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(ConcurrentLockSet.java:602) at org.apache.derby.impl.services.locks.AbstractPool.lockObject(AbstractPool.java:117) at org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(ConcurrentPool.java:28) at org.apache.derby.impl.store.raw.xact.RowLocking2.lockRecordForRead(RowLocking2.java:165) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScan(B2IRowLocking3.java:127) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockScan(B2IRowLocking3.java:739) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:662) at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:112) at org.apache.derby.impl.store.access.btree.BTreeScan.positionAtStartForForwardScan(BTreeScan.java:436) at org.apache.derby.impl.store.access.btree.BTreeForwardScan.positionAtStartPosition(BTreeForwardScan.java:71) at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:123) at org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java:1756) at org.apache.derby.impl.sql.execute.IndexChanger.doDelete(IndexChanger.java:335) at org.apache.derby.impl.sql.execute.IndexChanger.delete(IndexChanger.java:544) at org.apache.derby.impl.sql.execute.IndexSetChanger.delete(IndexSetChanger.java:250) at org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(RowChangerImpl.java:476) at org.apache.derby.impl.sql.catalog.TabInfoImpl.deleteRows(TabInfoImpl.java:750) at org.apache.derby.impl.sql.catalog.TabInfoImpl.deleteRow(TabInfoImpl.java:581) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.dropColumnDescriptorCore(DataDictionaryImpl.java:2950) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.dropAllColumnDescriptors(DataDictionaryImpl.java:2452) at org.apache.derby.iapi.sql.dictionary.ViewDescriptor.drop(ViewDescriptor.java:411) at org.apache.derby.impl.sql.execute.DropViewConstantAction.executeConstantAction(DropViewConstantAction.java:13 4) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:64) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:372) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235) ... 6 more Are the lock timeouts expected? Can anyone still reproduce this? Thread safety issue in TableDescriptor -- Key: DERBY-2861 URL: https://issues.apache.org/jira/browse/DERBY-2861 Project: Derby Issue Type: Bug Components: SQL Environment: Tested on a dual-core 3GHz Pentium machine running Windows Vista Business, using JDK 1.4.2_13 and Derby trunk revision 548822. Reporter: Jeff Clary Attachments: TestEmbeddedMultiThreading.java A NullPointerException
[jira] Commented: (DERBY-3448) Allow the MailJdbc system test to run under junit.
[ https://issues.apache.org/jira/browse/DERBY-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577234#action_12577234 ] Manjula Kutty commented on DERBY-3448: -- Can any one please review this patch? Allow the MailJdbc system test to run under junit. -- Key: DERBY-3448 URL: https://issues.apache.org/jira/browse/DERBY-3448 Project: Derby Issue Type: Improvement Components: Test Reporter: Daniel John Debrunner Assignee: Manjula Kutty Priority: Minor Attachments: DERBY-3448_diff.txt_02_26_ver2.txt, DERBY-3448_diff_02_26.txt, DERBY-3448_diff_02_27.txt, DERBY-3448_stat_02_26.txt, derby_3448_dbtasks_cleanup.txt It would be good to get the mailjdbc test to run under junit to allow use of the utilities there and decorators such as running the test getting all connections from a data source with a statement caching. Could still allow the test to run standalone in its current form -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[ https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577235#action_12577235 ] Daniel John Debrunner commented on DERBY-3320: -- Sorry missed earlier comment about exact match on locale. Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported Key: DERBY-3320 URL: https://issues.apache.org/jira/browse/DERBY-3320 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: Java ME: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 GNU/Linux Reporter: Vemund Østgaard Assignee: Mamta A. Satoor Attachments: DERBY_3320_Repro.java A problem I've discovered when testing with the phoneME advanced platform is that the collationtests expect other locales than Locale.US to be available on the platform that is used for the test, and for phoneME advanced (when compiled as foundation profile) only Locale.US is available. From the jdk1.6 javadoc of Collator.getAvailableLocales() I see that only Locale.US is strictly required: public static Locale[] getAvailableLocales() Returns an array of all locales for which the getInstance methods of this class can return localized instances. The returned array represents the union of locales supported by the Java runtime and by installed CollatorProvider implementations. It must contain at least a Locale instance equal to Locale.US. Returns: An array of locales for which localized Collator instances are available. This led me to thinking about how Derby should behave if created/booted with collation=TERRITORY_BASED and territory=some unsupported locale. I'm not sure what the consequences could be if the database is first created on a platform that supports whatever locale is set and later booted with one that doesn't, or created on a platform missing support and later booted with one that has. In any case I think it may confuse a user needlessly to see the database boot successfully with his collation setting and later behave in a way he does not expect. Opinions voiced on the derby-dev list are that both database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported. If a change like this is implemented, the collationtests should be changed to verify correct behavior also if they are executed in an environment were some of the tested locales are not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Reminder: Google Summer of code
Only a couple days left to post your Google Summer of Code projects. March 12 was the deadline given for project proposals. It's looking a little thin this year. Please add your projects to the Wiki at: http://wiki.apache.org/general/SummerOfCode2008 or add your name to derby-testandfix if you would like to support a student with bug fixing and test conversions. Kathey
[jira] Commented: (DERBY-3400) testgetTypeInfo Fails with ibm16 while running the UpgradeTests
[ https://issues.apache.org/jira/browse/DERBY-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577264#action_12577264 ] Kathey Marsden commented on DERBY-3400: --- Fixed with the following jvm version java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr1-20080309_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080308_17822 (JIT enabled, AOT enabled) J9VM - 20080308_017822_lHdSMr JIT - r9_20080307_1821 GC - 20080305_AB) JCL - 20080301_01 [C:/svn3/trunk] testgetTypeInfo Fails with ibm16 while running the UpgradeTests --- Key: DERBY-3400 URL: https://issues.apache.org/jira/browse/DERBY-3400 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Environment: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr1-20080108_02) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080102 _15870 (JIT enabled) J9VM - 20080102_015870_lHdSMr JIT - r9_20080101_1821 GC - 20071224_AA) JCL - 20071219_01 sysinfo - [C:/derbydev/trunk/test] java org.apache.derby.tools.sysinfo -- Java Information -- Java Version:1.6.0 Java Vendor: IBM Corporation Java home: c:\p4client\mkutty_main\ibm16\jre Java classpath: c:/derbydev/trunk/classes;c:/derbydev/trunk/tools/java/junit.ja r;. OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 2 Java user name: mkutty Java user home: C:\Documents and Settings\Administrator Java user dir: C:\derbydev\trunk\test java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [C:\derbydev\trunk\classes] 10.4.0.0 alpha - (1) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.4.0.0 alpha - (1) Found support for locale: [de_DE] version: 10.4.0.0 alpha - (1) Found support for locale: [es] version: 10.4.0.0 alpha - (1) Found support for locale: [fr] version: 10.4.0.0 alpha - (1) Found support for locale: [hu] version: 10.4.0.0 alpha - (1) Found support for locale: [it] version: 10.4.0.0 alpha - (1) Found support for locale: [ja_JP] version: 10.4.0.0 alpha - (1) Found support for locale: [ko_KR] version: 10.4.0.0 alpha - (1) Found support for locale: [pl] version: 10.4.0.0 alpha - (1) Found support for locale: [pt_BR] version: 10.4.0.0 alpha - (1) Found support for locale: [ru] version: 10.4.0.0 alpha - (1) Found support for locale: [zh_CN] version: 10.4.0.0 alpha - (1) Found support for locale: [zh_TW] version: 10.4.0.0 alpha - (1) -- Reporter: Manjula Kutty Assignee: Kathey Marsden Fix For: 10.4.0.0 Attachments: derby-3400_diff.txt, TestDerby3400.java I can reproduce the test with the just one old version(10.2.2.0) Here is the junit stack trace 1) testGetTypeInfo(org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest)junit.framework.AssertionFailedError: Column nullability do not match for column 16 expected:1 but was:0 at org.apache.derbyTesting.junit.JDBC.assertNullability(JDBC.java:741) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.assertMetaDataResultSet(DatabaseMetaDataTest.java:2348) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetTypeInfo(DatabaseMetaDataTest.java:2230) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at
Re: Junit hang
Knut Anders Hatlen wrote: Rick Hillegas [EMAIL PROTECTED] writes: I would appreciate people's advice about how to track down a hang in the Junit tests. I have added a new test case to TableFunctionTest. When I execute the test standalone, it runs fine. When I execute the surrounding suite, everything succeeds also. However, when I run the full set of junit tests, the run hangs in a later suite. I tried increasing the memory given to the testrun, but this does not fix the problem. I would appreciate: 1) advice about how to instrument the test run so that I know which test case I'm hanging in A thread dump could possibly help, and it would show if there are any Java level deadlocks. Either do a kill -QUIT on the Java process, or use the jstack utility bundled with the JDK (I'm assuming that you're still using JDK 1.5 on Mac?). 2) random theories which may occur to you stress.multi hung in many runs last week because of a deadlock between TableDescriptorOIDCache and TableDescriptorNameCache. Should be fixed now, though. A thread dump would tell whether that's the problem. Thanks, Knut. Increasing the max PermGen size got the tests past the out-of-memory-error. They then hung on test case 8515 out of 8520, in org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1. I interrupted the tests with kill -quit as you recommended. I'm attaching the console output. Regards, -Rick runswingjunittests is a script which sets up the classpath and then runs the swing runner with this command: java -Xmx512m -XX:MaxPermSize=128M -DderbyTesting.oldReleasePath=/Users/rh161140/derby/upgradeReleases junit.swingui.TestRunner -noloadin (Without the -XX:MaxPermSize switch, the tests would stop with an out-of-memory error, running out of PermGen space.) Once the swing runner is brought up, I run the master script: org.apache.derbyTesting.functionTests.suites.All Here's the console output: mainline (1.5) runswingjunittests Mon Mar 10 14:48:56 PDT 2008 Deleting old test run... Old test run deleted. Mon Mar 10 14:48:56 PDT 2008 sanity is sane java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC: Cannot start replication slave mode for database '/Users/rh161140/derby/mainline/testRun/db_slave/wombat'. The database has already been booted. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) at java.sql.DriverManager.getConnection(DriverManager.java:525) at java.sql.DriverManager.getConnection(DriverManager.java:193) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun$1.run(ReplicationRun.java:1008) at java.lang.Thread.run(Thread.java:613) Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC: Cannot start replication slave mode for database '/Users/rh161140/derby/mainline/testRun/db_slave/wombat'. The database has already been booted. at org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2090) at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:430) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:294) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:121) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:887) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:811) at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(NetConnection.java:644) at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:451) at org.apache.derby.client.net.NetConnection.init(NetConnection.java:219) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(ClientJDBCObjectFactoryImpl.java:270) at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:140) ... 4 more java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the database is not in replication master mode. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149) at java.sql.DriverManager.getConnection(DriverManager.java:525) at
[jira] Commented: (DERBY-3515) 23 timeouts encountered while running management junit suite as part of full nightly runs.
[ https://issues.apache.org/jira/browse/DERBY-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577298#action_12577298 ] Daniel John Debrunner commented on DERBY-3515: -- If you still are seeing failures it would be good to know if it's the first JMX related test that is failing or a subsequent one. 23 timeouts encountered while running management junit suite as part of full nightly runs. -- Key: DERBY-3515 URL: https://issues.apache.org/jira/browse/DERBY-3515 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: windows XP, laptop, ibm15 Reporter: Mike Matrigali Attachments: summary.out While running full nightly test suite on a classes,SANE build got 23 failures in management test suite as follows. Tried again in same codeline just running the management test suite and it worked 50 times in a row. Maybe issue is similar to DERBY-3514, where a previous test is leaving a bad state and now that timeout has been reduced again to where it was known to cause nightly test failures in some environments those issues are resurfacing. I am trying another full suite run to see if it reproduces in my environment, if others are seeing this issue, please add a comment. I will attach full log of errors, but here is the first few: There were 23 errors: 1) testDerbyRegisteredMBeansSimpleInfo(org.apache.derbyTesting.functionTests.tests.management.JMXTest)java.rmi.ConnectIOException: Exception creating connection to: 192.168.0.188; nested exception is: java.net.SocketException: Operation timed out: connect:could be due to invalid address at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:603) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:109) at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:52) at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2244) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:286) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:263) at org.apache.derbyTesting.functionTests.tests.management.RemoteConnectionGetter.getMBeanServerConnection(RemoteConnectionGetter.java:49) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getMBeanServerConnection(MBeanTest.java:177) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getApplicationManagementMBean(MBeanTest.java:252) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.enableManagement(MBeanTest.java:201) at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.setUp(MBeanTest.java:155) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: java.net.SocketException: Operation timed out: connect:could be due to invalid address at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:541) at java.net.Socket.connect(Socket.java:491) at java.net.Socket.init(Socket.java:399) at java.net.Socket.init(Socket.java:208) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:41) at
[jira] Commented: (DERBY-3322) Server guide refers to phantom property in template policy file for the Network Server
[
https://issues.apache.org/jira/browse/DERBY-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577308#action_12577308
]
Andrew McIntyre commented on DERBY-3322:
Dyre, I'm still publishing my nightly doc build out to the docs/dev area of the
website. Please let me know if what's up there is stale and I'll check on the
copying process.
Server guide refers to phantom property in template policy file for the
Network Server
--
Key: DERBY-3322
URL: https://issues.apache.org/jira/browse/DERBY-3322
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.3.1.4, 10.3.2.1
Environment: N/A
Reporter: John H. Embretsen
Assignee: John H. Embretsen
Priority: Trivial
Fix For: 10.4.0.0
Attachments: d3322v01.diff, tadminnetservcustom.html
The Server and Administration guide contains a section about customizing the
Network Server's security policy, based on the template policy:
http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html
This section mentions that the variable ${derby.security.host} should be
replaced with a suitable value.
However, the template policy, at /demo/templates/server.policy (released
binaries) or java/drda/org/apache/derby/drda/template.policy (SVN codeline),
does not refer to any variable or property called ${derby.security.host}.
Instead, the policy file specifies the wildcard address, with appropriate
comments:
quote
// Accept connections from any host. Derby is listening to the host
// interface specified via the -h option to NetworkServerControl
// start on the command line, via the address parameter to the
// org.apache.derby.drda.NetworkServerControl constructor in the API
// or via the property derby.drda.host; the default is localhost.
// You may want to restrict allowed hosts, e.g. to hosts in a specific
// subdomain, e.g. *.acme.com.
permission java.net.SocketPermission *, accept;
/quote
See also
http://www.nabble.com/Customizing-the-Network-Server%27s-security-policy-%28docs-vs.-reality%29-td14841290.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
