Fw: Problem with Derby: Connection refused
Dear All, Please reply. Regards Sonny - Forwarded by Sonny Laskar/TVM/TCS on 11/27/2010 12:26 PM - | | From: | | | |Sonny Laskar/MUM/TCS | | | | To:| | | |derby-u...@db.apache.org, derby-user-subscr...@db.apache.org, derby-user-digest-subscr...@db.apache.org, derby-dev@db.apache.org| | | | Date: | | | |11/26/2010 08:59 PM | | | | Subject: | | | |Problem with Derby: Connection refused | | Dear All, I am new to Derby. Please assist me. Problem description: We have IBM System Director software installed which uses Derby 10 internally. I wanted to study the Derby database. The software uses 2 databases viz IBMCDB and hatterastc I copied these 2 folders in my java environment. I can connect to the first database IBMCDB and execute select queries on all the tables. But when I connect to the hatterastc database, I get Connection refused error. I am attaching the derby.log file. Please suggest how to proceed and let me know if I should share any more details. With Warm Regards, Sonny Laskar India Tata Consultancy Services Mailto: sonny.las...@tcs.com Website: http://www.tcs.com Experience certainty. IT Services Business Solutions Outsourcing (See attached file: derby.log) =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you derby.log Description: Binary data
Problem with Derby: Connection refused
Dear All,I am new to Derby.Please assist me.Problem description:We have IBM System Director software installed which uses Derby 10 internally.I wanted to study the Derby database.The software uses 2 databases viz IBMCDB and hatterastcI copied these 2 folders in my java environment.I can connect to the first database IBMCDB and execute select queries on all the tables. But when I connect to the hatterastc database, I get "Connection refused" error.I am attaching the derby.log file.Please suggest how to proceed and let me know if I should share any more details.With Warm Regards,Sonny LaskarIndiaTata Consultancy ServicesMailto: sonny.las...@tcs.comWebsite: http://www.tcs.comExperience certainty. IT Services Business Solutions Outsourcing=-=-=Notice: The information contained in this e-mailmessage and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you derby.log Description: Binary data
[jira] Closed: (DERBY-4899) Refactor access to primary structures in AlterTableConstantAction
[ https://issues.apache.org/jira/browse/DERBY-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-4899. -- Closing issue. Refactor access to primary structures in AlterTableConstantAction - Key: DERBY-4899 URL: https://issues.apache.org/jira/browse/DERBY-4899 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.7.1.1 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.7.1.1 Attachments: derby-4899-1a-cleanup.diff, derby-4899-1b-cleanup.diff Many of the private methods in impl.sql.execute.AlterTableConstantAction take the activation (and sometimes a number of references obtained through it) as an argument. This seems unnecessary, and it clutters the code with argument passing, boilerplate code and variable hiding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-4881) Deadlock accessing SYS.SYSSTATISTICS
[ https://issues.apache.org/jira/browse/DERBY-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-4881. -- Closing issue. Deadlock accessing SYS.SYSSTATISTICS Key: DERBY-4881 URL: https://issues.apache.org/jira/browse/DERBY-4881 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.6.2.3, 10.7.1.1 Attachments: derby-4881-1a-deadlock_fix.diff, derby-4881-1b-deadlock_fix.diff Transactions accessing index statistics can deadlock if one of them inserts new entries and the other selects from the system table. Inserts happens for instance when update of index statistics are perform manually, or when a table is compressed (given that the table has indexes and contains some rows). This issue may be more problematic when automatic update of index statistics is implemented. Issue discovered when writing a regression tests for DERBY-4849, see discussion there. The bug is timing dependent, but has been observed on a variety of JVMs and platform architectures. To sum up: o using NO_WAIT + retry was suggested, but turned out to be an infeasible solution o current approach is to allow using read uncommitted isolation level when accessing statistics in the system table (take no locks) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-4857) Utilize the SOAP API to fetch JIRA issue list for release notes generation
[ https://issues.apache.org/jira/browse/DERBY-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-4857. -- Closing issue. I have decided to not backport, because there has been a lot of other changes in the build/release system. This fix isn't dependent on those other fixes, but to me it makes sense to have a clear cut between where we use new functionality and where we use old mechanisms. This affects documentation too (mostly wiki). The release manager(s) should be aware that several release process tasks have changed in 10.7. Utilize the SOAP API to fetch JIRA issue list for release notes generation -- Key: DERBY-4857 URL: https://issues.apache.org/jira/browse/DERBY-4857 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.7.1.1 Reporter: Kristian Waagan Assignee: Kristian Waagan Fix For: 10.7.1.1 Attachments: derby-4857-1a-jirasoap_relnotes.diff, derby-4857-1a-jirasoap_relnotes.stat, derby-4857-2a-jirasoap_maven_client.diff, derby-4857-2a-jirasoap_maven_client.stat, derby-4857-3a-jirasoap_relnotesgen_changes.diff, derby-4857-3a-jirasoap_relnotesgen_changes.stat, derby-4857-3b-jirasoap_relnotesgen_changes.diff, derby-4857-4a-jirasoap_ant_integration.diff, derby-4857-4a-jirasoap_ant_integration.stat, derby-4857-4b-jirasoap_ant_integration.diff, derby-4857-5a-minor_tweaks.diff, derby-4857-6a-client_tweaks.diff, RELEASE-NOTES.html Somewhat simplified, the release manager (RM) must currently perform the following manual steps to feed the release note generate the data it needs: a) Create manual JIRA filter to select issues addressed by the release. b) Save the filter result to disk as XML. c) Write/modify the XML parser to be able to parse the report. d) Determine and record all JIRA release note attachment ids for the issues requiring a release note. By using the current version of the SOAP API (3.13.5), steps (b) to (d) can be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New process for generating release notes
Den 04.11.2010 17:30, skrev Myrna van Lunteren: On Thu, Nov 4, 2010 at 1:37 AM, Kristian Waagan kristian.waa...@oracle.com wrote: Hi all, A new process for generating the Derby release notes has now been put into place. The solution uses the JIRA SOAP-based API to pull down the required information. I was going to rewrite [1], but thought I'd ask if we want to backport the new solution first. Is the new solution worth backporting? (at least to 10.6, possibly to 10.5) Do we want Rick to fully test it for 10.7.1.0 before doing so? If the new tool [2] turns out to be working well, the next improvement will be to get rid of the manual step of creating a JIRA filter. This requires that the ASF JIRA instance is upgraded to version 4.x. Thanks, -- Kristian [1] http://wiki.apache.org/db-derby/ReleaseNoteProcess [2] https://issues.apache.org/jira/browse/DERBY-4857 my 2c: Definitely let Rick try it out first... Is the backport complicated? Or do you think it would be easy to do if/when we need to make another release on those older branches? If we do decide to put it back to 10.5 now I'd be willing to test drive a patch. Thank you for working on this - the old mechanism was definitely cumbersome and flaky and subject to sudden changes in JIRA. I think Rick revamped the release process docs, so there's an 'older releases' doc...If you can make the changes in a similar way it would make sense to rewrite that wiki. FYI, from DERBY-4857: Closing issue. I have decided to not backport, because there has been a lot of other changes in the build/release system. This fix isn't dependent on those other fixes, but to me it makes sense to have a clear cut between where we use new functionality and where we use old mechanisms. This affects documentation too (mostly wiki). The release manager(s) should be aware that several release process tasks have changed in 10.7. With some fiddling it may be possible to generate release notes with the new mechanism from trunk for a maintenance release on a different branch, but I haven't actually done this. Just mentioning it in case the old mechanism is severly affected by Jira changes some time in the future (affects branches prior to 10.7). -- Kristian Myrna
[jira] Closed: (DERBY-4673) Error using XPLAIN style tables
[
https://issues.apache.org/jira/browse/DERBY-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan closed DERBY-4673.
--
Closing issue.
Error using XPLAIN style tables
---
Key: DERBY-4673
URL: https://issues.apache.org/jira/browse/DERBY-4673
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.6.1.0, 10.7.1.1
Reporter: Stephan van Loendersloot
Assignee: Kristian Waagan
Priority: Minor
Fix For: 10.6.2.3, 10.7.1.1
While trying the new Derby release (10.6.1.0), I ran into the following error
using XPLAIN style tables:
ERROR 22001: A truncation error was encountered trying to shrink CHAR
'C0A80265.A193-436003464463927241{25}' to length 32.
(Full stack trace is at the end of this message)
The culprit seems to be that the table SYSXPLAIN_STATEMENTS is created with a
column 'DRDA_ID CHAR(32)'.
After digging in the Derby code I found the following in
org.apache.derby.diag.ErrorLogReader
EmbedResultSetMetaData.getResultColumnDescriptor(DRDAID, Types.VARCHAR,
true, 50),
However, I also found the following in
org.apache.derby.impl.sql.catalog.XPLAINStatementDescriptor
SystemColumnImpl.getColumn(DRDA_ID, Types.CHAR, true, 32),
Another error in the XPLAIN tables is the following:
ERROR 22001: A truncation error was encountered trying to shrink VARCHAR
'Column[0][0] Id: 18
Operator: =
Ordered nulls: false
Unknown' to length 512.
This time, it's the SYSXPLAIN_SCAN_PROPS table
(org.apache.derby.impl.sql.catalog.XPLAINScanPropsDescriptor):
SystemColumnImpl.getColumn(SCAN_QUALIFIERS, Types.VARCHAR, true, 512),
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-4772) Data truncation error with XPLAIN-functionality enabled
[ https://issues.apache.org/jira/browse/DERBY-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-4772. -- Closing issue. Data truncation error with XPLAIN-functionality enabled --- Key: DERBY-4772 URL: https://issues.apache.org/jira/browse/DERBY-4772 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.2.1, 10.7.1.1 Reporter: Kristian Waagan Assignee: Kristian Waagan Fix For: 10.6.2.3, 10.7.1.1 Attachments: derby-4772-1a-increase_max_len.diff, derby-4772-1b-increase_max_len.diff, releaseNote.html, releaseNote.html When running a modified version of lang.OrderByAndSortAvoidance I get the following error: java.sql.SQLDataException: A truncation error was encountered trying to shrink CHAR 'Thread[DRDAConnThread_3,5,derby.daemons]' to length 32. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:79) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256) 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:2269) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1321) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1673) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:303) at org.apache.derby.impl.sql.execute.xplain.XPLAINSystemTableVisitor.addStmtDescriptorsToSystemCatalog(XPLAINSystemTableVisitor.java:390) at org.apache.derby.impl.sql.execute.xplain.XPLAINSystemTableVisitor.doXPLAIN(XPLAINSystemTableVisitor.java:317) at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.close(NoPutResultSetImpl.java:179) at org.apache.derby.impl.sql.execute.SortResultSet.close(SortResultSet.java:467) at org.apache.derby.impl.jdbc.EmbedResultSet.close(EmbedResultSet.java:575) at org.apache.derby.impl.drda.DRDAResultSet.close(DRDAResultSet.java:338) at org.apache.derby.impl.drda.DRDAStatement.rsClose(DRDAStatement.java:995) at org.apache.derby.impl.drda.DRDAConnThread.doneData(DRDAConnThread.java:7446) at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnThread.java:7026) at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnThread.java:6910) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:870) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:294) Caused by: java.sql.SQLException: A truncation error was encountered trying to shrink CHAR 'Thread[DRDAConnThread_3,5,derby.daemons]' to length 32. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 20 more Caused by: ERROR 22001: A truncation error was encountered trying to shrink CHAR 'Thread[DRDAConnThread_3,5,derby.daemons]' to length 32. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:343) at org.apache.derby.iapi.types.SQLChar.hasNonBlankChars(SQLChar.java:1767) at org.apache.derby.iapi.types.SQLChar.normalize(SQLChar.java:1743) at org.apache.derby.iapi.types.SQLChar.normalize(SQLChar.java:1695) at org.apache.derby.iapi.types.DataTypeDescriptor.normalize(DataTypeDescriptor.java:648) at org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeColumn(NormalizeResultSet.java:329) at org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeRow(NormalizeResultSet.java:373) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java:188) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:504) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317) at
[jira] Commented: (DERBY-4709) Create test that parse client trace file to detect round-trips for Derby-4653
[ https://issues.apache.org/jira/browse/DERBY-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965185#action_12965185 ] Kristian Waagan commented on DERBY-4709: Lily, can this issue be closed? Create test that parse client trace file to detect round-trips for Derby-4653 - Key: DERBY-4709 URL: https://issues.apache.org/jira/browse/DERBY-4709 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.7.1.1 Reporter: Lily Wei Assignee: Kristian Waagan Priority: Minor Fix For: 10.7.1.1 Attachments: derby-4709-1a-alternative_test.diff, derby-4709-1b-alternative_test.diff, derby-4709-1c-alternative_test.diff In DERBY-4653, Kristian suggested we have a test that parse the trace file to detect round-trip Connection.flowcommit() instead of calling getClientTransactionID() method. The existing test for DERBY-4653 is in J2EEDataSourceTest.testConnectionFlowCommit(). When this issue get fixed, the call for getClientTransactionID can be replace with trace file parsing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4653) Avoid unnecessary round-trip for commit in the client driver
[ https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965186#action_12965186 ] Kristian Waagan commented on DERBY-4653: Lily, can this issue be closed? Avoid unnecessary round-trip for commit in the client driver - Key: DERBY-4653 URL: https://issues.apache.org/jira/browse/DERBY-4653 Project: Derby Issue Type: Improvement Components: JDBC, Network Client Affects Versions: 10.7.1.1 Reporter: Kristian Waagan Assignee: Lily Wei Priority: Minor Fix For: 10.7.1.1 Attachments: _sds_0, DERBY-4653-1.diff, DERBY-4653-2.diff, DERBY-4653-3_withrollback.diff, DERBY-4653-4_withcommitrollbacktest.diff, DERBY-4653-5_withflowcommitrollback.diff, DERBY-4653-6_withflowcommitrollback.diff, DERBY-4653-7_withflowcommittest.diff, DERBY-4653-7_withflowcommittest_comment_update_diff.txt, DERBY-4653-7_withflowcommittest_comment_update_diff.txt, DERBY-4653-7_withflowcommittest_comment_update_diff_followup.txt, ReproTransInProgressAttempt.java, SaveRoundClientDS.java, SaveRoundClientDS.java The methods Connection.commit() and Connection.rollback() in the client driver cause a round-trip to the server even if the commit/rollback is unnecessary (i.e. there is nothing to commit or roll back). Comments suggest (see below) that this can be optimized, such that the commands are flowed to the server only when required. It can be seen that this optimization has been used other places in the client driver. Never the less, it must be checked that this optimization doesn't have side-effects. This issue came up in connection with connection pooling, where a pool implementation always issued a rollback to make sure there was no active transaction on the connection handed out. From Connection.flowCommit: // Per JDBC specification (see javadoc for Connection.commit()): // This method should be used only when auto-commit mode has been disabled. // However, some applications do this anyway, it is harmless, so // if they ask to commit, we could go ahead and flow a commit. // But note that rollback() is less harmless, rollback() shouldn't be used in auto-commit mode. // This behavior is subject to further review. // if (!this.inUnitOfWork) // return; // We won't try to be too smart, if the user requests a commit, we'll flow a commit, // regardless of whether or not we're in a unit of work or in auto-commit mode. // -- 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 (5 issues) Subscriber: derby-dev Key Summary DERBY-4771 Continue investigation of automatic creation/update of index statistics https://issues.apache.org/jira/browse/DERBY-4771 DERBY-4918 Minor refactoring of SPSDescriptor https://issues.apache.org/jira/browse/DERBY-4918 DERBY-268 Add Support for truncate table https://issues.apache.org/jira/browse/DERBY-268 DERBY-4713 Subclasses of ScriptTestCase can not run correctly with the non-English default locale https://issues.apache.org/jira/browse/DERBY-4713 DERBY-4183 Our regression tests use various jar files for which we don't have build scripts. https://issues.apache.org/jira/browse/DERBY-4183 You may edit this subscription at: https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?subId=10396filterId=12310751
[jira] Commented: (DERBY-4913) 10.3 to 10.5 upgrade fails with ava.io.StreamCorruptedException: java.lang.ClassCastException: org.apache.derby.catalog.types.OldRoutineType incompatible with org.apache
[ https://issues.apache.org/jira/browse/DERBY-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965226#action_12965226 ] Rick Hillegas commented on DERBY-4913: -- The serialization of data types seems to have changed in both 10.4 and 10.5. It would be interesting to know if you see this problem when upgrading the database from 10.3 to 10.4. If that works, try upgrading from 10.4 to 10.5. 10.3 to 10.5 upgrade fails with ava.io.StreamCorruptedException: java.lang.ClassCastException: org.apache.derby.catalog.types.OldRoutineType incompatible with org.apache.derby.iapi.types.DataTypeDescriptor - Key: DERBY-4913 URL: https://issues.apache.org/jira/browse/DERBY-4913 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.5.3.0 Reporter: Kathey Marsden Attachments: ClassLoaderUpgrade.java, derby-4913_initcause_diff.txt I have a report from a user upgrading to 10.5 from 10.3 that they got the following error during upgrade. I don't have much in the way of details yet, but thought I would post an issue since I've never seen this error before. I do have the original 10.3 database and it seems to upgrade fine to 10.5 with ij. java.sql.SQLException: Failed to start database '/ 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.seeNextException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source) at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source) at org.apache.derby.jdbc.EmbedPooledConnection.openRealConnection(U nknown Source) at org.apache.derby.jdbc.EmbedPooledConnection.init(Unknown Source) at org.apache.derby.jdbc.EmbedPooledConnection40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.getNewPooledConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource.createPoo ledConnection(Unknown Source) at org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource.getPooled Connection(Unknown Source) at snip Caused by: java.sql.SQLException: Failed to start database 'snip759243AF2F8 4F1DE' with class loader snip.extclassloa...@3e955f6, see the next exception for details. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(U nknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTran sportAcrossDRDA(Unknown Source) ... 41 more Caused by: java.sql.SQLException: Exception during restore of a serializable or SQLData object of class at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(U nknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTran sportAcrossDRDA(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException (Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) ... 38 more Caused by: ERROR XSDA8: Exception during restore of a serializable or SQLData object of class at org.apache.derby.iapi.error.StandardException.newException(Unkno wn Source) at org.apache.derby.impl.store.raw.data.StoredPage.readRecordFromAr ray(Unknown Source) at org.apache.derby.impl.store.raw.data.StoredPage.restoreRecordFro mSlot(Unknown Source) at org.apache.derby.impl.store.raw.data.BasePage.fetchFromSlot(Unkn own Source) at org.apache.derby.impl.store.access.conglomerate.GenericScanContr oller.fetchRows(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapScan.fetchNext(Unkno wn Source) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescript orViaHeap(Unknown Source) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getAllSPSDe scriptors(Unknown Source) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.dropJDBCMet adataSPSes(Unknown Source) at
Question about an OutOfMemory PermGen that is happening
A system running Solaris 10 using Derby 10.5.3 and JDK 1.6.0_05 has had a OutOfMemory PermGen reported in derby.log a couple of times of the past few months. This system has been running for over a year now with no problems but the last few months this has been reported and the system needed to be restarted. The only changes in the database access have been a substantial increase in the number of database records that have been inserted, deleted, and queried upon. There have been no new derby classes (ie procedures or functions) loaded into the system. The system runs about 2 weeks of constant access that last time before this occurred again. So any ideas why it would be getting a PermGen error? I know I can pass a parameter to increase the PermGen size (right now, it is using the JVM default) but I was wondering what would trigger this. Also, any recommendations on what this should be set to? Thanks. Brett
[jira] Reopened: (DERBY-4711) Hung thread after another thread is interrupted
[ https://issues.apache.org/jira/browse/DERBY-4711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan reopened DERBY-4711: Reopening for backport to 10.6. One of the changes in the test harness is needed for another backport, and this fix seems nice to have in older branches too. Hung thread after another thread is interrupted --- Key: DERBY-4711 URL: https://issues.apache.org/jira/browse/DERBY-4711 Project: Derby Issue Type: Bug Components: Services Affects Versions: 10.5.3.0 Environment: Windows server 2008 Reporter: Luke Quinane Assignee: Luke Quinane Fix For: 10.7.1.1 Attachments: interrupted-exception-fix.diff, interrupted-exception-fix.patch, junit-timing-fix.diff, junit.diff We've seen a problem today where we have several threads querying our database and when one gets interrupted the others are stuck waiting for a lock. Here is the stack trace for the stuck thread(s): daemon prio=4 DefaultExecutorService-pool-1-thread-47 Id=98 WAITING on org.apache.derby.impl.services.locks.activel...@6e6f45a1 at java.lang.Object.wait(Native Method) - waiting on org.apache.derby.impl.services.locks.activel...@6e6f45a1 at java.lang.Object.wait(Object.java:485) at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:115) at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(ConcurrentLockSet.java:463) at org.apache.derby.impl.services.locks.ConcurrentLockSet.zeroDurationLockObject(ConcurrentLockSet.java:855) at org.apache.derby.impl.services.locks.AbstractPool.zeroDurationlockObject(AbstractPool.java:297) at org.apache.derby.impl.services.locks.ConcurrentPool.zeroDurationlockObject(ConcurrentPool.java:28) at org.apache.derby.impl.store.raw.xact.RowLocking2nohold.lockRecordForRead(RowLocking2nohold.java:89) at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:520) at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:638) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:309) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:599) at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:105) at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:305) at org.apache.derby.impl.store.access.btree.BTreeScan.fetchNextGroup(BTreeScan.java:1585) at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(BulkTableScanResultSet.java:327) at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(BulkTableScanResultSet.java:282) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:460) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:427) - locked org.apache.derby.impl.jdbc.embedconnectio...@445d374b at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:371) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-4711) Hung thread after another thread is interrupted
[ https://issues.apache.org/jira/browse/DERBY-4711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan resolved DERBY-4711. Resolution: Fixed Fix Version/s: 10.6.2.2 Backported to 10.6 with revision 1040551. Hung thread after another thread is interrupted --- Key: DERBY-4711 URL: https://issues.apache.org/jira/browse/DERBY-4711 Project: Derby Issue Type: Bug Components: Services Affects Versions: 10.5.3.0 Environment: Windows server 2008 Reporter: Luke Quinane Assignee: Luke Quinane Fix For: 10.6.2.2, 10.7.1.1 Attachments: interrupted-exception-fix.diff, interrupted-exception-fix.patch, junit-timing-fix.diff, junit.diff We've seen a problem today where we have several threads querying our database and when one gets interrupted the others are stuck waiting for a lock. Here is the stack trace for the stuck thread(s): daemon prio=4 DefaultExecutorService-pool-1-thread-47 Id=98 WAITING on org.apache.derby.impl.services.locks.activel...@6e6f45a1 at java.lang.Object.wait(Native Method) - waiting on org.apache.derby.impl.services.locks.activel...@6e6f45a1 at java.lang.Object.wait(Object.java:485) at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:115) at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(ConcurrentLockSet.java:463) at org.apache.derby.impl.services.locks.ConcurrentLockSet.zeroDurationLockObject(ConcurrentLockSet.java:855) at org.apache.derby.impl.services.locks.AbstractPool.zeroDurationlockObject(AbstractPool.java:297) at org.apache.derby.impl.services.locks.ConcurrentPool.zeroDurationlockObject(ConcurrentPool.java:28) at org.apache.derby.impl.store.raw.xact.RowLocking2nohold.lockRecordForRead(RowLocking2nohold.java:89) at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:520) at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:638) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:309) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:599) at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:105) at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:305) at org.apache.derby.impl.store.access.btree.BTreeScan.fetchNextGroup(BTreeScan.java:1585) at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(BulkTableScanResultSet.java:327) at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(BulkTableScanResultSet.java:282) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:460) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:427) - locked org.apache.derby.impl.jdbc.embedconnectio...@445d374b at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:371) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-4849) Re-compilation may cause duplicate entries in the XPLAIN table
[ https://issues.apache.org/jira/browse/DERBY-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan resolved DERBY-4849. Resolution: Fixed Fix Version/s: 10.6.2.2 Backported fix to the 10.6 branch with revision 1040569. Marking issue as fixed. Re-compilation may cause duplicate entries in the XPLAIN table -- Key: DERBY-4849 URL: https://issues.apache.org/jira/browse/DERBY-4849 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.2.1, 10.7.1.1 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.6.2.2, 10.7.1.1 Attachments: derby-4849-1a-narrow_fix.diff, derby-4849-2a-broad_fix.diff, derby-4849-2b-broad_fix_with_test.diff, derby-4849-2b-broad_fix_with_test.stat, derby-4849-2c-broad_fix_with_test.diff, derby-4849-xplain_duplicate_stacktrace.txt If happening at the right moment, a re-compilation request may cause duplicate entries in the XPLAIN statement tables. I have only confirmed this for the SYSXPLAIN_STATEMENTS table, and I do not know if the other XPLAIN tables are affected. The error is highly intermittent, and so far I have only been able to trigger it when testing the automatic index statistics update prototype. See the attached stack-trace for some more details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question about an OutOfMemory PermGen that is happening
Bergquist, Brett br...@canoga.com writes: A system running Solaris 10 using Derby 10.5.3 and JDK 1.6.0_05 has had a OutOfMemory PermGen reported in derby.log a couple of times of the past few months. This system has been running for over a year now with no problems but the last few months this has been reported and the system needed to be restarted. The only changes in the database access have been a substantial increase in the number of database records that have been inserted, deleted, and queried upon. There have been no new derby classes (ie procedures or functions) loaded into the system. The system runs about 2 weeks of constant access that last time before this occurred again. So any ideas why it would be getting a PermGen error? When Derby compiles a query, it generates and loads a new Java class for executing the query. The generated classes should be garbage collected when they're no longer in use, so they shouldn't normally fill the PermGen. But there's a cache which holds up to 100 compiled statement, so the PermGen footprint usually grows until the cache has been filled. There could of course be a leak, either in the application or in the Derby code. Running the Java process with -XX:+HeapDumpOnOutOfMemoryError and inspecting the heap dump may give some indications. -- Knut Anders
[jira] Closed: (DERBY-4653) Avoid unnecessary round-trip for commit in the client driver
[ https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lily Wei closed DERBY-4653. --- Avoid unnecessary round-trip for commit in the client driver - Key: DERBY-4653 URL: https://issues.apache.org/jira/browse/DERBY-4653 Project: Derby Issue Type: Improvement Components: JDBC, Network Client Affects Versions: 10.7.1.1 Reporter: Kristian Waagan Assignee: Lily Wei Priority: Minor Fix For: 10.7.1.1 Attachments: _sds_0, DERBY-4653-1.diff, DERBY-4653-2.diff, DERBY-4653-3_withrollback.diff, DERBY-4653-4_withcommitrollbacktest.diff, DERBY-4653-5_withflowcommitrollback.diff, DERBY-4653-6_withflowcommitrollback.diff, DERBY-4653-7_withflowcommittest.diff, DERBY-4653-7_withflowcommittest_comment_update_diff.txt, DERBY-4653-7_withflowcommittest_comment_update_diff.txt, DERBY-4653-7_withflowcommittest_comment_update_diff_followup.txt, ReproTransInProgressAttempt.java, SaveRoundClientDS.java, SaveRoundClientDS.java The methods Connection.commit() and Connection.rollback() in the client driver cause a round-trip to the server even if the commit/rollback is unnecessary (i.e. there is nothing to commit or roll back). Comments suggest (see below) that this can be optimized, such that the commands are flowed to the server only when required. It can be seen that this optimization has been used other places in the client driver. Never the less, it must be checked that this optimization doesn't have side-effects. This issue came up in connection with connection pooling, where a pool implementation always issued a rollback to make sure there was no active transaction on the connection handed out. From Connection.flowCommit: // Per JDBC specification (see javadoc for Connection.commit()): // This method should be used only when auto-commit mode has been disabled. // However, some applications do this anyway, it is harmless, so // if they ask to commit, we could go ahead and flow a commit. // But note that rollback() is less harmless, rollback() shouldn't be used in auto-commit mode. // This behavior is subject to further review. // if (!this.inUnitOfWork) // return; // We won't try to be too smart, if the user requests a commit, we'll flow a commit, // regardless of whether or not we're in a unit of work or in auto-commit mode. // -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4653) Avoid unnecessary round-trip for commit in the client driver
[ https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965269#action_12965269 ] Lily Wei commented on DERBY-4653: - Thanks Kristian. I'll close this issue now. Avoid unnecessary round-trip for commit in the client driver - Key: DERBY-4653 URL: https://issues.apache.org/jira/browse/DERBY-4653 Project: Derby Issue Type: Improvement Components: JDBC, Network Client Affects Versions: 10.7.1.1 Reporter: Kristian Waagan Assignee: Lily Wei Priority: Minor Fix For: 10.7.1.1 Attachments: _sds_0, DERBY-4653-1.diff, DERBY-4653-2.diff, DERBY-4653-3_withrollback.diff, DERBY-4653-4_withcommitrollbacktest.diff, DERBY-4653-5_withflowcommitrollback.diff, DERBY-4653-6_withflowcommitrollback.diff, DERBY-4653-7_withflowcommittest.diff, DERBY-4653-7_withflowcommittest_comment_update_diff.txt, DERBY-4653-7_withflowcommittest_comment_update_diff.txt, DERBY-4653-7_withflowcommittest_comment_update_diff_followup.txt, ReproTransInProgressAttempt.java, SaveRoundClientDS.java, SaveRoundClientDS.java The methods Connection.commit() and Connection.rollback() in the client driver cause a round-trip to the server even if the commit/rollback is unnecessary (i.e. there is nothing to commit or roll back). Comments suggest (see below) that this can be optimized, such that the commands are flowed to the server only when required. It can be seen that this optimization has been used other places in the client driver. Never the less, it must be checked that this optimization doesn't have side-effects. This issue came up in connection with connection pooling, where a pool implementation always issued a rollback to make sure there was no active transaction on the connection handed out. From Connection.flowCommit: // Per JDBC specification (see javadoc for Connection.commit()): // This method should be used only when auto-commit mode has been disabled. // However, some applications do this anyway, it is harmless, so // if they ask to commit, we could go ahead and flow a commit. // But note that rollback() is less harmless, rollback() shouldn't be used in auto-commit mode. // This behavior is subject to further review. // if (!this.inUnitOfWork) // return; // We won't try to be too smart, if the user requests a commit, we'll flow a commit, // regardless of whether or not we're in a unit of work or in auto-commit mode. // -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4709) Create test that parse client trace file to detect round-trips for Derby-4653
[ https://issues.apache.org/jira/browse/DERBY-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965270#action_12965270 ] Lily Wei commented on DERBY-4709: - Thanks Kristian. Yes, please close this issue. Great job. I really appreciated it. Create test that parse client trace file to detect round-trips for Derby-4653 - Key: DERBY-4709 URL: https://issues.apache.org/jira/browse/DERBY-4709 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.7.1.1 Reporter: Lily Wei Assignee: Kristian Waagan Priority: Minor Fix For: 10.7.1.1 Attachments: derby-4709-1a-alternative_test.diff, derby-4709-1b-alternative_test.diff, derby-4709-1c-alternative_test.diff In DERBY-4653, Kristian suggested we have a test that parse the trace file to detect round-trip Connection.flowcommit() instead of calling getClientTransactionID() method. The existing test for DERBY-4653 is in J2EEDataSourceTest.testConnectionFlowCommit(). When this issue get fixed, the call for getClientTransactionID can be replace with trace file parsing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - Daily 1040190 - Sun DBTG
[Auto-generated mail] *Daily* 1040190/2010-11-29 18:00:24 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 01308613086 0 1406.31% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded NA NA NANA derbyall 022 0 1146.22% compatibility 022 0 .% demoSuite sles NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite sol 01308613086 0 953.24% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0204204 041.50% derbyall 022 0 419.82% compatibility 022 0 .% demoSuite sol32 NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite solN+1 01308613086 0 188.19% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0204204 060.32% derbyall 022 0 376.79% compatibility 022 0 .% demoSuite sparc 01308613086 0 482.85% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0204204 031.08% derbyall 022 0 378.85% compatibility 022 0 .% demoSuite vista NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite vista-64 NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite w2003 NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1040190.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/1040190_bySig.html *Jvm: 1.5* lin NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 0205205 042.38% derbyall 01126011260 0 1767.87% suitesAll sol32 NA NA NANA derbyall NA NA NANA suitesAll solN+1 0205205 054.53% derbyall 01126011260 0 1878.52% suitesAll sparc 0205205 031.43% derbyall 01126011260 0 1119.14% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll
[jira] Closed: (DERBY-4709) Create test that parse client trace file to detect round-trips for Derby-4653
[ https://issues.apache.org/jira/browse/DERBY-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-4709. -- Thanks, Lily. I asked because you are listed as reporter. In general I prefer that the reporter closes the issue he/she filed, as the reporter is generally in a better position to tell if the issue has indeed been addressed or not. Create test that parse client trace file to detect round-trips for Derby-4653 - Key: DERBY-4709 URL: https://issues.apache.org/jira/browse/DERBY-4709 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.7.1.1 Reporter: Lily Wei Assignee: Kristian Waagan Priority: Minor Fix For: 10.7.1.1 Attachments: derby-4709-1a-alternative_test.diff, derby-4709-1b-alternative_test.diff, derby-4709-1c-alternative_test.diff In DERBY-4653, Kristian suggested we have a test that parse the trace file to detect round-trip Connection.flowcommit() instead of calling getClientTransactionID() method. The existing test for DERBY-4653 is in J2EEDataSourceTest.testConnectionFlowCommit(). When this issue get fixed, the call for getClientTransactionID can be replace with trace file parsing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4709) Create test that parse client trace file to detect round-trips for Derby-4653
[ https://issues.apache.org/jira/browse/DERBY-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965386#action_12965386 ] Lily Wei commented on DERBY-4709: - Sorry about that. I did not realize that. Thanks Kristian. I will do that next time. Create test that parse client trace file to detect round-trips for Derby-4653 - Key: DERBY-4709 URL: https://issues.apache.org/jira/browse/DERBY-4709 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.7.1.1 Reporter: Lily Wei Assignee: Kristian Waagan Priority: Minor Fix For: 10.7.1.1 Attachments: derby-4709-1a-alternative_test.diff, derby-4709-1b-alternative_test.diff, derby-4709-1c-alternative_test.diff In DERBY-4653, Kristian suggested we have a test that parse the trace file to detect round-trip Connection.flowcommit() instead of calling getClientTransactionID() method. The existing test for DERBY-4653 is in J2EEDataSourceTest.testConnectionFlowCommit(). When this issue get fixed, the call for getClientTransactionID can be replace with trace file parsing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4771) Continue investigation of automatic creation/update of index statistics
[ https://issues.apache.org/jira/browse/DERBY-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965450#action_12965450 ] Dag H. Wanvik commented on DERBY-4771: -- Thanks Kristian! Re testDropWhileScanningThenDelete proposal, sorry, reviewer was just confused ;-) Continue investigation of automatic creation/update of index statistics --- Key: DERBY-4771 URL: https://issues.apache.org/jira/browse/DERBY-4771 Project: Derby Issue Type: Task Components: SQL, Store Affects Versions: 10.8.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Attachments: autoindexstats.html, derby-4771-1a-prototype_code_dump.diff, derby-4771-1a-prototype_code_dump.stat, derby-4771-1b-prototype_code_dump.diff, derby-4771-2a-prototype_lcc_code_dump.diff, derby-4771-2b-prototype_lcc_code_dump.diff, derby-4771-2c-prototype_lcc_code_dump.diff, derby-4771-2d-prototype_lcc_code_dump.diff, DERBY-4771-2e-prototype.rar, derby-4771-2e-prototype_lcc_code_dump.diff, derby-4771-2f-prototype_lcc_code_dump-WORK-IN-PROGRESS.diff, derby.log, error-stacktrace.out, rjall.out, rjall.out, rjall.out, rjall.rar, rjone.out Work was started to improve Derby's handling of index statistics. This issue tracks further discussion and work for this task. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Looking for hang (DERBY-4920)
Hi, I have now committed a fix on trunk of some errors in the interrupt handling of RAFContainer4 as part of DERBY-4741. We saw hangs in suitesAll (DERBY-4920) prior to that check-in (svn 1040086); I am now looking for instances of the hang *after* 1040086 went in. Please let me know if you still see it, as I doubt 1040086 fixed the root cause of DERBY-4741, with as much detail as you can provide (e.g. jps, jstack). Meanwhile I am thinking about a way to instrument the code to catch the issue. Thanks, Dag
[jira] Created: (DERBY-4922) failure in tests using encryption - fails to rename certain database files
failure in tests using encryption - fails to rename certain database files -- Key: DERBY-4922 URL: https://issues.apache.org/jira/browse/DERBY-4922 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.7.1.1, 10.7.1.2 Environment: windows XP Reporter: Myrna van Lunteren I've seen 2 test failures related to an attempt by derby to rename database files; 1: during nightly tests (11/29/2010; svn sync-ed up to 1040394, so 10.7.1.2) with ibm 1.6 SR8, derbyall (dir edited to shorter name inserted line breaks for readability) *** Start: encryptDatabase jdk1.6.0 encryptionAll:encryptionOFB 2010-11-30 00:41:14 *** 74 del 0 rows inserted/updated/deleted 74a74,76 ERROR 38000: The exception 'org.apache.derby.iapi.error.PassThroughException: ERROR XBM0S: Unable to rename file 'C:\test\\derbyall\encryptionAll\encryptionOFB\encryptDatabase\wombat\service.properties' to 'C:\test\derbyall\encryptionAll\encryptionOFB\encryptDatabase\wombat\service.propertiesold'' was thrown while evaluating an expression. ERROR XJ001: Java exception: 'ERROR XBM0S: Unable to rename file 'C:\test\derbyall\encryptionAll\encryptionOFB\encryptDatabase\wombat\service.properties' to 'C:\test\derbyall\encryptionAll\encryptionOFB\encryptDatabase\wombat\service.propertiesold': org.apache.derby.iapi.error.PassThroughException'. ERROR XBM0S: Unable to rename file 'C:\test\derbyall\encryptionAll\encryptionOFB\encryptDatabase\wombat\service.properties' to 'C:\test\derbyall\encryptionAll\encryptionOFB\encryptDatabase\wombat\service.propertiesold' .(many more resulting diffs)... 2: during DbpPowersTest in test cycle of 10.7.1.1 (build 1040133), with ibm 1.5. SR11 FP1: 1) testReEncrypt(org.apache.derbyTesting.functionTests.tests.jdbcapi.DboPowersTest) junit.framework.AssertionFailedError: (re)encryption, no authentication expected:null but was: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ040, SQLERRMC: Failed to start database 'singleUse/oneuse1e' with class loader sun.misc.launcher$appclassloa...@2c0a2c0a, see the next exception for details.:: SQLSTATE: XJ001Java exception: 'ERROR XBM0S: Unable to rename file 'C:\test\system\singleUse\oneuse1e\service.properties' to 'C:\test\system\singleUse\oneuse1e\service.propertiesold': org.apache.derby.iapi.error.PassThroughException'.::SQLSTATE: XBM0S Unable to rename file 'C:\test\system\singleUse\oneuse1e\service.properties' to 'C:\test\system\singleUse\oneuse1e\service.propertiesold' at org.apache.derbyTesting.functionTests.tests.jdbcapi.DboPowersTest.vetAttempt(DboPowersTest.java:751) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DboPowersTest.vetEncryptionAttempt(DboPowersTest.java:586) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DboPowersTest.testReEncrypt(DboPowersTest.java:510) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109) 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) 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) I believe the problems are related to the removeDir issues of DERBY-4905 and DERBY-4915. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4915) test failure in OSReadOnlyTest in assertDirectoryDeleted
[ https://issues.apache.org/jira/browse/DERBY-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965469#action_12965469 ] Myrna van Lunteren commented on DERBY-4915: --- I saw this also in a nightly run with 10.7.1.2 - synced to revision 1040394, with ibm 1.5 (sr11); failing to delete the dir startingdirsystem\singleUse\readOnly: at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(BaseJDBCTestCase.java:1421) at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.moveDatabaseOnOS(OSReadOnlyTest.java:295) at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:152) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109) 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) test failure in OSReadOnlyTest in assertDirectoryDeleted Key: DERBY-4915 URL: https://issues.apache.org/jira/browse/DERBY-4915 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.7.1.1 Environment: windows XP, ibm 1.6 Reporter: Myrna van Lunteren I've seen the assert flag a failure for deleteing a log file last night, and a seg0 file the night before. This is one stack trace: 1) testOSReadOnly(org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest)junit.framework.AssertionFailedError: Failed to delete 2 files (root=F:\test\JarResults.2010-11-23\ibm16_suites.All\system\singleUse\readWrite: F:\test\JarResults.2010-11-23\ibm16_suites.All\system\singleUse\readWrite\log (isDir=true, canRead=true, canWrite=true, size=0), F:\jartest\JarResults.2010-11-23\ibm16_suites.All\system\singleUse\readWrite (isDir=true, canRead=true, canWrite=true, size=0) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(BaseJDBCTestCase.java:1421) at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.moveDatabaseOnOS(OSReadOnlyTest.java:295) at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:160) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) 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:16) 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:16) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) 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:16) This is another: 1)
[jira] Commented: (DERBY-4916) Upgrade tests fail in DropDatabaseSetup.tearDown unable to delete a directory
[ https://issues.apache.org/jira/browse/DERBY-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965476#action_12965476 ] Myrna van Lunteren commented on DERBY-4916: --- It seems you're running without -Dderby.tests.trace=true...I ran with, and could identify the failing test to be more often than not SqlRolesTest fixture - see DERBY-4905. I wonder, as you say this reproduces for you by running just the upgrade suite, if you would see the same if you were to run with that property on. I used the -DderbyTesting.oldReleasePaht property for my tests. All the same, I saw a similar test failure, not in the upgrade tests, but in o.a.d.functionTests.tests.store.OfflineBackupTest.testCreateFromRestoreFrom (trying to remove log dir) with ibm 1.5. Upgrade tests fail in DropDatabaseSetup.tearDown unable to delete a directory - Key: DERBY-4916 URL: https://issues.apache.org/jira/browse/DERBY-4916 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.7.1.1 Environment: o 1.Oracle JRockit(R) (build R28.0.1-21-133393-1.5.0_24-20100512-2132-windows-ia32, compiled mode) 2. Sun JDK 1.6.0_20, Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing) o OS: Windows Vista Home Premium SP2 Reporter: Kristian Waagan Attachments: example1.txt, example2.txt The upgrade test fails in the teardown phase because a database directory cannot be deleted. Happens for a varying number of version combinations, I've seen from one to five failed tests (out of 2496 tests) so far. See attached files for some examples. The error is reproducible running the upgrade suite standalone. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4905) test failure in teardown (removeDir) related to testSQLRoles
[ https://issues.apache.org/jira/browse/DERBY-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965483#action_12965483 ] Myrna van Lunteren commented on DERBY-4905: --- I saw similar failures with 10.7.1.1 run with ibm 1.6 SR8 - once on update from 10.2.1.6 (phase CREATE) and once from 10.2.2.0 (phase CREATE). Also in that run there was one removeDir test failure with ibm 1.5 during org.apache.derbyTesting.tests.store.OfflineBackupTest, fixture testCreateFromRestoreFrom (attempting to delete the log dir). I have tested 10.6.2 on this same machine and did *not* see this type of error then. test failure in teardown (removeDir) related to testSQLRoles Key: DERBY-4905 URL: https://issues.apache.org/jira/browse/DERBY-4905 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.7.1.1 Environment: Windows XP, ibm 1.6 SR8 Reporter: Myrna van Lunteren During the windows XP test run of the 10.7.1. release candidate (1035301) this failure popped up: 1) Upgrade test for 10.5junit.framework.AssertionFailedError: extin at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:116) at org.apache.derbyTesting.junit.DropDatabaseSetup.access$000(DropDatabaseSetup.java:35) at org.apache.derbyTesting.junit.DropDatabaseSetup$1.run(DropDatabaseSetup.java:105) at java.security.AccessController.doPrivileged(AccessController.java:202) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:102) at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:98) at org.apache.derbyTesting.junit.SupportFilesSetup.tearDown(SupportFilesSetup.java:127) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:16) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) 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:51) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) 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:51) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) 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:51) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) 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:51) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) 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:51) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) 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:51) at
[jira] Created: (DERBY-4923) update of a long row can fail with ERROR nospc: nospc.U exception.
update of a long row can fail with ERROR nospc: nospc.U exception. -- Key: DERBY-4923 URL: https://issues.apache.org/jira/browse/DERBY-4923 Project: Derby Issue Type: Bug Affects Versions: 10.6.2.1, 10.6.1.0, 10.5.3.0 Reporter: Mike Matrigali Assignee: Mike Matrigali An update of a row fails with a nospc.U exception. If there is space on the disk then an update should never fail for a space issue. The code is meant to always reserve enough space on a page such that if an expanding update happens that does not fit, it should in the worst case change the row to an overflow row pointer and put the rest in a linked overflow chain. The following set of circumstances will cause this bug (not sure which are exactly needed - just what i did to cause the repro), I will be attaching a test case: The row being updated has the following characteristics: o located on 4k page o 2 colum row with 2nd column a blob column o the row is a long row with first piece having 1st column on main page, and the 2nd piece having just blob column on overflow page. o before the update there is 0 free space on the overflow page. o the update causes the blob column to expand past 4k Caused by: java.sql.SQLException: nospc.U at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 39 more Caused by: ERROR nospc: nospc.U at org.apache.derby.impl.store.raw.data.StoredPage.logRow(StoredPage.java:4155) at org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDataToBuffer(UpdateOperation.java:255) at org.apache.derby.impl.store.raw.data.UpdateOperation.init(UpdateOperation.java:106) at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:80) at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8625) at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1062) at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:486) at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523) at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:569) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:264) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1241) ... 33 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4917) zero byte dbex.lck file can cause dual boot warning saying Severe and non-recoverable corruption can result and may have already occurred.
[
https://issues.apache.org/jira/browse/DERBY-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-4917:
--
Attachment: ExLockFile.java
SimpleConnect.java
Here are a couple of small programs for diagnosing the problem that I asked the
user to run.,
The first program SimpleConnect, makes a connection to the database and checks
the size of the lock file created.
It should be run as
java SimpleConnect path to database
The System.out output should be captured and returned along with the derby.log.
On my system the output is:
$ java SimpleConnect /u/kmarsd/repro/lockwarn/wombat
dbex.lck exists and is length:4
Rename dbex.lck to dbex.lck.sav with f.renameTo
Connection successfully madeorg.apache.derby.impl.jdbc.embedconnectio...@1023687
94 (XID = 40), (SESSIONID = 0), (DATABASE = /u/kmarsd/repro/lockwarn/wombat), (D
RDAID = null)
length of dbex.lck file:4
I expect on the user machine the dbex.lck file will be of length 0 which will
narrow the problem outside of the applicatoin to just Derby. If it shows
length 4 then something in the application environment must be influencing
the locking.
Assuming the length shows 0 with SimpleConnect, the second program has just the
lock file creation and locking code:
run like
java ExLockFile path to db
The output on my system is:
java ExLockFile /u/kmarsd/repro/lockwarn/wombat
/u/kmarsd/repro/lockwarn/wombat exists. Attempt exclusive lock
create file succeded. validExclusiveLock=true
1)lockFileOpen = new RandomAccessFile((File) this, rw)
1) Complete lockFileOpen =java.io.randomaccessf...@44ba44ba
2) lockFileChannel = lockFileOpen.getChannel()
2) Complete lockFileChannel = sun.nio.ch.filechanneli...@51ac51ac
3) dbLock = LockFileChannel.tryLock()
3) Complete dbLock = sun.nio.ch.FileLockImpl[0:9223372036854775807 exclusive val
id]
lockFileOpen.writeInt(EXCLUSIVE_FILE_LOCK)
writeIntSuccessful
lockFileChannel.force(true)
lockChannel.force(true) successful
status = EXCLUSIVE_FILE_LOCK
Lock status is:1-EXCLUSIVE_FILE_LOCK
f.length() = 4
I am thinking maybe at the site we will see an IOException or some sort of
other clue.
zero byte dbex.lck file can cause dual boot warning saying Severe and
non-recoverable corruption can result and may have already occurred.
---
Key: DERBY-4917
URL: https://issues.apache.org/jira/browse/DERBY-4917
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.1.2.1
Environment: z/OS
E205{S000EKA} java -version
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-
20100215 (SR
11 FP1 ))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-
20100127a
(JIT enabled)
J9VM - 20100122_52103_bHdSMr
JIT - 20091016_1845ifx1_r8
GC - 20091026_AA)
JCL - 20100215
Derby 10.2.2.1 - (815839)
Reporter: Kathey Marsden
Attachments: ExLockFile.java, SimpleConnect.java
User reports the following warning booting Derby 10.2 with JDK 1.5 SR11 FP1
on z/OS.
ij connnect 'jdbc:derby:wombat';
IJ ERROR: Unable to establish connection
ij connect 'jdbc:derby:wombat';
WARNING: Derby (instance c013800d-012c-8027-19b4-00037b18) is attempting
to
boot the database snip dbname even though Derby (instance c0
13800d-012c-74ae-07c3-000af3f0) may still be active. Only one instance
of D
erby should boot a database at a time. Severe and non-recoverable corruption
can
result and may have already occurred.
The dbex.lck file is zero length. The code seems to indicate in
DirFile4.getExclusiveLock() that a zero length dbex.lck file is possible if
the product is booted with less than JDK 1.4 and Derby should show the
warning under these circumstances, but investigation shows that even if the
dbex,lck file is removed it is recreated with zero length using JDK 1.5.
So there seem to be two issues.
1) dbex.lck is somehow getting created with zero length with JDK 1.5 on this
machine with JDK 1.5 SR11 FP1.
2) We have this logic pertaining to JDK 1.3.1 in the product that probably
can be removed and perhaps masks a real exclusive locking problem that
perhaps should
[jira] Updated: (DERBY-4923) update of a long row can fail with ERROR nospc: nospc.U exception.
[ https://issues.apache.org/jira/browse/DERBY-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-4923: -- Attachment: derby.log derby4923repro.diff derby4923repro.diff is a repro of the bug in the form of a junit test to be run from the codeline. The attached derby.log shows the result from running it against a sane build. update of a long row can fail with ERROR nospc: nospc.U exception. -- Key: DERBY-4923 URL: https://issues.apache.org/jira/browse/DERBY-4923 Project: Derby Issue Type: Bug Affects Versions: 10.5.3.0, 10.6.1.0, 10.6.2.1 Reporter: Mike Matrigali Assignee: Mike Matrigali Attachments: derby.log, derby4923repro.diff An update of a row fails with a nospc.U exception. If there is space on the disk then an update should never fail for a space issue. The code is meant to always reserve enough space on a page such that if an expanding update happens that does not fit, it should in the worst case change the row to an overflow row pointer and put the rest in a linked overflow chain. The following set of circumstances will cause this bug (not sure which are exactly needed - just what i did to cause the repro), I will be attaching a test case: The row being updated has the following characteristics: o located on 4k page o 2 colum row with 2nd column a blob column o the row is a long row with first piece having 1st column on main page, and the 2nd piece having just blob column on overflow page. o before the update there is 0 free space on the overflow page. o the update causes the blob column to expand past 4k Caused by: java.sql.SQLException: nospc.U at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 39 more Caused by: ERROR nospc: nospc.U at org.apache.derby.impl.store.raw.data.StoredPage.logRow(StoredPage.java:4155) at org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDataToBuffer(UpdateOperation.java:255) at org.apache.derby.impl.store.raw.data.UpdateOperation.init(UpdateOperation.java:106) at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:80) at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8625) at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1062) at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:486) at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523) at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:569) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:264) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1241) ... 33 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-4924) o.a.d.client.am not exported in OSGi manifest
o.a.d.client.am not exported in OSGi manifest - Key: DERBY-4924 URL: https://issues.apache.org/jira/browse/DERBY-4924 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.6.2.1 Reporter: Carl Hall When calling ClientDataSource.setSsl(String), o.a.d.client.am.SqlException can be thrown but o.a.d.client.am is not exported in the OSGi manifest. Either o.a.d.client.am needs to be exported or this exception needs to be moved to an exported package (only o.a.d.jdbc is currently exported). Workaround: catch java.lang.Exception so that the class loader doesn't try to load o.a.d.client.am. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4856) Add thread dump information when derby crash
[ https://issues.apache.org/jira/browse/DERBY-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lily Wei updated DERBY-4856: Attachment: DERBY-4856-part_1_1a.diff Thanks to Kathey, due to the scope of the changes, I would like to purpose three steps check-in to address this issue : I. 1.1. Move ThreadDump.java from java/shared/org/apache/derby/shared/common/sanity to java/shard/org/apache/derby/shared/common/error 1.2. move dumpThreads method from AssertFailure to ExceptionUtil II. 2.1 Add ThreadDump information to sane build in ContextManager. cleanupOnError(). it will print the thread dump information to derby.log III. 3.1 Add file handling as Bryan and Kristian's suggestion for ThreadDump info. The current thinking is to add the file handling code as the method as utility tool and calls it in ContextManager I am attaching DERBY-4856-part_1_1a.diff for code review. The patching is covering the part one change. I am running Suites.All and derbyall now. Add thread dump information when derby crash Key: DERBY-4856 URL: https://issues.apache.org/jira/browse/DERBY-4856 Project: Derby Issue Type: Bug Components: Services Reporter: Lily Wei Priority: Minor Attachments: corruptdb.zip, derby-4856-1a.diff, DERBY-4856-part_1_1a.diff, derby.log On system crash or session ending error, Derby should dump as much information as possible. Such as: forcing a javacore if possible or at least thread dump and system environment information. This should only occur if a running session crashes not on boot error due to fail recovery etc. The IBM jvm provides a way to programmatically dump a javacore. i.e. com.ibm.jvm.Dump.JavaDump() And, the SUN jvm will force a thread dump using the Unsafe class and there may be a better way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-4856) Add thread dump information when derby crash
[ https://issues.apache.org/jira/browse/DERBY-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lily Wei reassigned DERBY-4856: --- Assignee: Lily Wei Add thread dump information when derby crash Key: DERBY-4856 URL: https://issues.apache.org/jira/browse/DERBY-4856 Project: Derby Issue Type: Bug Components: Services Reporter: Lily Wei Assignee: Lily Wei Priority: Minor Attachments: corruptdb.zip, derby-4856-1a.diff, DERBY-4856-part_1_1a.diff, derby.log On system crash or session ending error, Derby should dump as much information as possible. Such as: forcing a javacore if possible or at least thread dump and system environment information. This should only occur if a running session crashes not on boot error due to fail recovery etc. The IBM jvm provides a way to programmatically dump a javacore. i.e. com.ibm.jvm.Dump.JavaDump() And, the SUN jvm will force a thread dump using the Unsafe class and there may be a better way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
