[jira] [Updated] (DERBY-5691) Document that Write Caching must be disabled to avoid possible database corruption
[ https://issues.apache.org/jira/browse/DERBY-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5691: -- Summary: Document that Write Caching must be disabled to avoid possible database corruption (was: Recommend disabling Write Caching for on Windows) Document that Write Caching must be disabled to avoid possible database corruption Key: DERBY-5691 URL: https://issues.apache.org/jira/browse/DERBY-5691 Project: Derby Issue Type: Improvement Components: Documentation Environment: Microsoft Windows Reporter: Stan Bradbury Labels: Write_caching Suggestion that we document a recommendation that Windows Write Caching be disabled on machines using Derby. The following article warns about Write Caching on Windows as a possbile source of database corruption: http://support.microsoft.com/kb/281672 It is possible that this could be the cause of some unexplained Derby corruptions identified after power failure of other system interupt. Links explaining how to disable Write Caching: Win 2K: http://support.microsoft.com/kb/259716 Win 2008: http://support.microsoft.com/kb/324805 From the Windows 2008 article: With some third-party programs, disk write caching has to be turned on or off. Additionally, turning disk write caching on may increase operating system performance; however, it may also result in the loss of information if a power failure, equipment failure, or software failure occurs. This article describes how to turn disk write caching on or off. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5207) Fix the description of Derby's stored page format, found on the web site.
[ https://issues.apache.org/jira/browse/DERBY-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5207: -- Issue fix info: Newcomer,Patch Available (was: Newcomer) Fix the description of Derby's stored page format, found on the web site. - Key: DERBY-5207 URL: https://issues.apache.org/jira/browse/DERBY-5207 Project: Derby Issue Type: Improvement Components: Web Site Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Mohamed Nufail Attachments: DERBY-5207.patch I have found some discrepancies between Derby code and the description of the stored page format found on our web site (http://db.apache.org/derby/papers/pageformats.html): 1) The website correctly says that the page header is 56 bytes long. However, you get 58 bytes if you add up the values in the left column of http://db.apache.org/derby/papers/pageformats.html#storedpage. The extra 2 bytes come from the inclusion of an unsigned short representing % of the page to keep free for updates. That field does not appear in StoredPage.readPageHeader(). The field should be removed from the web site page. 2) That table has an additional problem: the spare for future use (encryption uses to write random bytes here) field is correctly listed as being 4 bytes long (in the left column) but the middle column says that it is a long. That middle column should say that the value is an integer. 3) Although the first 4 bytes of the AllocPage header are devoted to a Formatable ID, the actual Formatable ID only occupies the leading 2 bytes of the page. The next 2 bytes are unused. The first line of the Format of Alloc Page table should note this fact. 4) There is no RECORD_INITIAL bit in the record header status field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4115) Provide a way to drop statistics information
[ https://issues.apache.org/jira/browse/DERBY-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4115: -- Issue fix info: High Value Fix Has this feature never been implemented due to lack of demand, or are there potential issues that haven't been noted in this JIRA? I filed it in response to a specific user case where it would have been helpful. Now with automatic index stat it is more needed. I think it hasn't been picked up before now because folks just haven't had the bandwidth and it is not a bug so doesn't get reviewed often with triage. I think it would be a great addition and am marking it High Value Fix in case anyone finds that inspiring #:) Provide a way to drop statistics information Key: DERBY-4115 URL: https://issues.apache.org/jira/browse/DERBY-4115 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.6.1.0 Reporter: Kathey Marsden Now that DERBY-269 has been resolved, users can update statistics, but once they do, they are committed to using and maintaining the statistics, even if it doesn't improve performance or they have difficulty maintaining the statistics on a regular basis. It would be good to have a way to drop statistics information so that users could revert to the prior behavior if needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5675) on IBM 1.7 20 failures , 190 errors mostly of the variety Java exception: 'sun.misc.Unsafe incompatible with java.util.concurrent.ConcurrentHashMap$HashEntry: java.lang.C
[ https://issues.apache.org/jira/browse/DERBY-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5675: -- Attachment: suites.All.out Attaching the full suites.All output. (emb)store.AccessTest.testReclaimDeletedRowsDuringSplit used 5125 ms E. The root exception is a NullPointer in store. Presumably the database corrupt and cascade failures from there. ) testReclaimDeletedRowsDuringSplit(org.apache.derbyTesting.functionTests.tests.store.AccessTest)java.sql.SQLException: Java exception: 'sun.misc.Unsafe incompatible with java.util.concurrent.ConcurrentHashMap$HashEntry: java.lang.ClassCastException'. 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.derbyTesting.junit.BaseJDBCTestCase.commit(BaseJDBCTestCase.java:376) at org.apache.derbyTesting.functionTests.tests.store.AccessTest.reclaimTest(AccessTest.java:1269) at org.apache.derbyTesting.functionTests.tests.store.AccessTest.testReclaimDeletedRowsDuringSplit(AccessTest.java:1281) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Caused by: java.sql.SQLException: Java exception: 'sun.misc.Unsafe incompatible with java.util.concurrent.ConcurrentHashMap$HashEntry: java.lang.ClassCastException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 47 more Caused by: java.lang.ClassCastException: sun.misc.Unsafe incompatible with java.util.concurrent.ConcurrentHashMap$HashEntry at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:937) at org.apache.derby.impl.services.locks.ConcurrentLockSet.unlock(Unknown Source) at org.apache.derby.impl.services.locks.LockSpace.unlockGroup(Unknown Source) at org.apache.derby.impl.services.locks.AbstractPool.unlockGroup(Unknown Source) at org.apache.derby.impl.services.locks.ConcurrentPool.unlockGroup(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.releaseAllLocks(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.postComplete(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.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) ... 41 more 176)
[jira] [Updated] (DERBY-5676) Database cannot to started
[
https://issues.apache.org/jira/browse/DERBY-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5676:
--
Attachment: db.tar
Here is a tarred database which might be more convenient on other platforms.
I see the NullPointerException on both z/os and windows connecting to this
database.
Database cannot to started
--
Key: DERBY-5676
URL: https://issues.apache.org/jira/browse/DERBY-5676
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.5.3.0
Environment: Operating System: Z/OS version
These are some of the OS properties.
0SYSTEM PROPERTIES:
java.vendor=IBM Corporation
os.name=z/OS
java.vm.specification.vendor=Sun Microsystems Inc.
java.runtime.version=pmz3160_26sr1-2014_01 (SR1)
user.language=en
java.version=1.6.0
user.timezone=America/New_York
sun.arch.data.model=32
com.ibm.zero.version=2
java.endorsed.dirs=/HO43/Vantagegmi/runtime/apache-tomcat-6.0.20/common/endorsed
com.ibm.oti.vm.library.version=26
sun.jnu.encoding=IBM-1047
jxe.current.romimage.version=17
package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.,sun.beans.
file.separator=/
java.specification.name=Java Platform API Specification
java.class.version=50.0
user.country=US
java.home=/tfsjava/J6.0
java.vm.info=JRE 1.6.0 z/OS s390-31 2013_94967 (JIT enabled, AOT
enabled)
J9VM - R26_Java626_SR1_2013_1649_B94967
JIT - r11_20111028_21230
GC - R26_Java626_SR1_2013_1649_B94967
J9CL - 2013_94967
os.version=01.13.00
ibm.serversocket.recover=true
java.awt.fonts=
path.separator=:
java.vm.version=2.6
java.util.prefs.PreferencesFactory=java.util.prefs.FileSystemPreferencesFactory
user.variant=
java.awt.printerjob=sun.print.PSPrinterJob
sun.io.unicode.encoding=UnicodeBig
awt.toolkit=sun.awt.X11.XToolkit
ibm.signalhandling.sigint=true
java.assistive=ON
package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.
java.naming.factory.url.pkgs=org.apache.naming
user.home=/HO43/tmp
com.ibm.cpu.endian=big
java.specification.vendor=Sun Microsystems Inc.
ibm.signalhandling.sigchain=false
sun.security.policy.utf8=false
java.library.path=/tfsjava/J6.0/lib/s390/default:/tfsjava/J6.0/lib/s390:/tfsjava/J6.0/lib/s390/default:/lib:/usr/lib:/tfsjava/J6
.0/bin:/tfsjava/J6.0/bin/classic::/tfsjava/J6.0/lib/s390/default:/tfsjava/J6.0/lib/s390
java.vendor.url=http://www.ibm.com/
java.vm.vendor=IBM Corporation
platform.notASCII=true
common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar
java.fullversion=JRE 1.6.0 IBM J9 2.6 z/OS s390-31 2013_94967 (JIT
enabled, AOT enabled)
J9VM - R26_Java626_SR1_2013_1649_B94967
JIT - r11_20111028_21230
GC - R26_Java626_SR1_2013_1649_B94967
J9CL - 2013_94967
java.runtime.name=Java(TM) SE Runtime Environment
java.class.path=/tfsjava/J6.0/lib/tools.jar:/HO43/Vantagegmi/runtime/apache-tomcat-6.0.20/bin/bootstrap.jar:/HO43/Vantagegmi/run
time/apache-tomcat-6.0.20/bin/commons-logging-api.jar:
java.vm.specification.name=Java Virtual Machine Specification
java.vm.specification.version=1.0
sun.cpu.endian=big
ibm.system.encoding=IBM-1047
os.arch=s390
java.vm.name=IBM J9 VM
com.ibm.oti.shared.enabled=false
com.ibm.vm.bitmode=32
file.encoding=ISO8859-1
Reporter: Ambili
Priority: Blocker
Attachments: db.pax.Z, db.tar, derby.log
The install is created on a HFS file system. And we create DB using this
command
java -cp . -jar derbyrun.jar ij databaseAuth.sql
and databaseAuth.sql content is given below.
connect 'jdbc:derby:
/HO43/Vantagegmi/webclientdb/VantageDb;create=true;dataEncryption=true;bootPassword=Password;encryptionAlgorithm=AES/CBC/NoPadding;';
-- CREATE USER_CREDENTIALS TABLE WITH PRIMARY KEY OF USERNAME
-- STEP 2
CREATE TABLE USER_CREDENTIALS
(
USERNAME VARCHAR(30) NOT NULL,
PASSWORD VARCHAR(30) NOT NULL,
PRIMARY KEY (USERNAME)
);
-- INSERT USER INTO USER_CREDENTIALS TABLE
-- STEP 3
INSERT INTO USER_CREDENTIALS VALUES('APP', 'Password');
EXIT;
Create was successful. But when we try
[jira] [Updated] (DERBY-5671) NsTest does not run on trunk do multiple issues stemming from concurrency improvements
[ https://issues.apache.org/jira/browse/DERBY-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5671: -- Description: As I understand it at least since September 30 of last year, the system test NsTest has been broken on trunk. In these six months the test has not been runnable, so we do not know if new issues have been introduced with sequence generators or most importantly with auto-increment columns that are now based on them, which many, many applications rely upon. Even if the known problems are fixed later in the 10.9 release cycle and new problems are exposed, we won't be able to go back to any point in time to discover when they might be released. In 10.8 we coped with this problem by backing out the concurrency improvements (DERBY-5448) pending fixes for DERBY-5422, DERBY-5454, DERBY-5430. Currently none of those issues have been assigned. Since this has been going on now for six months, I think we urgently need to stabiliize auto-increment columns and get this test running again on trunk. I can see three possible options. 1) Someone with interest assign themselves to these issues and make significant progress over the next few weeks. 2) Make the concurrency improvements optional with a property which defaults to false (I don't know if this is practical) 3) Back the concurrency performance improvements out of trunk until these issues have been resolved and the change can be resubmitted. I realize that NsTest is not the easiest test to work with but it does seem to have found serious problems with generated columns that I think users are likely to hit. In the past, a similiar disregard for mailjdbc exposing a corruption issue meant that we actually released a bad corruption issue that I know hit many users of Derby before we addressed it. Autoincrement is widely, widely, used. We need to get it stabilized and the test running on trunk. Although the system tests are not particularly easy to deal with, they are all we have and they do find issues. was: As I understand it at least since September 30 of last year, the system test NsTest has been broken on trunk. In these six months the test has not been runnable, so we do not know if new issues have been introduced with sequence generators or most importantly with auto-increment columns that are now based on them, which many, many applications rely upon. Even if the known problems are fixed later in the 10.9 release cycle and new problems are exposed, we won't be able to go back to any point in time to discover when they might be released. In 10.8 we coped with this problem by backing out the concurrency improvements (DERBY-4448) pending fixes for DERBY-5422, DERBY-5454, DERBY-5430. Currently none of those issues have been assigned. Since this has been going on now for six months, I think we urgently need to stabiliize auto-increment columns and get this test running again on trunk. I can see three possible options. 1) Someone with interest assign themselves to these issues and make significant progress over the next few weeks. 2) Make the concurrency improvements optional with a property which defaults to false (I don't know if this is practical) 3) Back the concurrency performance improvements out of trunk until these issues have been resolved and the change can be resubmitted. I realize that NsTest is not the easiest test to work with but it does seem to have found serious problems with generated columns that I think users are likely to hit. In the past, a similiar disregard for mailjdbc exposing a corruption issue meant that we actually released a bad corruption issue that I know hit many users of Derby before we addressed it. Autoincrement is widely, widely, used. We need to get it stabilized and the test running on trunk. Although the system tests are not particularly easy to deal with, they are all we have and they do find issues. NsTest does not run on trunk do multiple issues stemming from concurrency improvements --- Key: DERBY-5671 URL: https://issues.apache.org/jira/browse/DERBY-5671 Project: Derby Issue Type: Bug Components: SQL Reporter: Kathey Marsden Priority: Critical As I understand it at least since September 30 of last year, the system test NsTest has been broken on trunk. In these six months the test has not been runnable, so we do not know if new issues have been introduced with sequence generators or most importantly with auto-increment columns that are now based on them, which many, many applications rely upon. Even if the known problems are fixed later in the 10.9 release cycle and new problems are exposed, we
[jira] [Updated] (DERBY-2515) Network client does not retain the INOUT parameter value change for subsequent execution
[ https://issues.apache.org/jira/browse/DERBY-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2515: -- Affects Version/s: (was: 10.5.3.0) 10.3.1.4 Fix Version/s: 10.7.1.4 10.6.2.3 10.5.3.2 Assignee: Rick Hillegas (was: Kathey Marsden) Reassigning to Rick and resolving. Also restoring the affects version. This was accidentally changed with the bulk reopen. I had intended to add 10.5 as an affects version but unfortunately that replaced what was there. Network client does not retain the INOUT parameter value change for subsequent execution Key: DERBY-2515 URL: https://issues.apache.org/jira/browse/DERBY-2515 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Reporter: Kathey Marsden Assignee: Rick Hillegas Priority: Minor Labels: derby_triage10_8 Fix For: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.1.2 Attachments: Test_2515.java, derby-2515-01-ac-copyINOUTreturnValues.diff, derby-2515-02-aa-polishCatchBlock.diff If I set a INOUT parameter to a value (say 12.3) and it gets modified by the procedure to another value (say 45.6) then on the next execution of the same CallableStatement, embedded maintains the current value (45.6), while network server reverts to the former value (12.3). This issue was found while converting the test lang/procedure.java. See references to this issue in the converted LangProcedureTest.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4275) Query executions fail when compressing a table using SYSCS_UTIL.SYSCS_COMPRESS_TABLE
[ https://issues.apache.org/jira/browse/DERBY-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4275: -- Affects Version/s: 10.3.3.0 10.4.1.3 Bug behavior facts: Crash,Seen in production (was: Crash) This was reported by a user 10.3. Updating affects version Query executions fail when compressing a table using SYSCS_UTIL.SYSCS_COMPRESS_TABLE Key: DERBY-4275 URL: https://issues.apache.org/jira/browse/DERBY-4275 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.3.0 Reporter: Sai Pullabhotla Assignee: Mike Matrigali Labels: derby_triage10_5_2 Fix For: 10.8.2.2, 10.9.0.0 Attachments: CompressDBTest1.java, CompressDBTest2.java, D4275.java, d4275-1a.diff, invalidate-after.diff, invalidation-during-compilation.diff, npe.diff Query executions (SELECT and/or UPDATE) fail with serious exceptions while the table is being compressed using SYSCS_UTIL.SYSCS_COMPRESS_ TABLE. The compression eventually finishes normally, but the queries keep failing with the same error until the database is rebooted. More information about this can be found on the Derby mailing list at http://www.nabble.com/Issue-with-SYSCS_UTIL.SYSCS_COMPRESS_-TABLE-td23892893.html. The exception stacktrace is below: Caused by: java.sql.SQLException: The conglomerate (71,409) requested does not exist. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(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.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source) at org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93) ... 25 more Caused by: ERROR XSAI2: The conglomerate (71,409) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) at org.apache.derby.impl.store.access.BackingStoreHashTableFromScan.init(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.createBackingStoreHashtableFromScan(Unknown Source) at org.apache.derby.impl.sql.execute.HashScanResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.JoinResultSet.openRight(Unknown Source) at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.UnionResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.SortResultSet.getRowFromResultSet(Unknown Source) at org.apache.derby.impl.sql.execute.SortResultSet.getNextRowFromRS(Unknown Source) at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown Source) at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] [Updated] (DERBY-3870) Concurrent Inserts of rows with XML data results in an exception
[ https://issues.apache.org/jira/browse/DERBY-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3870: -- Labels: derby_backport_reject_10_7 (was: derby_triage10_5_2) Concurrent Inserts of rows with XML data results in an exception Key: DERBY-3870 URL: https://issues.apache.org/jira/browse/DERBY-3870 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.1.3, 10.4.2.1, 10.5.2.0, 10.6.1.0 Environment: System: MS windows server 2003 standard edition service pack 2. Derby is run as a server on port 1527. Reporter: Royi Ronen Assignee: Knut Anders Hatlen Labels: derby_backport_reject_10_7 Fix For: 10.8.2.2, 10.9.0.0 Attachments: Copy of derby.log, DerbyMultiInsertXmlException.zip, d3870-1a.diff, d3870-1a.stat, d3870-2a.diff, d3870-3a.diff, d3870-3a.stat, d3870-junit.diff, upgrade-with-test.diff, upgrade.diff We insert rows into a table using the following prepared statement (through JDBC): INSERT INTO USER1.PSTORE values(?,?, XMLPARSE(document CAST (? AS CLOB) preserve whitespace)) where each of the ?'s are replaced with a string. One thread runs fine. Two or more result in the following exception: org.apache.derby.client.am.SqlException: Java exception: 'FWK005 parse may not be called while parsing.: org.xml.sax.SAXException'. at org.apache.derby.client.am.SqlException.init(Unknown Source) at org.apache.derby.client.am.SqlException.init(Unknown Source) We believe that this comes from the dBuilder.parse(InputSource) method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4779) NPE while inserting into a table which has a generated column and an insert trigger
[ https://issues.apache.org/jira/browse/DERBY-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4779: -- Attachment: derby-4779_10_5_diff.txt 10.5 required manual merge. Attaching patch derby-4779_10_5_diff.txt NPE while inserting into a table which has a generated column and an insert trigger --- Key: DERBY-4779 URL: https://issues.apache.org/jira/browse/DERBY-4779 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.5.3.0, 10.6.1.0, 10.7.1.1 Reporter: Rick Hillegas Assignee: Kathey Marsden Labels: derby_triage10_8 Fix For: 10.8.2.2, 10.9.0.0 Attachments: d4779.diff, d4779.diff, derby-4779_10_5_diff.txt, test1.diff, testreport.txt The following script generates an NPE on the concluding insert: connect 'jdbc:derby:memory:dummy;create=true'; create function getRegion( v int ) returns varchar( 20 ) language java parameter style java deterministic no sql external name 'java.lang.Integer.toString' ; create table orders ( orderID bigint primary key, salesPrice int not null, region generated always as ( getRegion( salesPrice ) ) ) ; create table dummy( a int ); create trigger newOrderTrigger after insert on orders for each row insert into dummy( a ) values ( 1 ) ; insert into orders( orderID, salesPrice ) values ( 1, 2 ) ; Here is the NPE: java.lang.NullPointerException at org.apache.derby.impl.sql.execute.DMLWriteResultSet.objectifyStreams(Unknown Source) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-3009) Out of memory error when creating a very large table
[ https://issues.apache.org/jira/browse/DERBY-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3009: -- Attachment: derby-3009_10_5_diff.txt 10.5 had to be merged manually. Attaching patch derby-3009_10_5_diff.txt Out of memory error when creating a very large table Key: DERBY-3009 URL: https://issues.apache.org/jira/browse/DERBY-3009 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.5.3.0 Environment: Win XP Pro Reporter: Nick Williamson Assignee: Kathey Marsden Labels: derby_triage10_5_2 Fix For: 10.8.1.2 Attachments: DERBY-3009.zip, derby-3009-1a.diff, derby-3009-1b.diff, derby-3009_10_5_diff.txt When creating an extremely large table (c.50 indexes, c.50 FK constraints), IJ crashes with an out of memory error. The table can be created successfully if it is done in stages, each one in a different IJ session. From Kristian Waagan: With default settings on my machine, I also get the OOME. A brief investigation revealed a few things: 1) The OOME occurs during constraint additions (with ALTER TABLE ... ADD CONSTRAINT). I could observe this by monitoring the heap usage. 2) The complete script can be run by increasing the heap size. I tried with 256 MB, but the monitoring showed usage peaked at around 150 MB. 3) The stack traces produced when the OOME occurs varies (as could be expected). 4) It is the Derby engine that produce the OOME, not ij (i.e. when I ran with the network server, the server failed). I have not had time to examine the heap content, but I do believe there is a bug in Derby. It seems some resource is not freed after use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5584) Select statement with subqueries with group by and count distinct statements returns wrong number of results
[ https://issues.apache.org/jira/browse/DERBY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5584: -- Fix Version/s: 10.8.2.3 merged to 10.8 with revision 1300625 Select statement with subqueries with group by and count distinct statements returns wrong number of results Key: DERBY-5584 URL: https://issues.apache.org/jira/browse/DERBY-5584 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.7.1.1 Environment: Output from sysinfo java.specification.name: Java Platform API Specification java.specification.version: 1.6 java.runtime.version: 1.6.0_20-b02 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derby.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbytools.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbynet.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbyclient.jar] 10.7.1.1 - (1040133) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.7.1.1 - (1040133) Found support for locale: [de_DE] version: 10.7.1.1 - (1040133) Found support for locale: [es] version: 10.7.1.1 - (1040133) Found support for locale: [fr] version: 10.7.1.1 - (1040133) Found support for locale: [hu] version: 10.7.1.1 - (1040133) Found support for locale: [it] version: 10.7.1.1 - (1040133) Found support for locale: [ja_JP] version: 10.7.1.1 - (1040133) Found support for locale: [ko_KR] version: 10.7.1.1 - (1040133) Found support for locale: [pl] version: 10.7.1.1 - (1040133) Found support for locale: [pt_BR] version: 10.7.1.1 - (1040133) Found support for locale: [ru] version: 10.7.1.1 - (1040133) Found support for locale: [zh_CN] version: 10.7.1.1 - (1040133) Found support for locale: [zh_TW] version: 10.7.1.1 - (1040133) Reporter: Piotr Zgadzaj Assignee: Bryan Pendleton Labels: derby_triage10_9 Fix For: 10.8.2.3, 10.9.0.0 Attachments: patch1.txt, patch2.txt, query.log, tests.out, tests.sql, try1.txt Steps to reproduce: 1. Create database, connect to database with any JDBC client 2. create two tables: CREATE TABLE TEST_5 ( profile_id INTEGER NOT NULL, group_ref INTEGER NOT NULL, matched_count INTEGER NOT NULL ); CREATE TABLE TEST_6 ( profile_id INTEGER NOT NULL, group_ref INTEGER NOT NULL, matched_count INTEGER NOT NULL ); 3. Insert two records for each table: insert into test_5 values (1, 1,1); insert into test_5 values (2, 1, 2); insert into test_6 values (1, 1,1); insert into test_6 values (2, 1, 2); 4. Run following statement SELECT * FROM (SELECT ps1.group_ref, COUNT(DISTINCT ps1.matched_count) AS matched_count FROM test_5 ps1 GROUP BY ps1.group_ref, ps1.profile_id ) a, (SELECT ps2.group_ref, COUNT( DISTINCT ps2.matched_count) AS matched_count FROM test_6 ps2 GROUP BY ps2.group_ref, ps2.profile_id ) b As a result I've got 3 records instead of 4 - at least Oracle 10g returns 4 records for this statement. Maybe i'm doing something wrong. Do you have any suggestions / possible workarounds for this problem -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5584) Select statement with subqueries with group by and count distinct statements returns wrong number of results
[ https://issues.apache.org/jira/browse/DERBY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5584: -- Affects Version/s: 10.6.2.3 Labels: derby_backport_reject_10_5 derby_triage10_9 (was: derby_triage10_9) This issue probably affects 10.6 and 10.7 as the ROLLUP work went into 10.6, It would be a good candidate to backport to those releases, but does not affect 10.5 so labeling derby_backport_reject_10_5 Select statement with subqueries with group by and count distinct statements returns wrong number of results Key: DERBY-5584 URL: https://issues.apache.org/jira/browse/DERBY-5584 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.2.3, 10.7.1.1 Environment: Output from sysinfo java.specification.name: Java Platform API Specification java.specification.version: 1.6 java.runtime.version: 1.6.0_20-b02 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derby.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbytools.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbynet.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbyclient.jar] 10.7.1.1 - (1040133) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.7.1.1 - (1040133) Found support for locale: [de_DE] version: 10.7.1.1 - (1040133) Found support for locale: [es] version: 10.7.1.1 - (1040133) Found support for locale: [fr] version: 10.7.1.1 - (1040133) Found support for locale: [hu] version: 10.7.1.1 - (1040133) Found support for locale: [it] version: 10.7.1.1 - (1040133) Found support for locale: [ja_JP] version: 10.7.1.1 - (1040133) Found support for locale: [ko_KR] version: 10.7.1.1 - (1040133) Found support for locale: [pl] version: 10.7.1.1 - (1040133) Found support for locale: [pt_BR] version: 10.7.1.1 - (1040133) Found support for locale: [ru] version: 10.7.1.1 - (1040133) Found support for locale: [zh_CN] version: 10.7.1.1 - (1040133) Found support for locale: [zh_TW] version: 10.7.1.1 - (1040133) Reporter: Piotr Zgadzaj Assignee: Bryan Pendleton Labels: derby_backport_reject_10_5, derby_triage10_9 Fix For: 10.8.2.3, 10.9.0.0 Attachments: patch1.txt, patch2.txt, query.log, tests.out, tests.sql, try1.txt Steps to reproduce: 1. Create database, connect to database with any JDBC client 2. create two tables: CREATE TABLE TEST_5 ( profile_id INTEGER NOT NULL, group_ref INTEGER NOT NULL, matched_count INTEGER NOT NULL ); CREATE TABLE TEST_6 ( profile_id INTEGER NOT NULL, group_ref INTEGER NOT NULL, matched_count INTEGER NOT NULL ); 3. Insert two records for each table: insert into test_5 values (1, 1,1); insert into test_5 values (2, 1, 2); insert into test_6 values (1, 1,1); insert into test_6 values (2, 1, 2); 4. Run following statement SELECT * FROM (SELECT ps1.group_ref, COUNT(DISTINCT ps1.matched_count) AS matched_count FROM test_5 ps1 GROUP BY ps1.group_ref, ps1.profile_id ) a, (SELECT ps2.group_ref, COUNT( DISTINCT ps2.matched_count) AS matched_count FROM test_6 ps2 GROUP BY ps2.group_ref, ps2.profile_id ) b As a result I've got 3 records instead of 4 - at least Oracle 10g returns 4 records for this statement. Maybe i'm doing something wrong. Do you have any suggestions / possible workarounds for this problem -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4617) Sysinfo.testSysinfoLocale failed with IB47 M 1.6 on Windows 7 64bit
[ https://issues.apache.org/jira/browse/DERBY-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4617: -- Fix Version/s: 10.5.3.1 This issue has already been fixed in 10.5. Adjusting the fixVersion Sysinfo.testSysinfoLocale failed with IB47 M 1.6 on Windows 7 64bit --- Key: DERBY-4617 URL: https://issues.apache.org/jira/browse/DERBY-4617 Project: Derby Issue Type: Bug Components: Localization Affects Versions: 10.5.3.0 Reporter: Lily Wei Assignee: Kathey Marsden Priority: Minor Labels: derby_triage10_5_2 Fix For: 10.5.3.1, 10.6.2.3, 10.7.1.4, 10.8.2.2, 10.9.0.0 Attachments: derby-4617_try_diff.txt, derby.log Sysinfo.testSysinfoLocale failed with IB47 M 1.6 on Windows 7 64bit. This is the exception from running the test: 1) testSysinfoLocale(org.apache.derbyTesting.functionTests.tests.derbynet.SysinfoTest)junit.framework.AssertionFailedError: expected:14 but was:1 at org.apache.derbyTesting.functionTests.tests.derbynet.SysinfoTest.assertMatchingStringExists(SysinfoTest.java:322) at org.apache.derbyTesting.functionTests.tests.derbynet.SysinfoTest.testSysinfoLocale(SysinfoTest.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109) When running with SysinfoTest along, you will see the following error: ...before sed 2010-04-16 22:14:49.289 GMT : Ung?ltige Antwort von Network Server: Keine ausrei chenden Daten. after sed 2010-04-16 22:14:49.289 GMT : Ung?ltige Antwort von Network Server: Keine ausrei chenden Daten. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4319) hang in suites.all with ibm 1.5 on AIX after ttestDefaultProperties
[ https://issues.apache.org/jira/browse/DERBY-4319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4319: -- Labels: derby_backport_reject_10_5 (was: derby_triage10_8) hang in suites.all with ibm 1.5 on AIX after ttestDefaultProperties --- Key: DERBY-4319 URL: https://issues.apache.org/jira/browse/DERBY-4319 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.5.2.0 Environment: ibm jvm 1.5 SR9-0 on IBM AIX 3.5 Reporter: Myrna van Lunteren Assignee: Kathey Marsden Labels: derby_backport_reject_10_5 Fix For: 10.8.1.2 Attachments: LaunchedNetworkServer.javacore.20110309.160148.6488248.0001.txt, LaunchedNetworkServerAfterPing.javacore.20110310.124948.6488248.0002.txt, TestOutput2011-03-09.txt, TestProcess.javacore.20110310.123703.4390978.0001.txt, derby-4317_timeout_for_complete_diff.txt, derby-4319_disableSetPortPriorityAndDefaultProperties_diff.txt, derby-4319_disable_setPortPriorty_diff.txt, derby-4319_teardown_kill_on_bad_ping.txt, javacore.20090723.093837.25380.0001.txt, javacore.20090723.093909.24726.0001.txt The test run for 10.5.2.0 hung in suites.All. The console output (the run was with -Dderby.tests.trace=true) showed ttestDefaultProperties had successfully completed but the run was halted. ps -eaf | grep java showed the process that kicked off suites.All, and a networkserver process with the following flags: - classpath classpath including derby.jar, derbytools.jar, derbyclient.jar, derbynet.jar, derbyTesting.jar, derbyrun.jar, derbyTesting.jar and junit.jar -Dderby.drda.logConnections= -Dderby.drda.traceAll= -Dderby.drda.traceDirectory= -Dderby.drda.keepAlive= -Dderby.drda.timeSlice= -Dderby.drda.host= -Dderby.drda.portNumber= -derby.drda.minThreads= -Dderby.drda.maxThreads= -Dderby.drda.startNetworkServer= -Dderby.drda.debug= org.apache.derby.drda.NetworkServerControl start -h localhost -p 1527 This process had been sitting for 2 days. After killing the NetworkServerControl process, the test continued successfully (except for DERBY-4186, fixed in trunk), but the following was put out to the console: START-SPAWNED:SpawnedNetworkServer STANDARD OUTPUT: exit code=137 2009-07-18 03:16:07.157 GMT : Security manager installed using the Basic server security policy. 2009-07-18 03:16:09.169 GMT : Apache Derby Network Server - 10.5.2.0 - (794445) started and ready to accept connections on port 1527 END-SPAWNED :SpawnedNetworkServer STANDARD OUTPUT: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5271) Client may hang if the server crashes due to a java.lang.Error
[ https://issues.apache.org/jira/browse/DERBY-5271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5271: -- Affects Version/s: 10.1.3.1 10.2.2.0 10.3.3.0 10.4.2.0 10.5.3.0 10.6.2.1 10.7.1.1 10.8.1.2 Client may hang if the server crashes due to a java.lang.Error -- Key: DERBY-5271 URL: https://issues.apache.org/jira/browse/DERBY-5271 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.9.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.8.2.2, 10.9.0.0 Attachments: derby-5271-1a-inital_fix_proposal.diff When certain types of errors are raised while the network server is processing a client request, the server is left in a semi-degraded state. The problem this issue is concerned with, is that the client socket is kept open even though the server in a kind of degraded state (server JVM still alive). This causes the client to hang, until the server JVM is killed, in a read-call on the socket. I'm able to reproduce this with an OOME being raised on the server. In my opinion, hanging when there is no chance of progression is bad behavior. Furthermore, it causes trouble for automated testing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-1016) javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
[
https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-1016:
--
Issue fix info: High Value Fix,Known fix,Newcomer,Release Note
Needed,Repro attached (was: Repro attached,Newcomer,Known fix,High Value Fix)
Labels: derby_backport_reject_10_8 derby_triage10_5_2 (was:
derby_triage10_5_2)
Although a behavior correction, this is a behavior change so I think needs a
release note and is probably not appropriate for backport.
javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of
XA_PROTO on a prepared transaction
--
Key: DERBY-1016
URL: https://issues.apache.org/jira/browse/DERBY-1016
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.1.3.1, 10.2.1.6
Reporter: Kathey Marsden
Assignee: Jayaram Subramanian
Labels: derby_backport_reject_10_8, derby_triage10_5_2
Fix For: 10.9.0.0
Attachments: DERBY-1016.diff, DERBY-1016.patch, DERBY-1016.patch,
DERBY-1016_Patch_1.diff, ReproDerby1016.java, derby1016-donotcommit.diff,
derby1016-stat.txt, runoutputNov30.out, utilXid.java
javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of
XA_PROTO on a prepared transaction
I posted a question to derby-dev about this and heard no response so am
assuming it is indeed a bug.
in the XA+
specification, it seems like xa_forget should only be valid for a
heuristically completed transaction, so should be XAER_PROTO
and not XAER_NOTA.
In xaStateTran.sql we have this case:
-- get back into prepared state
xa_start xa_noflags 50;
insert into xastate values(2);
xa_end xa_success 50;
xa_prepare 50;
select * from global_xactTable where gxid is not null order by gxid;
-- the following should error XAER_NOTA
xa_forget 50;
The user code I am looking at handles forget like this. They expect
XAER_PROTO in this case.
try {
xaRes.forget(xidList[i]);
System.out.print(XA-Transaction [ + (i+1) + ]
Forgotten. \n );
} catch (XAException XAeForget) {
if ( XAeForget.errorCode ==
XAException.XAER_PROTO ) {
System.out.print(XA-Transaction [ + (i+1)
+ ] not heuristically completed yet - Rolling Back instead. \n );
xaRes.rollback(xidList[i]);
System.out.print(XA-Transaction [ + (i+1)
+ ] Rolled Back. \n );
}
if ( XAeForget.getMessage() != null ) {
System.out.println(XAException +
XAeForget.getMessage() );
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
[ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5552: -- Fix Version/s: 10.8.2.3 10.7.1.4 10.6.2.2 10.5.3.1 Assignee: Brett Wooldridge (was: Kathey Marsden) I backported the fix and test to 10.5. Reassigning to Brett who provided the code patch. Filed DERBY-5633 for the testing. Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs - Key: DERBY-5552 URL: https://issues.apache.org/jira/browse/DERBY-5552 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2 Environment: Solaris 10, Glassfish V2.1.1, Reporter: Brett Bergquist Assignee: Brett Wooldridge Priority: Blocker Labels: derby_triage10_9 Fix For: 10.5.3.1, 10.6.2.2, 10.7.1.4, 10.8.2.3, 10.9.0.0 Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, ReproDerby5552DB2.java, ReproDerby5552LockTimeout.java, appserverstack.txt, client.tar.Z, derby-5552_withexpanded_test_diff.txt, derby-5552_withtest_diff.txt, derby-5552_withtest_diff.txt, derby.log, derbystackatshutdown.txt, execute.patch, transactionsleft.txt, utilXid.java The issue arrives when multiple XA transactions are done in parallel and there is either a lock timeout or a lock deadlock detected. When this happens the connection is leaked in the Glassfish connection pool and the client thread hangs in org.apache.derby.client.netReply.fill(Reply.java:172). Shutting down the app server fails because the thread has a lock in org.apache.derby.client.net.NetConnection40 and another task is calling org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214) which is waiting for the lock. Killing the appsever using kill and then attempting to shutdown Derby network server causes the Network Server to hang. One of the threads hangs waiting for a lock at org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525) and the main thread has this locked at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242) and it itself is waiting for a lock which belongs to a thread that is stuck at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118) which is in the TIMED_WAITING state. Only by killing the Network Server using kill is possible at this point. There are transactions left even though all clients have been removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
[ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5552: -- Attachment: ReproDerby5552DB2.java utilXid.java Well, I tried this out with DB2 and things are interesting and different. The first thing of note is that the default for DB2 is no lock timeout. I had to go into Control Center and change the database application parameter LOCKTIMEOUT to be something other than -1. With DB2 after the lock timeout DB2 doesn't let you use the connection saying Exception trying to check conn2 after lock timeout but before explicit rollback com.ibm.db2.jcc.am.SqlException: [jcc][t4][10342][11669][4.12.55] Application must execute a rollback. The unit of w has already been rolled back in the database but other resource managers involved in this unit of work might not. To ure integrity of this application, all SQL requests will be rejected until the application issues a rollback. ERROR =-4497, SQLSTATE=null Then it won't actually let you do a rollback, but will let you do an end. If you try rollback it fails with XAER_PROTO but a rollback after end fails with XAER_NOTA if you try to rollback after end. Statements after the end fail with XA_RBTIMEOUT so I am not sure actually how one could use the connection again. Below is the output and attached is the program I was playing with in case anyone is interested, but I think the main thing I have learned is that since the spec doesn't really offer any guidance on this, we just need to do something reasonable and make sure that the global transaction doesn't get used again except to rollback, which I think the behavior with the patch does effectively as the activity that happens on the connection after the implicit rollback happens in a new local transaction. So I will go ahead and check in the latest patch with the expanded test. $ java -Duser=x -Dpassword=xxx ReproDerby5552DB2 Got Expected Lock Timeout Exception DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=4.12.55 Connection ok. got right value Exception trying to check conn2 after lock timeout but before explicit rollback com.ibm.db2.jcc.am.SqlException: [jcc][t4][10342][11669][4.12.55] Application must execute a rollback. The unit of work has already been rolled back in the database but other resource managers involved in this unit of work might not. To ens ure integrity of this application, all SQL requests will be rejected until the application issues a rollback. ERRORCODE =-4497, SQLSTATE=null at com.ibm.db2.jcc.am.hd.a(hd.java:660) at com.ibm.db2.jcc.am.hd.a(hd.java:60) at com.ibm.db2.jcc.am.hd.a(hd.java:75) at com.ibm.db2.jcc.am.o.f(o.java:537) at com.ibm.db2.jcc.am.o.a(o.java:495) at com.ibm.db2.jcc.am.Sqlca.getJDBCMessage(Sqlca.java:334) at com.ibm.db2.jcc.am.SqlExceptionContainer.getMessage(SqlExceptionContainer.java:78) at com.ibm.db2.jcc.am.SqlTransactionRollbackException.getMessage(SqlTransactionRollbackException.java:52) at ReproDerby5552DB2.main(ReproDerby5552DB2.java:61) Did not get exception on end as with Derby Got Exception checking conn2 after end com.ibm.db2.jcc.am.SqlException: [jcc][t4][2041][11392][4.12.55] Error executing XAResource.end(). Server returned XA_R BTIMEOUT. ERRORCODE=-4203, SQLSTATE=null at com.ibm.db2.jcc.am.hd.a(hd.java:660) at com.ibm.db2.jcc.am.hd.a(hd.java:60) at com.ibm.db2.jcc.am.hd.a(hd.java:94) at com.ibm.db2.jcc.t4.zb.a(zb.java:2755) at com.ibm.db2.jcc.t4.c.Xb(c.java:271) at com.ibm.db2.jcc.am.o.g(o.java:340) at com.ibm.db2.jcc.t4.a.g(a.java:631) at com.ibm.db2.jcc.am.o.a(o.java:214) at com.ibm.db2.jcc.am.mn.a(mn.java:3073) at com.ibm.db2.jcc.am.mn.a(mn.java:686) at com.ibm.db2.jcc.am.mn.executeQuery(mn.java:670) at ReproDerby5552DB2.checkConn(ReproDerby5552DB2.java:106) at ReproDerby5552DB2.main(ReproDerby5552DB2.java:86) Rolling back xid2 Exception in thread main com.ibm.db2.jcc.am.XaException: [jcc][t4][2041][12326][4.12.55] Error executing XAResource.ro llback(). Server returned XAER_NOTA. ERRORCODE=-4203, SQLSTATE=null at com.ibm.db2.jcc.am.hd.c(hd.java:453) at com.ibm.db2.jcc.t4.zb.b(zb.java:2773) at com.ibm.db2.jcc.t4.ac.b(ac.java:1546) at com.ibm.db2.jcc.t4.ac.a(ac.java:1326) at com.ibm.db2.jcc.t4.ac.a(ac.java:1321) at com.ibm.db2.jcc.t4.ac.rollback(ac.java:1310) at ReproDerby5552DB2.main(ReproDerby5552DB2.java:94) kmarsden@IBM-JDPM42DBIO2 ~/repro/derby-5552 $ $ java ReproDerby5552DB2 Got Expected Lock Timeout Exception DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=6 Connection ok. got right value Exception trying to check conn2
[jira] [Updated] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
[ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5552: -- Fix Version/s: 10.9.0.0 Change fix version to 10.9. Leaving open for backport. Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs - Key: DERBY-5552 URL: https://issues.apache.org/jira/browse/DERBY-5552 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.1.2 Environment: Solaris 10, Glassfish V2.1.1, Reporter: Brett Bergquist Assignee: Kathey Marsden Priority: Blocker Labels: derby_triage10_9 Fix For: 10.9.0.0 Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, ReproDerby5552DB2.java, ReproDerby5552LockTimeout.java, appserverstack.txt, client.tar.Z, derby-5552_withexpanded_test_diff.txt, derby-5552_withtest_diff.txt, derby-5552_withtest_diff.txt, derby.log, derbystackatshutdown.txt, execute.patch, transactionsleft.txt, utilXid.java The issue arrives when multiple XA transactions are done in parallel and there is either a lock timeout or a lock deadlock detected. When this happens the connection is leaked in the Glassfish connection pool and the client thread hangs in org.apache.derby.client.netReply.fill(Reply.java:172). Shutting down the app server fails because the thread has a lock in org.apache.derby.client.net.NetConnection40 and another task is calling org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214) which is waiting for the lock. Killing the appsever using kill and then attempting to shutdown Derby network server causes the Network Server to hang. One of the threads hangs waiting for a lock at org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525) and the main thread has this locked at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242) and it itself is waiting for a lock which belongs to a thread that is stuck at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118) which is in the TIMED_WAITING state. Only by killing the Network Server using kill is possible at this point. There are transactions left even though all clients have been removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
[ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5552: -- Affects Version/s: 10.1.3.1 10.2.2.0 10.3.3.0 10.4.2.0 10.5.3.0 10.6.2.1 10.7.1.1 10.8.2.2 This issue has always been here. Changing affects version accordingly. Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs - Key: DERBY-5552 URL: https://issues.apache.org/jira/browse/DERBY-5552 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2 Environment: Solaris 10, Glassfish V2.1.1, Reporter: Brett Bergquist Assignee: Kathey Marsden Priority: Blocker Labels: derby_triage10_9 Fix For: 10.9.0.0 Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, ReproDerby5552DB2.java, ReproDerby5552LockTimeout.java, appserverstack.txt, client.tar.Z, derby-5552_withexpanded_test_diff.txt, derby-5552_withtest_diff.txt, derby-5552_withtest_diff.txt, derby.log, derbystackatshutdown.txt, execute.patch, transactionsleft.txt, utilXid.java The issue arrives when multiple XA transactions are done in parallel and there is either a lock timeout or a lock deadlock detected. When this happens the connection is leaked in the Glassfish connection pool and the client thread hangs in org.apache.derby.client.netReply.fill(Reply.java:172). Shutting down the app server fails because the thread has a lock in org.apache.derby.client.net.NetConnection40 and another task is calling org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214) which is waiting for the lock. Killing the appsever using kill and then attempting to shutdown Derby network server causes the Network Server to hang. One of the threads hangs waiting for a lock at org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525) and the main thread has this locked at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242) and it itself is waiting for a lock which belongs to a thread that is stuck at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118) which is in the TIMED_WAITING state. Only by killing the Network Server using kill is possible at this point. There are transactions left even though all clients have been removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
[ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5552: -- Attachment: derby-5552_withexpanded_test_diff.txt Attached is a new patch derby-5552_withexpanded_test_diff.txt which expands the test to check the state of the connections and the transaction table after the lock timeout. I think most things are working as expected. - The transaction (xid2) that was rolled back due the lock timeout is no longer in the transaction table after the lock time out. - New statements on the connection after the lock timeout start a new local transaction. - XAResource.end() on xid2 fails with an RB_TIMEOUT - Even though it is not in the transaction table and is holding no locks, xid2 has to be explicitly rolled back before it can be reused. This is the one I am not sure about. Should this be necessary? Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs - Key: DERBY-5552 URL: https://issues.apache.org/jira/browse/DERBY-5552 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.1.2 Environment: Solaris 10, Glassfish V2.1.1, Reporter: Brett Bergquist Assignee: Kathey Marsden Priority: Blocker Labels: derby_triage10_9 Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, ReproDerby5552LockTimeout.java, appserverstack.txt, client.tar.Z, derby-5552_withexpanded_test_diff.txt, derby-5552_withtest_diff.txt, derby-5552_withtest_diff.txt, derby.log, derbystackatshutdown.txt, execute.patch, transactionsleft.txt The issue arrives when multiple XA transactions are done in parallel and there is either a lock timeout or a lock deadlock detected. When this happens the connection is leaked in the Glassfish connection pool and the client thread hangs in org.apache.derby.client.netReply.fill(Reply.java:172). Shutting down the app server fails because the thread has a lock in org.apache.derby.client.net.NetConnection40 and another task is calling org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214) which is waiting for the lock. Killing the appsever using kill and then attempting to shutdown Derby network server causes the Network Server to hang. One of the threads hangs waiting for a lock at org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525) and the main thread has this locked at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242) and it itself is waiting for a lock which belongs to a thread that is stuck at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118) which is in the TIMED_WAITING state. Only by killing the Network Server using kill is possible at this point. There are transactions left even though all clients have been removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-1966) NetworkServer startup can take 50+ seconds if a client holds an open connection to the previous server booted within the same vm
[ https://issues.apache.org/jira/browse/DERBY-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1966: -- Attachment: AttemptReproDerby1966.java I attempted to reproduce this problem with the attached program AttemptReproDerby1966 against the reported version 10.3.1.4 on Windows with IBM 1.4.2 (although probably a later version of IBM 1.4.2) $ java -version java version 1.4.2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142ifx-20110211 (SR13 FP8+PM31983) (JIT enabled: jitc)) Kristian also said he had trouble reproducing with the steps provided. I think unless someone has other ideas, we should close this one Cannot Reproduce NetworkServer startup can take 50+ seconds if a client holds an open connection to the previous server booted within the same vm Key: DERBY-1966 URL: https://issues.apache.org/jira/browse/DERBY-1966 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.3.1.4 Environment: Windows XP - IBM JVM 1.4.2 Reporter: Daniel John Debrunner Labels: derby_triage10_5_2 Attachments: AttemptReproDerby1966.java Seen when a client in the same jvm held a open connection to a previously booted network server within the same jvm. Order would be: boot server client connect to server (hold onto connection and don't close) shutdown server boot server -- this boot will take 50+ seconds -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-256) ASSERTION when attempting to execute a statement after shutdown of database with network Server
[ https://issues.apache.org/jira/browse/DERBY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-256: - Attachment: repro.sql Against trunk running the attached repro.sql started with: java -Dij.protocol=jdbc:derby://localhost:1527/ org.apache.derby.tools.ij I see the protocol error Dag described. I don't see the assertion failure in the derby.log. To avoid confusion, the best thing to do would be to close this one cannot reproduce and open up a new bug for the protocol error. ASSERTION when attempting to execute a statement after shutdown of database with network Server --- Key: DERBY-256 URL: https://issues.apache.org/jira/browse/DERBY-256 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.1.2.1 Reporter: Kathey Marsden Labels: derby_triage10_5_2 Attachments: repro.sql java -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.user=I -Dij.password=mine org.apache.derby.tools.ij -- create and connect to the databases ij connect 'wombat;create=true'; ij connect 'myDB;create=true'; -- shutdown database wombat -- ERROR 08006 expected ij(CONNECTION1) connect 'wombat;shutdown=true'; Connection number: 3. ERROR 08006: wombat?(server log )?atabase 'wombat' shutdown.?08006.D com.ibm.db2.jcc.am.SqlException: wombat?(server log XXX) Database 'wombat' shutdown.?08006.D ij(CONNECTION1) show connections; CONNECTION0 - jdbc:db2j:net://localhost:1527/wombat;create=true CONNECTION1* - jdbc:db2j:net://localhost:1527/myDB;create=true * = current connection ij(CONNECTION1) select * from sys.systables; -- system tables are returned 15 rows selected -- shutdown database myDB -- ERROR 08006 expected ij(CONNECTION1) connect 'mydb;shutdown=true'; Connection number: 4. ERROR 08006: mydb?(server log:)Database 'mydb' shutdown.?08006.D com.ibm.db2.jcc.am.SqlException: mydb?(server log: XXX)Database 'mydb' shutdown.?08006.D ij(CONNECTION1) show connections; CONNECTION0 - jdbc:db2j:net://localhost:1527/wombat;create=true CONNECTION1* - jdbc:db2j:net://localhost:1527/myDB;create=true * = current connections ij(CONNECTION1) select * from sys.systables; com.ibm.db2j.protocol.BasicServices.Errors.AssertFailure: ASSERT FAILED connection is closed at com.ibm.db2j.protocol.BasicServices.SanityService.SanityManager. ASSERT(SanityManager.java:124) at com.ibm.db2j.impl.Connectivity.JDBC.Local.LocalConnection.prepar eCall(LocalConnection.java:887) at com.ibm.db2j.impl.Connectivity.JDBC.Local.LocalConnection.prepar eCall(LocalConnection.java:842) at com.ibm.db2j.drda.DRDAConnThread.parseSQLDTA_work(DRDAConnThread .java:3771) at com.ibm.db2j.drda.DRDAConnThread.parseSQLDTA(DRDAConnThread.java :3694) at com.ibm.db2j.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnT hread.java:3576) at com.ibm.db2j.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.j ava:3422) at com.ibm.db2j.drda.DRDAConnThread.processCommands(DRDAConnThread. java:848) at com.ibm.db2j.drda.DRDAConnThread.run(DRDAConnThread.java:235) agentThread[DRDAConnThread_4,5,main] ERROR 08003: DB2 SQL error: SQLCODE: -1, SQLSTATE: 08003, SQLERRMC: (server log:C:\mark52\test\users\test\db2j.log)?No current connection.?08003 com.ibm.db2.jcc.am.SqlException: (server log:C:\mark52\test\users\test\db2j.log)?No current connection.?08003 at com.ibm.db2.jcc.am.Statement.completeSqlca(Statement.java:1459) at com.ibm.db2.jcc.t4.T4StatementReply.parsePrepareError(T4Statemen tReply.java:594) at com.ibm.db2.jcc.t4.T4StatementReply.parsePRPSQLSTTreply(T4Statem entReply.java:141) at com.ibm.db2.jcc.t4.T4StatementReply.readPrepareDescribeOutput(T4 StatementReply.java:42) at com.ibm.db2.jcc.t4.StatementReply.readPrepareDescribeOutput(Stat ementReply.java:31) at com.ibm.db2.jcc.t4.T4Statement.readPrepareDescribeOutput_(T4Stat ement.java:142) at com.ibm.db2.jcc.am.Statement.readPrepareDescribeOutput(Statement .java:1062) at com.ibm.db2.jcc.am.Statement.flowExecute(Statement.java:1702) at com.ibm.db2.jcc.am.Statement.executeX(Statement.java:666) at com.ibm.db2.jcc.am.Statement.execute(Statement.java:650) at com.ibm.db2j.tools.ijImpl.ij.executeImmediate(ij.java:261) at com.ibm.db2j.tools.ijImpl.utilMain.doCatch(utilMain.java:427) at com.ibm.db2j.tools.ijImpl.utilMain.go(utilMain.java:306) at com.ibm.db2j.tools.ijImpl.Main.go(Main.java:202) at com.ibm.db2j.tools.ijImpl.Main.mainCore(Main.java:168) at
[jira] [Updated] (DERBY-5270) Move DRDAConstants from iapi to shared.common
[ https://issues.apache.org/jira/browse/DERBY-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5270: -- Issue fix info: Known fix,Newcomer Labels: derby_triage10_9 (was: ) Move DRDAConstants from iapi to shared.common - Key: DERBY-5270 URL: https://issues.apache.org/jira/browse/DERBY-5270 Project: Derby Issue Type: Improvement Components: Network Client, Network Server Affects Versions: 10.9.0.0 Reporter: Kristian Waagan Priority: Trivial Labels: derby_triage10_9 DRDAConstants are used by both the client and the server, and contains constants only. The shared package seems like a better home for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4805) Increase the length of the RDBNAM field in the DRDA implementation
[ https://issues.apache.org/jira/browse/DERBY-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4805: -- Issue fix info: High Value Fix,Newcomer (was: Newcomer) Labels: derby_triage10_9 (was: ) This is a good project for a newcomer. The trickiest thing will be determining if any special handling is needed with mixed client/server versions and testing that. Increase the length of the RDBNAM field in the DRDA implementation -- Key: DERBY-4805 URL: https://issues.apache.org/jira/browse/DERBY-4805 Project: Derby Issue Type: Improvement Components: Network Client, Network Server Affects Versions: 10.7.1.1 Reporter: Tiago R. Espinha Labels: derby_triage10_9 Currently, whenever the client driver is used, there is a limit of 255 bytes for the database name. This is defined by the DRDA spec and there has been a discussion on the list [1] as to whether this limit should be raised due to the introduction of the new ACR that allows for UTF-8 characters. UTF-8 characters can take up to four bytes and this reduces the limit in characters dramatically. This should be an easy change as there is a codepoint that defines this limit. [1] - http://old.nabble.com/Database-name-length-tt29691419.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4719) Define consistent Derby data source behavior
[ https://issues.apache.org/jira/browse/DERBY-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4719: -- Urgency: Normal Labels: derby_triage10_9 (was: ) It would be nice to have consistent datasource behavior, but I agree incremental changes in that direction could be difficult for users. Since the datasources have their own implementation specific names, perhaps one solution for someone wanting to tackle this big project would be to create a new set of Datasources with new names that have the consistent behavior. Define consistent Derby data source behavior Key: DERBY-4719 URL: https://issues.apache.org/jira/browse/DERBY-4719 Project: Derby Issue Type: Task Components: Documentation, Javadoc, JDBC, Network Client Affects Versions: 10.7.1.1 Reporter: Kristian Waagan Labels: derby_triage10_9 The behavior of the various data source implementations in Derby isn't consistent. As a starting point, from the thread [1] on derby-dev: - Hi, I have been investigating how the various Derby data source implementations behave when it comes to [bean] properties. Properties and attributes are used interchangeably, and I'll be using the following abbreviations: o DS-[E|C] the normal data souce embedded/client o CP-[E|C] ConnectionPoolDataSource embedded/client o XA-[E|C] XADataSource embedded/client Here are some of the current issues: 1) CP-C and XA-C effectively ignore the connection attribute string for certain attributes (those who have individual setters, DERBY-4067) 2) *-E don't update the internal property state based on the connection attribute string (i.e. specifying ;user=myuser won't change the return value of getUser() after connect). 3) Only some of the properties are updated from the connection attribute string. This is as expected, but it is confusing that for instance 'traceDirectory' is updated and 'traceLevel' isn't. 4) *-C has 'APP' as the default user, *-E has null. 5) Some property setters accept all values, others throw an exception if the value is invalid. I don't think all these issues should be fixed, but I'd like to fix (1), as it has caused some trouble in the past (i.e., user not understanding why the settings aren't taking effect). There are several possible fixes for (1): 1a) Make CP-C and XA-C process the connection attribute string to update the internal state. 1b) Make DS-C ignore the connection attribute string (may break existing deployments). 1c) Throw exception if a property with a setter is specified in the connection attribute string. I don't care that much about which solution is chosen, but I'd prefer that the various data sources are consistent. For instance, it would be nice if a user could swap ClientDataSource with ClientConnectionPoolDataSource without having to change the data source definition. For instance, doing this today with ssl=basic in the connection attribute string would make DS-C connect with SSL, but CP-C would connection without SSL. We have this wording in the JavaDoc for ClienBaseDataSource.setConnectionAttributes(String): Set this property to pass in more Derby specific connection URL attributes. Any attributes that can be set using a property of this DataSource implementation (e.g user, password) should not be set in connectionAttributes. Conflicting settings in connectionAttributes and properties of the DataSource will lead to unexpected behaviour. Any opinions or questions on any of this? Regards, - [1] http://old.nabble.com/Derby-data-sources-to28692616.html#a28692616 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4702) Determine if the DRDA Layber B DSS extended total length field should carry a signed or unsigned integer
[ https://issues.apache.org/jira/browse/DERBY-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4702: -- Urgency: Low Labels: derby_triage10_9 (was: ) Determine if the DRDA Layber B DSS extended total length field should carry a signed or unsigned integer Key: DERBY-4702 URL: https://issues.apache.org/jira/browse/DERBY-4702 Project: Derby Issue Type: Task Components: Network Client, Network Server Affects Versions: 10.7.1.1 Reporter: Kristian Waagan Priority: Minor Labels: derby_triage10_9 The client and the server disagrees on whether the extended total length field in the DRDA protocol is signed or unsigned. A search in the DRDA specification (version 4) was fruitless. I don't think the current situation results in any practical problems, but it would be nice to determine what the correct representation is and to make the client and the server consistent. This issue was brought up under DERBY-1595. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4688) With Derby 10.6 and higher, selecting object columns from system tables ERROR XN020: Error marshalling or unmarshalling a user defined type
[ https://issues.apache.org/jira/browse/DERBY-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4688: -- Issue fix info: Release Note Needed,Repro attached,Workaround attached (was: Release Note Needed) Urgency: Low Bug behavior facts: Embedded/Client difference,Regression Labels: derby_triage10_9 (was: ) Issue Type: Bug (was: Task) Triage for 10.9. Switch to bug, regression, repro attached and Work around attached. Unless someone shows enthusiasm for fixing it, I think users will need to use the work around of including derby.jar in their client classpath if they want to select these columns from the system tables. We may want to consider resolving it won't fix With Derby 10.6 and higher, selecting object columns from system tables ERROR XN020: Error marshalling or unmarshalling a user defined type --- Key: DERBY-4688 URL: https://issues.apache.org/jira/browse/DERBY-4688 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.7.1.1 Reporter: Kathey Marsden Priority: Minor Labels: derby_triage10_9 Attachments: ReproDerby4688.java, derby-4688_diff_try1.txt, releaseNote.html If derby.jar is not in the classpath when a client selects an object from a system table, for example selecting ALIASINFO from SYS.SYSALIASES an error will result, eg. ERROR XN020: Error marshalling or unmarshalling a user defined type: org.apache. derby.catalog.types.RoutineAliasInfo To reproduce, put only derbyclient.jar and derbytools.jar in your classpath and connect to a running server and run: ij connect 'jdbc:derby://localhost:1527/wombat;create=trrue'; ij select * from sys.sysaliases ; ALIASID |ALIAS |SCHEMAID|JAVACLASSNAME |||SYST|ALIASINFO |SPECIFICNAME -- ERROR XN020: Error marshalling or unmarshalling a user defined type: org.apache. derby.catalog.types.RoutineAliasInfo ij With the 10.5 client it gives the text of the procedure or function definition for ALIASINFO may have been useful to someone, e.g. SQLCAMESSAGE(IN SQLCODE INTEGER,IN SQLERRML SMALLINT,IN SQLERRMC VARCHAR(2400),I N SQLERRP CHAR(8),IN SQLERRD0 INTEGER,IN SQLERR I am not sure what can or should be done about this issue. Workaround include: - Cast the value to LONG VARCHAR in the query. - Put the server jars in the classpath if you want to use the objects. - Remove extraneous columns if they are not used. I am not sure what can or should be done about this issue, but a release note would at least help mitigate it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4633) Cache default calendar in result sets and statements on client driver
[ https://issues.apache.org/jira/browse/DERBY-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4633: -- Issue fix info: Newcomer Urgency: Normal Labels: derby_triage10_9 (was: ) Triage for 10.9 This might be an appropriate newcomer project with some guidance. Cache default calendar in result sets and statements on client driver - Key: DERBY-4633 URL: https://issues.apache.org/jira/browse/DERBY-4633 Project: Derby Issue Type: Improvement Components: JDBC, Network Client Affects Versions: 10.6.1.0 Reporter: Knut Anders Hatlen Labels: derby_triage10_9 After the changes in DERBY-4582, these methods now allocate a default calendar object on each invocation (on the client driver), whereas they didn't before the fix: ResultSet.getDate(int) ResultSet.getTime(int) ResultSet.getTimestamp(int) PreparedStatement.setDate(int, java.sql.Date) PreparedStatement.setTime(int, java.sql.Time) PreparedStatement.setTimestamp(int, java.sql.Timestamp) CallableStatement.getDate(int) CallableStatement.getTime(int) CallableStatement.getTimestamp(int) The embedded driver prevents excessive allocation of default calendar objects in these methods by caching an instance in ConnectionChild (the super-class of EmbedResultSet, EmbedPreparedStatement and EmbedCallableStatement). We should do something similar on the client driver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-3687) Make client driver allow nested savepoints
[ https://issues.apache.org/jira/browse/DERBY-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3687: -- Issue fix info: Repro attached Urgency: Normal Labels: derby_triage10_9 (was: ) Triage for 10.9. Mark repro attached Make client driver allow nested savepoints -- Key: DERBY-3687 URL: https://issues.apache.org/jira/browse/DERBY-3687 Project: Derby Issue Type: Improvement Components: Network Client Reporter: Dag H. Wanvik Labels: derby_triage10_9 Attachments: Main.java Currently, only the embedded driver allows nested savepoints, cf. the attached repro. In the interest of harmonizing the drivers it would be nice to make the client driver allow this as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-3377) Network Client/Server should use sqlType instead of locator value to determine if lob was sent by locator/value
[ https://issues.apache.org/jira/browse/DERBY-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3377: -- Labels: LOB derby_triage10_9 (was: LOB) Network Client/Server should use sqlType instead of locator value to determine if lob was sent by locator/value --- Key: DERBY-3377 URL: https://issues.apache.org/jira/browse/DERBY-3377 Project: Derby Issue Type: Improvement Components: Network Client, Network Server Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.1.3 Reporter: Kathey Marsden Priority: Minor Labels: LOB, derby_triage10_9 This issue came up during the fix for DERBY-3243. Currently network server does not send the correct sqlType for locators. It sends DB2_SQLTYPE_BLOB or DB2_SQLTYPE_CLOB instead of DB2_SQLTYPE_BLOB_LOCATOR or DB2_SQLTYPE_CLOB_LOCATOR so the client's only way of determining whether it is getting a lob by value or locator is to look at the locator/extended length field and use that to branch its logic. It would be cleaner moving foward to use the sqlType to branch this logic, but there would have to be version specific handling to allow it to work the old way when communicating with older versions. The sqlType is sent as part of the SQLDAGRP in DRDAConnThread.writeSQLDAGRP() in the server code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-1755) Add support to client to be able to retry a connection request with a server supported secmec.
[ https://issues.apache.org/jira/browse/DERBY-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1755: -- Urgency: Low Labels: derby_triage10_9 (was: ) Triage for 10.9. Setting Urgency low. We haven't seen requests for this that I know of. Add support to client to be able to retry a connection request with a server supported secmec. -- Key: DERBY-1755 URL: https://issues.apache.org/jira/browse/DERBY-1755 Project: Derby Issue Type: Improvement Components: Network Client, Network Server Reporter: Sunitha Kambhampati Priority: Minor Labels: derby_triage10_9 If server does not accept the client sent security mechanism, then as part of response for ACCSEC , the server sends the list of supported secmec back to the client. If the client can support the secmec sent by the server, then the client can retry the connection request with a secmec that the server said it supports. Some existing clients like the C client already handle this behavior. It would be nice to have the network client be able to make such choices. Some related jiras- DERBY-1517,DERBY-1675,DERBY-926 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-1657) Align error reporting in the client driver and embedded driver for streaming errors through the JDBC API
[
https://issues.apache.org/jira/browse/DERBY-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-1657:
--
Labels: derby_triage10_9 (was: )
Align error reporting in the client driver and embedded driver for streaming
errors through the JDBC API
Key: DERBY-1657
URL: https://issues.apache.org/jira/browse/DERBY-1657
Project: Derby
Issue Type: Improvement
Components: JDBC, Network Client, Network Server, Store
Environment: Using streams as input for JDBC methods.
Reporter: Kristian Waagan
Labels: derby_triage10_9
The way streaming errors are reported differ between the client driver and
the embedded driver.
The following SQLStates can be seen:
XCL30.S=An IOException was thrown when reading a ''{0}'' from an InputStream.
XSDA4.S=An unexpected exception was thrown
22001=A truncation error was encountered trying to shrink {0} ''{1}'' to
length {2}.
XJ023.S=Input stream did not have exact amount of data as the requested
length.
XN014.S=Network protocol error: encountered an IOException, parameter #{0}.
Remaining data has been padded with 0x0. Message: {1}.
XN015.S=Network protocol error: the specified size of the InputStream,
parameter #{0}, is less than the actual InputStream length.
XN016.S=Network protocol error: encountered error in stream length
verification, parameter #{0}. Message: {1}.
XN017.S=Network protocol error: end of stream prematurely reached, parameter
#{0}. Remaining data has been padded with 0x0.
XN018.S=Network protocol error: the specified size of the Reader, parameter
#{0}, is less than the actual InputStream length.
Some of these exceptions are nested inside one or more of the other
exceptions.
There are basicly three types of streaming errors:
a) The stream is too long for the column it is being inserted into
b) The actual length of the stream does not match the specified length
c) A general IOException is thrown when reading from the stream
An approach would be to always throw specific exceptions for a) and b), for
instance 22001 and XJ023, and throw a general exception for class c)
exceptions (the message of the IOException would be wrapped/included).
Note that the level of detail in client and embedded (in the top level
exception) might vary; it can be XN017 on the client, but XSDA4 in embedded
(for the same JDBC code causing the exception).
Changing the SQLStates might impact existing applications, but aligning the
drivers' behavior has high priority.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-1441) Allow client to be able to send greater than 32k query block size.
[ https://issues.apache.org/jira/browse/DERBY-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1441: -- Urgency: Low Labels: derby_triage10_9 (was: ) Triage for 10.9. I think this is still valid as DERBY-959 only dealt with server side changes. Allow client to be able to send greater than 32k query block size. -- Key: DERBY-1441 URL: https://issues.apache.org/jira/browse/DERBY-1441 Project: Derby Issue Type: Improvement Components: Network Client Affects Versions: 10.2.1.6 Reporter: Sunitha Kambhampati Priority: Minor Labels: derby_triage10_9 DERBY-959 talks about 'Allowing use of QRYDTA block sizes greater than 32k'. I am opening two tasks after the discussion on DERBY-959. As part of this issue: - add support in client to be able to send query block size of greater than 32k. After that, some benchmarking needs to be done to choose a good query block size for the client to send to the server. I'll open another jira for the performance analysis task. Here is the link to the discussion that happened for DERBY-959. http://www.nabble.com/-jira--Created%3A-%28DERBY-959%29-Allow-use-of-DRDA-QRYDTA-block-sizes-greater-than-32K-t1106974.html#a2892273 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-2363) Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings.
[ https://issues.apache.org/jira/browse/DERBY-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2363: -- Issue fix info: High Value Fix Urgency: Normal Labels: derby_triage10_9 (was: ) Triage for 10.9. If this can be achieved to allow SSL without client side application change and special configuration, that would be I think a big boost to Network Server security in the field. Marking High Value Fix Add initial handshake on connection setup to determine server's required ssl support level and avoid client side attribute settings. Key: DERBY-2363 URL: https://issues.apache.org/jira/browse/DERBY-2363 Project: Derby Issue Type: Improvement Components: Network Client, Network Server Reporter: Daniel John Debrunner Labels: derby_triage10_9 Based upon some of the discussion in DERBY-2108, it would be useful to have some initial handshake between the client and the server to indicate the required level of ssl support. This would avoid client applications having to setup ssl related JDBC attributes or DataSource properties. Thus one could change the server to be ssl enabled without having to change any applications. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5328) The private fields of the NetServlet can be changed by multiple threads, giving rise to race conditions and corruptions.
[ https://issues.apache.org/jira/browse/DERBY-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5328: -- Issue fix info: Newcomer Labels: derby_triage10_9 (was: ) Triage for 10.9 The private fields of the NetServlet can be changed by multiple threads, giving rise to race conditions and corruptions. Key: DERBY-5328 URL: https://issues.apache.org/jira/browse/DERBY-5328 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Labels: derby_triage10_9 Attachments: derby-5328-01-aa-simpleFields.diff At the beginning of the NetServlet class, there are a number of private fields. These fields can be inspected and changed by any thread running inside NetServlet.doGet(). Due to the way that app servers dispatch servlet requests, this means that multiple threads can be operating inside doGet() at the same time, clobbering one another's work. The weirdest instance of this is the shared PrintWriter (called out) which is used to produce the response web page sent back by the servlet. Multiple threads all writing to the same PrintWriter will create a very bizarre response page. The following improvements should be made: 1) The server field should be set by a synchronized method. 2) Every run through doGet() should create its own PrintWriter which is passed to other methods. The instance-wide out field should be removed. 3) Various other fields should be re-coded using the Atomic classes introduced by Java 5. These fields include logStatus and traceStatus. This solution can be implemented if the community votes to approve the sunsetting of JVM 1.4 (currently at the polls). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5607) Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server
[ https://issues.apache.org/jira/browse/DERBY-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5607: -- Priority: Critical (was: Major) Issue fix info: Patch Available,Repro attached (was: Repro attached) Urgency: Normal Bug behavior facts: Regression Test Failure (was: Security) Labels: derby_triage10_9 (was: ) Triage for 10.9. upped priority since it was a hang, but I there has already been a fix checked in for this issue. Is it ready to be resolved? Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server - Key: DERBY-5607 URL: https://issues.apache.org/jira/browse/DERBY-5607 Project: Derby Issue Type: Bug Components: Network Client, Network Server, Services Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Priority: Critical Labels: derby_triage10_9 Attachments: NASTHang.java, derby-5607-01-aa-userInternalDriver.diff A deadlock in the Java 5 VM hangs connection attempts if you are using NATIVE authentication with a client which runs in the same VM as the server. I will attach a test case which demonstrates this. This bug is implicated in the failures being discussed on https://issues.apache.org/jira/browse/DERBY-5601 and was disclosed by the discussion on this email thread: http://old.nabble.com/-URGENT--Critical-test-situation-on-trunk-to33259629.html#a33259629 The bug arises when NativeAuthenticationServiceImpl attempts a nested connection to the Credentials database during database creation. The nested connection is attempted in order to dertermine whether the user has system-wide privilege to create databases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-2883) template security policy file for network server uses undefined property derby.security.host
[
https://issues.apache.org/jira/browse/DERBY-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-2883:
--
Issue fix info: Newcomer
Labels: derby_triage10_5_2 derby_triage10_9 (was:
derby_triage10_5_2)
Triage for 10.9. Mark as Newcomer. Good newcomer issue to learn a bit about
java 2 security.
template security policy file for network server uses undefined property
derby.security.host
Key: DERBY-2883
URL: https://issues.apache.org/jira/browse/DERBY-2883
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.3.1.4, 10.4.1.3
Reporter: Daniel John Debrunner
Labels: derby_triage10_5_2, derby_triage10_9
DERBY-2811 changed the use of
permission java.net.SocketPermission ${derby.drda.host}:*, accept;
to
permission java.net.SocketPermission ${derby.security.host}:*, accept;
I think this is correct for the default policy file used by the network
server, but incorrect for the user template file.
I think rather than exposing this internal property derby.security.host,
the template should continue to use ${derby.drda.host}
and include comments about needing to change it if the server is listening on
a wildcard address. Currently there's no explanation of where
derby.security.host comes from.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5317) NullPointerException in org.apache.derby.client.net.Request.sendBytes() with client
[ https://issues.apache.org/jira/browse/DERBY-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5317: -- Labels: derby_triage10_9 (was: ) Triaged for 10.9. Keeping urgency as urgent as it is a client crash and has a simple reproduction. I confirmed the issue reproduces with Repro5317.java attached and very quickly (in case someone has been shying away from this issue because I mentioned it takes a long time to reproduce with LobLimitsTest. $ java Repro5317 Fri Feb 17 09:49:50 PST 2012 : Apache Derby Network Server - 10.9.0.0 alpha - (1242867M) started and ready to accept con nections on port 1527 START insert clob -insertClob of size = 31744 Insert Clob (31744) rows= 2 = 382 Rows inserted with clob of size (31744) = 2 START ClobTest #4 - select and then update clob of size= 31744 - Uses setClob api Fri Feb 17 09:49:52 PST 2012 : Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT ar g = 200d; Error Code Value = 1d. Plaintext connection attempt from an SSL enabled client? org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_ SYNTAXRM; CODPNT arg = 200d; Error Code Value = 1d. Plaintext connection attempt from an SSL enabled client? at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:537) at org.apache.derby.impl.drda.DRDAConnThread.invalidCodePoint(DRDAConnThread.java:8295) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:4366) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:4175) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:1063) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) Fri Feb 17 09:49:52 PST 2012 : Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT ar g = 200d; Error Code Value = 1d. Plaintext connection attempt from an SSL enabled client? org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_ SYNTAXRM; CODPNT arg = 200d; Error Code Value = 1d. Plaintext connection attempt from an SSL enabled client? at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:537) at org.apache.derby.impl.drda.DRDAConnThread.invalidCodePoint(DRDAConnThread.java:8295) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:4366) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:4175) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:1063) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) Exception in thread main java.lang.NullPointerException at org.apache.derby.client.net.Request.sendBytes(Request.java:1212) at org.apache.derby.client.net.Request.flushScalarStreamSegment(Request.java:604) at org.apache.derby.client.net.Request.padScalarStreamForError(Request.java:660) at org.apache.derby.client.net.Request.writePlainScalarStream(Request.java:323) at org.apache.derby.client.net.Request.writeScalarStream(Request.java:247) at org.apache.derby.client.net.Request.writeScalarStream(Request.java:500) at org.apache.derby.client.net.NetStatementRequest.buildEXTDTA(NetStatementRequest.java:1042) at org.apache.derby.client.net.NetStatementRequest.writeExecute(NetStatementRequest.java:151) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPreparedStatement.java:174) at org.apache.derby.client.am.PreparedStatement.writeExecute(PreparedStatement.java:1806) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2036) at org.apache.derby.client.am.PreparedStatement.executeUpdateX(PreparedStatement.java:417) at org.apache.derby.client.am.PreparedStatement.executeUpdate(PreparedStatement.java:403) at Repro5317.selectUpdateClob(Repro5317.java:170) at Repro5317.main(Repro5317.java:42) kmarsden@IBM-JDPM42DBIO2 ~/repro/derby-5317 think Urgent is correct as NullPointerException in org.apache.derby.client.net.Request.sendBytes() with client - Key: DERBY-5317 URL: https://issues.apache.org/jira/browse/DERBY-5317 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.9.0.0 Reporter: Kathey
[jira] [Updated] (DERBY-5338) When attempting to insert a 4GB stream client gives SQLState XN015 network protocol error vs embedded 22003 data too large for type
[
https://issues.apache.org/jira/browse/DERBY-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5338:
--
Urgency: Normal
Bug behavior facts: Crash,Embedded/Client difference (was: Embedded/Client
difference)
Labels: derby_triage10_9 (was: )
Triaging for 10.9. Marking urgency as normal as this is a disallowed operation,
but since the connection is lost, marking it as a crash. This test in
LobLimitsTest should be changed to eliminate the special client condition to
reproduce the issue.
public void test_02_BlobNegative() throws SQLException {
// Negative Test, use setBlob api to insert a 4GB blob.
setAutoCommit(false);
PreparedStatement insertBlob =
prepareStatement(INSERT INTO BLOBTBL values (?,?,?,?));
BlobImplT _4GbBlob =
new BlobImplT(new RandomByteStreamT(new java.util.Random(),
_4GB), _4GB);
try {
insertBlob_SetBlob(BlobTest #7 (setBlob with 4Gb blob,
insertBlob, _4GbBlob,
_4GB, 0, 1, 0);
fail(Inserting 4BG blob should have thrown exception);
} catch (SQLException sqle) {
// DERBY DOES NOT SUPPORT INSERT OF 4GB BLOB
if (usingDerbyNetClient()) {
// DERBY-5338 client gives wrong SQLState and protocol error
// inserting a 4GB clob. Should be 22003
assertSQLState(XN015,sqle);
} else {
assertSQLState(22003, sqle);
}
commit();
}
When attempting to insert a 4GB stream client gives SQLState XN015 network
protocol error vs embedded 22003 data too large for type
---
Key: DERBY-5338
URL: https://issues.apache.org/jira/browse/DERBY-5338
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.9.0.0
Reporter: Kathey Marsden
Priority: Minor
Labels: derby_triage10_9
In converting LobLimits test DERBY-1903, I see that attempting to insert a
4GB stream with client gives the error XN015
Caused by: org.apache.derby.client.am.SqlException: Network protocol error:
the specified size of the InputStream, parameter #4, is less than the actual
InputStream length.
at
org.apache.derby.client.net.Request.writePlainScalarStream(Request.java:359)
at
org.apache.derby.client.net.Request.writeScalarStream(Request.java:247)
at
org.apache.derby.client.net.NetStatementRequest.buildEXTDTA(NetStatementRequest.java:963)
at
org.apache.derby.client.net.NetStatementRequest.writeExecute(NetStatementRequest.java:151)
at
org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPreparedStatement.java:174)
at
org.apache.derby.client.am.PreparedStatement.writeExecute(PreparedStatement.java:1800)
at
org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2030)
at
org.apache.derby.client.am.PreparedStatement.executeUpdateX(PreparedStatement.java:417)
at
org.apache.derby.client.am.PreparedStatement.executeUpdate(PreparedStatement.java:403)
... 38 more
vs's embedded's 22003, the length exceeds the maximum length for the data
type.
I am not sure if the connection is lost or not. It typically is with protocol
errors.
Look for this bug number in largedata.LobLimits.java for test case.
You can remove the exclusion for usingDerbyNetClient and run
org.apache.derbyTesting.functionTests.tests.largedata.LobLimitsLiteTest
to reproduce the problem. I will check the test case in soon as part of
DERBY-1903
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5341) Client allows insert of stream in excess of column with non-white space characters
[
https://issues.apache.org/jira/browse/DERBY-5341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5341:
--
Urgency: Urgent
Bug behavior facts: Deviation from standard,Embedded/Client
difference,Wrong query result (was: Embedded/Client difference,Wrong query
result)
Labels: derby_triage10_9 (was: )
Triage for 10.9. Marking Urgent since it has wrong results.
Client allows insert of stream in excess of column with non-white space
characters
---
Key: DERBY-5341
URL: https://issues.apache.org/jira/browse/DERBY-5341
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.9.0.0
Reporter: Kathey Marsden
Labels: derby_triage10_9
In converting LobLimits.java DERBY-1903 and trying to enable
LobLimitsLiteTest with client. I discovered that this case fails with client:
try {
insertClob2(ClobTest #9.1 , conn, insertClob2,
MORE_DATA_THAN_COL_WIDTH, 4, 1,
MORE_DATA_THAN_COL_WIDTH, CHARDATAFILE);
fail(ClobTest #9.1 + should have thrown XSDA4);
} catch (SQLException sqle) {
assertSQLState(XSDA4, sqle);
}
// no row must be retrieved.
selectClob2(ClobTest #9.2 , conn, selectClob2, BIG_LOB_SZ, 4, 0,
CHARDATAFILE);
If I omit the fail assertion, the row actually does get inserted and has
presumably been truncated.
I will check in LobLimits.java soon with this bug number in the comments.
To reproduce, remove the if(!usingDerbyNetClient) condition and run the test
largedata.LobLimitsLiteTest to reproduce the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5411) Client that does not have Security manager permission to connect gets ERROR 08006: Insufficient data while reading from the network Message should be clearer
[
https://issues.apache.org/jira/browse/DERBY-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5411:
--
Urgency: Low
Labels: derby_triage10_9 (was: )
Triaging for 10.9. Marking urgency as low as the problem is that with incorrect
usage (incorrect permissions) we throw an ugly and informative error instead of
an informative one.
Client that does not have Security manager permission to connect gets ERROR
08006: Insufficient data while reading from the network Message should be
clearer
---
Key: DERBY-5411
URL: https://issues.apache.org/jira/browse/DERBY-5411
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.8.2.2
Reporter: Kathey Marsden
Priority: Minor
Labels: derby_triage10_9
I was doing a little remote testing for the release candidate and noticed if
a machine does not have permission to connect, then the client shows the
following exception:
ij connect 'jdbc:derby://9.72.133.41:1527/wombat';
ERROR 08006: Insufficient data while reading from the network - expected a
minimum of 6 bytes and received only 0 bytes. The connection has been term
inated.
java.sql.SQLNonTransientConnectionException: Insufficient data while reading
from the network - expected a minimum of 6 bytes and received only 0 byte
s. The connection has been terminated.
at
org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown
Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:322)
at java.sql.DriverManager.getConnection(DriverManager.java:297)
at org.apache.derby.impl.tools.ij.ij.dynamicConnection(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.ConnectStatement(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown
Source)
at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.main(Unknown Source)
at org.apache.derby.tools.ij.main(Unknown Source)
Caused by: org.apache.derby.client.am.DisconnectException: Insufficient data
while reading from the network - expected a minimum of 6 bytes and receiv
ed only 0 bytes. The connection has been terminated.
at org.apache.derby.client.net.Reply.fill(Unknown Source)
at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown
Source)
at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source)
at org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown
Source)
at
org.apache.derby.client.net.NetConnectionReply.readExchangeServerAttributes(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.readServerAttributesAndKeyExchange(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowConnect(Unknown
Source)
at org.apache.derby.client.net.NetConnection.init(Unknown Source)
at org.apache.derby.client.net.NetConnection40.init(Unknown Source)
at
org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown
Source)
... 12 more
It would be good to have a clearer error message:
To Reproduce, use the script and policy file below changing the url for
derby.codejars to the correct path for your enviroment also in the policy
file my.policy exchange x.x.x.x with the permitted host and y.y.y.y with the
disallowed host. Then try to connect from the disllowed host with connect
'jdbc:derby://x.x.x.x:1527/wombat';
Script startServer.sh:
java -Djava.security.manager
-Dderby.codejars=file:c:/cygwin/home/kmarsden/projects/10.8.2testing/db-derby-10.8.2.1-lib/lib/
-Djava.security.policy=my.policy org.apache.derby.drda.NetworkServerControl
start -h 0.0.0.0
Policy File my.policy (change x.x.x.x and y.y.y.y) to the allowed and
disallowed host respectively. )Since the y.y.y.y line is commented it is not
really relevant except for testing that remote connections work properly)
grant codeBase ${derby.codejars}derby.jar
{
//
// These
[jira] [Updated] (DERBY-5534) ResultSet#updateFloat, #updateDouble do not check for NaN and other conditions on client
[
https://issues.apache.org/jira/browse/DERBY-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5534:
--
Issue fix info: Newcomer,Repro attached
Urgency: Normal
Labels: derby_triage10_9 (was: )
Triage for 10.9. Marking normal urgency also Newcomer. Verified this test
still fails when enabled for client. I am not totally sure what happens to the
value, does something get updated since there is no exception?
This test in ParameterMappingTest
// Remove test when DERBY-5534 is fixed
if (usingEmbedded()) {
assertUpdateState(rs, F04,
_X, Float.NaN, XXX_FLOAT, 22003);
assertUpdateState(rs, F04,
_X, Double.MIN_VALUE, XXX_DOUBLE, 22003);
// REAL DB2 limits: remove if DERBY-3398 is implemented
assertUpdateState(rs, F04, bdSmallestPosFloatValue, 22003);
assertUpdateState(rs, F04, bdSmallestNegFloatValue, 22003);
assertUpdateState(rs, F04, bdMaxFloatValue, 22003);
assertUpdateState(rs, F04, bdMinFloatValue, 22003);
}
here was 1 failure:
)
testDerby5533UpdateXXX(org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest)junit.framework
ionFailedError: exception expected
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.assertUpdateState(ParameterMap
t.java:5051)
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testDerby5533UpdateXXX(Paramet
ngTest.java:4775)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
FAILURES!!!
Tests run: 18, Failures: 1, Errors: 0
ResultSet#updateFloat, #updateDouble do not check for NaN and other
conditions on client
Key: DERBY-5534
URL: https://issues.apache.org/jira/browse/DERBY-5534
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client
Affects Versions: 10.8.2.2
Reporter: Dag H. Wanvik
Priority: Minor
Labels: derby_triage10_9
In updateXXX, where XXX is one of Float or Double, embedded throws value out
of range when the argument is Float.NaN or Double.NaN, the client does not
catch it.
The server will balk when the row is updated, though, in ResultSet#updateRow.
It will be more regular if this is caught in updateXXX also on the client as
other range errors are. The SQL state seen is 22003, which is what embedded
throws on updateXXX. See also DERBY-5533.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5553) System property for client tracing -Dderby.client.traceDirectory does not work with XADataSource
[ https://issues.apache.org/jira/browse/DERBY-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5553: -- Issue fix info: High Value Fix,Newcomer Urgency: Normal Labels: derby_10.9 (was: ) Triage for 10.9. Marking Newcomer and High Value Fix as it should be straight forward and as Brett discovered, it can be quite frustrating when diagnosing a problem to find the diagnostics don't work. System property for client tracing -Dderby.client.traceDirectory does not work with XADataSource Key: DERBY-5553 URL: https://issues.apache.org/jira/browse/DERBY-5553 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.8.2.2, 10.9.0.0 Reporter: Kathey Marsden Labels: derby_triage10_9 Attachments: XATemplate.java, utilXid.java The client system property -Dderby.client.traceDirectory does not work with ClientXADataSource. No trace files are created if this property is set when making XA Connections. I am sure it works fine with DriverManager connections and also checked tracing works fine using connection attributes and XA with. ds.setConnectionAttributes(traceDirectory=./traceDir); I have not checked ClientDataSource or ClientConnectionPoolDataSource. Attached is a reproduction for this issue. mkdir ./traceDir javac -g XATemplate.java utilXid.java java -Dderby.client.traceDirectory=./traceDir XATemplate You will see that traceDir is empty. This came up when debugging DERBY-5552 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5560) Java deadlock between LogicalConnection40 and ClientXAConnection40
[ https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5560: -- Issue fix info: High Value Fix Urgency: Urgent Bug behavior facts: Crash,Performance,Seen in production (was: Seen in production,Performance) Labels: derby_triage10_9 (was: ) Triage for 10.9. Marking Urgent, Crash (hang) and High Value Fix as we already have a patch. Just need a volunteer to run tests and hopefully add a test case and we can get this checked in. Java deadlock between LogicalConnection40 and ClientXAConnection40 -- Key: DERBY-5560 URL: https://issues.apache.org/jira/browse/DERBY-5560 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.8.2.2 Environment: Solaris 10 Glassfish V2.1.1 ClientXADataSource connection pool setup to close all connections on any error Reporter: Brett Bergquist Labels: derby_triage10_9 Attachments: DERBY-5560.patch There is a Java deadlock between LogicalConnection40 and ClientXAConnection40. The order of calls that cause the deadlock are: Thread 1 LogicalConnection.close ClientPooledConnection.recycleConnection Thread 2 ClientPooledConnection.close LogicalConnection.nullPhysicalConnection Thread 1 acquires a lock on the LogicalConnection and attempts to acquire a lock on the ClientPooledConnection Thread 2 acquires a lock on the ClientPooledConnection and attempts to acquire a lock on the LogicalConnection In production this occurs when one thread is committing a transaction and another thread is trying to close the connection. This occurred because the Glassfish connection pool is setup to close all connections on any error on any connection and an error has been detected on another connection in the pool. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5561) Race conditions in LogicalConnection checking for a null physical connection
[ https://issues.apache.org/jira/browse/DERBY-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5561: -- Issue fix info: High Value Fix,Patch Available Urgency: Urgent Labels: derby_triage10_9 (was: ) Triage for 10.9. Urgent, High Value Fix. Thanks Brett for the patch and Siddharth for picking up the testing and driving it to commit. Race conditions in LogicalConnection checking for a null physical connection Key: DERBY-5561 URL: https://issues.apache.org/jira/browse/DERBY-5561 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.8.2.2 Environment: Solaris 10 Glassfish V2.1.1 ClientXADataSource connection pool Reporter: Brett Bergquist Assignee: Siddharth Srivastava Labels: derby_triage10_9 Attachments: DERBY-5561.patch There are race conditions with checkForNullPhysicalConnection calls in LogicalConnection. checkForNullPhysicalConnection is not synchronized and it checks for the member phsyicalConnection which can be cleared by nullPhsyicalConnection (which is synchronized) and close (which is synchronized) and closeWithoutRecyclingToPool (which is synchronized). This affects nativeSQL, getAutoCommit, getTransactionIsolation, getWarnings, isReadOnly, getCatalog, getTypeMap, createStatement, prepareCall, prepareStatement, setHoldability, getHoldability, setSavePoint, rollBack, releaseSavePoint, getSchema, setSchema. All of these call checkForNullPhysicalConnection and then use the member physicalConnection after that call returns. Because these methods are not synchronized, between the time checkForNullPhysicalConnectoin returns and physicalConnection is used, the physicalConnection member could be set to null and then a NPE occurs. Probably all of these methods should be changed to synchronized. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5220) Output from org.apache.derby.drda.NetworkServerControl runtimeinfo are truncated if the amount of data exceeds some threshold
[
https://issues.apache.org/jira/browse/DERBY-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5220:
--
Urgency: Low
Labels: derby_triage10_9 (was: )
Soren Vejrup Carlsen, can you verify this problem is fixed with 10.8.2.2 which
has the fix for DERBY-5326?
Knut mentioned that fix may correct this problem.
Also triage for 10.9. Mark low for now. Awaiting fix verification.
Output from org.apache.derby.drda.NetworkServerControl runtimeinfo are
truncated if the amount of data exceeds some threshold
-
Key: DERBY-5220
URL: https://issues.apache.org/jira/browse/DERBY-5220
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.5.3.0
Environment: java -Xmx1536m -cp
/home/test/CSRTEST7/lib/db/derbynet.jar:/home/test/CSRTEST7/lib/db/derby.jar
org.apache.derby.drda.NetworkServerControl sysinfo -p 8128
- Derby Network Server Information
Version: CSS10050/10.5.3.0 - (802917) Build: 802917 DRDA Product Id:
CSS10050
-- listing properties --
derby.drda.maxThreads=0
derby.drda.sslMode=off
derby.drda.keepAlive=true
derby.drda.minThreads=0
derby.drda.portNumber=8128
derby.drda.logConnections=false
derby.drda.timeSlice=0
derby.drda.startNetworkServer=false
derby.drda.host=localhost
derby.drda.traceAll=false
-- Java Information --
Java Version:1.6.0_21
Java Vendor: Sun Microsystems Inc.
Java home: /usr/java/jdk1.6.0_21/jre
Java classpath:
/home/test/CSRTEST7/lib/db/derbynet.jar:/home/test/CSRTEST7/lib/db/derby.jar
OS name: Linux
OS architecture: i386
OS version: 2.6.18-53.el5PAE
Java user name: test
Java user home: /home/test
Java user dir: /home/test/CSRTEST7
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[/home/test/CSRTEST7/lib/db/derby.jar] 10.5.3.0 - (802917)
[/home/test/CSRTEST7/lib/db/derbynet.jar] 10.5.3.0 - (802917)
--
- Locale Information -
--
Reporter: Soren Vejrup Carlsen
Labels: derby_triage10_9
When using the runtimeinfo command with the
org.apache.derby.drda.NetworkServerControl program
It seems that the output is truncated, as if the output exceeeds some
threshold or met some internal timeout, so that it does not wait for the rest
of the data.
In that case, the output starts with
{code}
-- Derby Network Server Runtime Information ---
-- Session Information ---
Session # :1
Database :harvestDatabase/fullhddb
User :APP
# Statements:12
{code}
but does not end with something like
{code}
-
# Connection Threads : 3
# Active Sessions : 3
# Waiting Sessions : 0
Total Memory : 64356352 Free Memory : 62239544
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5234) Unable to insert data into table. Failed due be ERROR XSDG0: Page Page(51919,Container(0, 1104)) could not be read from disk.
[ https://issues.apache.org/jira/browse/DERBY-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5234: -- Component/s: (was: Network Server) (was: SQL) (was: JDBC) Store Priority: Critical (was: Major) Issue fix info: High Value Fix,Repro attached Labels: ERROR XSDG0 apache corruption data derby derby_triage10_9 (was: ERROR XSDG0 apache corruption data derby) Triage for 10.9. Marking Critical priority, Urgent Urgency, High Value Fix. Changing component to store. I was able to reproduce with the attached repro at 10.9.0.0 alpha - (1242867) java.sql.SQLException: Page Page(10219,Container(0, 1168)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2340) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1715) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:311) at DbCompressErrorTester.insertData(DbCompressErrorTester.java:162) at DbCompressErrorTester.test(DbCompressErrorTester.java:116) at DbCompressErrorTester.main(DbCompressErrorTester.java:38) Caused by: java.sql.SQLException: Page Page(10219,Container(0, 1168)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:12 2) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) ... 12 more Caused by: java.sql.SQLException: Java exception: 'Reached end of file while attempting to read a whole page.: java.io.E OFException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:12 2) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:436) ... 10 more Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page. at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:1169) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(RAFContainer4.java:430) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:370) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:263) at org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:673) at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:193) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.store.raw.data.FileContainer.initPage(FileContainer.java:2430) at org.apache.derby.impl.store.raw.data.FileContainer.newPage(FileContainer.java:1878) at org.apache.derby.impl.store.raw.data.BaseContainer.addPage(BaseContainer.java:314) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.addPage(BaseContainerHandle.java:183) at org.apache.derby.impl.store.access.heap.HeapController.doInsert(HeapController.java:302) at org.apache.derby.impl.store.access.heap.HeapController.insert(HeapController.java:575) at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java:457) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:999) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:519) at
[jira] [Updated] (DERBY-5261) NetworkServerControl prints usage message twice on some errors
[
https://issues.apache.org/jira/browse/DERBY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5261:
--
Urgency: Low
Labels: derby_triage10_9 (was: )
NetworkServerControl prints usage message twice on some errors
--
Key: DERBY-5261
URL: https://issues.apache.org/jira/browse/DERBY-5261
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.8.1.2
Reporter: Knut Anders Hatlen
Priority: Minor
Labels: derby_triage10_9
If you invoke NetworkServerControl with an invalid command, the usage message
will be printed twice.
$ java -jar derbynet.jar abc
Mon Jun 06 10:14:25 CEST 2011 : Command abc is unknown.
Usage: NetworkServerControl commands
Commands:
start [-h host] [-p portnumber] [-noSecurityManager] [-ssl sslmode]
shutdown [-h host][-p portnumber] [-ssl sslmode] [-user username]
[-password password]
ping [-h host][-p portnumber] [-ssl sslmode]
sysinfo [-h host][-p portnumber] [-ssl sslmode]
runtimeinfo [-h host][-p portnumber] [-ssl sslmode]
logconnections {on|off} [-h host][-p portnumber] [-ssl sslmode]
maxthreads max[-h host][-p portnumber] [-ssl sslmode]
timeslice milliseconds[-h host][-p portnumber] [-ssl sslmode]
trace {on|off} [-s session id][-h host][-p portnumber] [-ssl sslmode]
tracedirectory traceDirectory[-h host][-p portnumber] [-ssl sslmode]
Mon Jun 06 10:14:25 CEST 2011 : No command given.
Usage: NetworkServerControl commands
Commands:
start [-h host] [-p portnumber] [-noSecurityManager] [-ssl sslmode]
shutdown [-h host][-p portnumber] [-ssl sslmode] [-user username]
[-password password]
ping [-h host][-p portnumber] [-ssl sslmode]
sysinfo [-h host][-p portnumber] [-ssl sslmode]
runtimeinfo [-h host][-p portnumber] [-ssl sslmode]
logconnections {on|off} [-h host][-p portnumber] [-ssl sslmode]
maxthreads max[-h host][-p portnumber] [-ssl sslmode]
timeslice milliseconds[-h host][-p portnumber] [-ssl sslmode]
trace {on|off} [-s session id][-h host][-p portnumber] [-ssl sslmode]
tracedirectory traceDirectory[-h host][-p portnumber] [-ssl sslmode]
Printing it once should be enough.
The same problem is seen if you don't specify a required argument for an
option. For example java -jar derbynet start -p (no port number).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5400) Toggling of network tracing should be protected by requiring the user to specify the credentials of the system administrator.
[ https://issues.apache.org/jira/browse/DERBY-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5400: -- Issue fix info: Release Note Needed Labels: derby_triage10_9 (was: ) Triage for 10.9. Marking Release note needed as this would be a behavior change. Toggling of network tracing should be protected by requiring the user to specify the credentials of the system administrator. - Key: DERBY-5400 URL: https://issues.apache.org/jira/browse/DERBY-5400 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Labels: derby_triage10_9 For servers which are brought up with the system administrator's credentials, we should require those credentials to be specified when turning network tracing on and off. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5401) The NetServlet should require system administrator credentials in order to perform its operations on a server which requires authentication.
[ https://issues.apache.org/jira/browse/DERBY-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5401: -- Issue fix info: Release Note Needed Labels: derby_triage10_9 (was: ) Triage for 10.9. Marking relese note needed as it will be a behavior change. I tend to think that the servlet is mostly there for demo purposes, so considered changing urgency to Low, but left it at Normal. The NetServlet should require system administrator credentials in order to perform its operations on a server which requires authentication. Key: DERBY-5401 URL: https://issues.apache.org/jira/browse/DERBY-5401 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Labels: derby_triage10_9 If Derby authentication is required on the VM running derby.war, then the NetServlet forms should require system administrator credentials in order to issue any commands. In addition, the network connection between the browser forms and the VM should be encrypted so that those credentials cannot be snooped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
[ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5552: -- Urgency: Urgent Labels: derby_triage10_9 (was: ) Triage for 10.9. This issue is in progress and should be committed soon. I think I am going to just double check that subsequent operations on the connection start a new local transaction and that the old global transaction is really dead. The test confirms we cannot do an XA end but should probably also check the transaction table. If all that checks out I will check in the change as is. Thanks Mike and Brett for the input. Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs - Key: DERBY-5552 URL: https://issues.apache.org/jira/browse/DERBY-5552 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.1.2 Environment: Solaris 10, Glassfish V2.1.1, Reporter: Brett Bergquist Assignee: Kathey Marsden Priority: Blocker Labels: derby_triage10_9 Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, ReproDerby5552LockTimeout.java, appserverstack.txt, client.tar.Z, derby-5552_withtest_diff.txt, derby-5552_withtest_diff.txt, derby.log, derbystackatshutdown.txt, execute.patch, transactionsleft.txt The issue arrives when multiple XA transactions are done in parallel and there is either a lock timeout or a lock deadlock detected. When this happens the connection is leaked in the Glassfish connection pool and the client thread hangs in org.apache.derby.client.netReply.fill(Reply.java:172). Shutting down the app server fails because the thread has a lock in org.apache.derby.client.net.NetConnection40 and another task is calling org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214) which is waiting for the lock. Killing the appsever using kill and then attempting to shutdown Derby network server causes the Network Server to hang. One of the threads hangs waiting for a lock at org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525) and the main thread has this locked at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242) and it itself is waiting for a lock which belongs to a thread that is stuck at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118) which is in the TIMED_WAITING state. Only by killing the Network Server using kill is possible at this point. There are transactions left even though all clients have been removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5584) Select statement with subqueries with group by and count distinct statements returns wrong number of results
[ https://issues.apache.org/jira/browse/DERBY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5584: -- Component/s: (was: Network Server) SQL Issue fix info: High Value Fix,Patch Available,Repro attached Urgency: Urgent Bug behavior facts: Deviation from standard,Wrong query result (was: Deviation from standard) Labels: derby_triage10_9 (was: ) Triage for 10.9. Moved component to SQL and checked appropriate boxes. I wonder. Is this a regression? Thanks Bryan for working on this issue. Select statement with subqueries with group by and count distinct statements returns wrong number of results Key: DERBY-5584 URL: https://issues.apache.org/jira/browse/DERBY-5584 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.7.1.1 Environment: Output from sysinfo java.specification.name: Java Platform API Specification java.specification.version: 1.6 java.runtime.version: 1.6.0_20-b02 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derby.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbytools.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbynet.jar] 10.7.1.1 - (1040133) [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbyclient.jar] 10.7.1.1 - (1040133) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.7.1.1 - (1040133) Found support for locale: [de_DE] version: 10.7.1.1 - (1040133) Found support for locale: [es] version: 10.7.1.1 - (1040133) Found support for locale: [fr] version: 10.7.1.1 - (1040133) Found support for locale: [hu] version: 10.7.1.1 - (1040133) Found support for locale: [it] version: 10.7.1.1 - (1040133) Found support for locale: [ja_JP] version: 10.7.1.1 - (1040133) Found support for locale: [ko_KR] version: 10.7.1.1 - (1040133) Found support for locale: [pl] version: 10.7.1.1 - (1040133) Found support for locale: [pt_BR] version: 10.7.1.1 - (1040133) Found support for locale: [ru] version: 10.7.1.1 - (1040133) Found support for locale: [zh_CN] version: 10.7.1.1 - (1040133) Found support for locale: [zh_TW] version: 10.7.1.1 - (1040133) Reporter: Piotr Zgadzaj Assignee: Bryan Pendleton Labels: derby_triage10_9 Attachments: patch1.txt, query.log, tests.out, tests.sql, try1.txt Steps to reproduce: 1. Create database, connect to database with any JDBC client 2. create two tables: CREATE TABLE TEST_5 ( profile_id INTEGER NOT NULL, group_ref INTEGER NOT NULL, matched_count INTEGER NOT NULL ); CREATE TABLE TEST_6 ( profile_id INTEGER NOT NULL, group_ref INTEGER NOT NULL, matched_count INTEGER NOT NULL ); 3. Insert two records for each table: insert into test_5 values (1, 1,1); insert into test_5 values (2, 1, 2); insert into test_6 values (1, 1,1); insert into test_6 values (2, 1, 2); 4. Run following statement SELECT * FROM (SELECT ps1.group_ref, COUNT(DISTINCT ps1.matched_count) AS matched_count FROM test_5 ps1 GROUP BY ps1.group_ref, ps1.profile_id ) a, (SELECT ps2.group_ref, COUNT( DISTINCT ps2.matched_count) AS matched_count FROM test_6 ps2 GROUP BY ps2.group_ref, ps2.profile_id ) b As a result I've got 3 records instead of 4 - at least Oracle 10g returns 4 records for this statement. Maybe i'm doing something wrong. Do you have any suggestions / possible workarounds for this problem -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5600) ) testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError: Failo
[ https://issues.apache.org/jira/browse/DERBY-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5600: -- Component/s: Replication Labels: derby_triage10_9 (was: ) ) testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError: Failover did not succeed at org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase. --- Key: DERBY-5600 URL: https://issues.apache.org/jira/browse/DERBY-5600 Project: Derby Issue Type: Bug Components: Network Server, Replication Affects Versions: 10.8.2.3 Environment: Linux vmware Reporter: Kathey Marsden Labels: derby_triage10_9 Saw this on Feb 1 run 10.8.2.3.129442 Linux vmware testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError: Failover did not succeed at org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase.java:813) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:359) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing.testReplication_Local_1_Indexing(ReplicationRun_Local_1Indexing.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code)) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code)) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java(Compiled Code)) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.runBare(ReplicationRun.java:222) at junit.extensions.TestDecorator.basicRun(TestDecorator.java(Inlined Compiled Code)) at junit.extensions.TestSetup$1.protect(TestSetup.java(Inlined Compiled Code)) at junit.extensions.TestSetup.run(TestSetup.java(Compiled Code)) Caused by: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08004, SQLERRMC: Connection refused to database '/local1/cloudtst/dev/src/NightlyBuildResults.2012-02-01/ibm142_suites.All/db_slave/wombat' because it is in replication slave mode. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java(Compiled Code)) at java.sql.DriverManager.getConnection(DriverManager.java(Compiled Code)) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:338) ... 31 more Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08004, SQLERRMC: Connection refused to database '/local1/cloudtst/dev/src/NightlyBuildResults.2012-02-01/ibm142_suites.All/db_slave/wombat' because it is in replication slave mode. at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown Source) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown Source) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown Source) at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source) at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source) at org.apache.derby.client.net.NetConnection.init(Unknown Source) at org.apache.derby.client.net.Cl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5600) ) testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError: Failo
[ https://issues.apache.org/jira/browse/DERBY-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5600: -- Urgency: Normal ) testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError: Failover did not succeed at org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase. --- Key: DERBY-5600 URL: https://issues.apache.org/jira/browse/DERBY-5600 Project: Derby Issue Type: Bug Components: Network Server, Replication Affects Versions: 10.8.2.3 Environment: Linux vmware Reporter: Kathey Marsden Labels: derby_triage10_9 Saw this on Feb 1 run 10.8.2.3.129442 Linux vmware testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError: Failover did not succeed at org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase.java:813) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:359) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing.testReplication_Local_1_Indexing(ReplicationRun_Local_1Indexing.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code)) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code)) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java(Compiled Code)) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.runBare(ReplicationRun.java:222) at junit.extensions.TestDecorator.basicRun(TestDecorator.java(Inlined Compiled Code)) at junit.extensions.TestSetup$1.protect(TestSetup.java(Inlined Compiled Code)) at junit.extensions.TestSetup.run(TestSetup.java(Compiled Code)) Caused by: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08004, SQLERRMC: Connection refused to database '/local1/cloudtst/dev/src/NightlyBuildResults.2012-02-01/ibm142_suites.All/db_slave/wombat' because it is in replication slave mode. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java(Compiled Code)) at java.sql.DriverManager.getConnection(DriverManager.java(Compiled Code)) at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:338) ... 31 more Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08004, SQLERRMC: Connection refused to database '/local1/cloudtst/dev/src/NightlyBuildResults.2012-02-01/ibm142_suites.All/db_slave/wombat' because it is in replication slave mode. at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown Source) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown Source) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown Source) at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source) at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source) at org.apache.derby.client.net.NetConnection.init(Unknown Source) at org.apache.derby.client.net.Cl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5610) ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes
[ https://issues.apache.org/jira/browse/DERBY-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5610: -- Urgency: Normal Labels: derby_triage10_9 (was: ) Triage for 10.9 ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes -- Key: DERBY-5610 URL: https://issues.apache.org/jira/browse/DERBY-5610 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.2.3 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Labels: derby_triage10_9 Attachments: derby-5610_diff.txt ServerPropertiesTest showed the below output when running. The ping retries and the test passes. I am not sure if in fact a Connection reset is a valid response if the server is not fully up and the test is just being too verbose or if it is real problem that we get this Error. .java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown Source) at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source) at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.shutdownServer(ServerPropertiesTest.java:309) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:484) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at
[jira] [Updated] (DERBY-5621) Failure in SecureServerTest )junit.framework.AssertionFailedError: Failed ping after changing trace directory:
[ https://issues.apache.org/jira/browse/DERBY-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5621: -- Urgency: Normal Labels: derby_triage10_9 (was: ) Failure in SecureServerTest )junit.framework.AssertionFailedError: Failed ping after changing trace directory: --- Key: DERBY-5621 URL: https://issues.apache.org/jira/browse/DERBY-5621 Project: Derby Issue Type: Bug Components: Network Server, Test Affects Versions: 10.9.0.0 Environment: ava.specification.name: Java Platform API Specification java.specification.version: 1.6 java.runtime.version: pxi3260sr9fp1-20110208_03 (SR9 FP1) java.fullversion: JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) J9VM - 20110203_074623 JIT - r9_20101028_17488ifx3 GC - 20101027_AA Reporter: Kathey Marsden Labels: derby_triage10_9 I saw this failure on Linux IBM 1.6 Feb 15 http://people.apache.org/~myrnavl/derby_test_results/main/linux/testSummary-1244826.html 1) SecureServerTest( Opened = false, Authenticated= true, CustomDerbyProperties= null, WildCardHost= 0.0.0.0 )junit.framework.AssertionFailedError: Failed ping after changing trace directory: at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.setTraceDirectory(SecureServerTest.java:381) at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.testServerStartup(SecureServerTest.java:352) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5606) NullPointerException at EncryptContainerOperation
[ https://issues.apache.org/jira/browse/DERBY-5606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5606: -- Fix Version/s: (was: 10.8.2.2) Labels: (was: patch) Unmarking Fix version as this is not yet fixed and removing patch label. The best thing to do is try to stand alone reproduction with a new database trying to change the encryption key. The files you deleted would be either index or base table definitions. The database is definitely corrupt after deletion of any files under the seg0 or log directory and behavior can be totally unpredictable. Had you deleted any files prior to getting the original NPE? NullPointerException at EncryptContainerOperation - Key: DERBY-5606 URL: https://issues.apache.org/jira/browse/DERBY-5606 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.8.2.2 Environment: windows 7 professional 64 bits and xp with Oracle jre1.6.0_30 Reporter: Jesus Marin Attachments: c3010.dat, c3021.dat As I try to change encryption key from a working encrypted db using: code jdbc:derby:c:\gexcat\gexcat.db5;dataEncryption=true;encryptionAlgorithm=AES/CBC/NoPadding;newEncryptionKey=0CE9CC799AADABAB295E4D91EAE86346;encryptionKey=0A023619DFD37A71263BEFCABBD68EA8 /code I get this error (from Stack trace): code java.sql.SQLException: Failed to start database 'c:\gexcat\gexcat.db5' with class loader net.sourceforge.squirrel_sql.fw.sql.SQLDriverClassLoader@21aac775, see the next exception for details. 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.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.AutoloadedDriver.connect(Unknown Source) at net.sourceforge.squirrel_sql.fw.sql.SQLDriverManager.getConnection(SQLDriverManager.java:133) at net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.execute(OpenConnectionCommand.java:97) at net.sourceforge.squirrel_sql.client.mainframe.action.ConnectToAliasCommand$SheetHandler.run(ConnectToAliasCommand.java:280) at net.sourceforge.squirrel_sql.client.mainframe.action.ConnectToAliasCommand$SheetHandler.performOK(ConnectToAliasCommand.java:237) at net.sourceforge.squirrel_sql.client.gui.db.ConnectionInternalFrame.connect(ConnectionInternalFrame.java:311) at net.sourceforge.squirrel_sql.client.gui.db.ConnectionInternalFrame.access$300(ConnectionInternalFrame.java:56) at net.sourceforge.squirrel_sql.client.gui.db.ConnectionInternalFrame$MyOkClosePanelListener.okPressed(ConnectionInternalFrame.java:461) at net.sourceforge.squirrel_sql.client.gui.OkClosePanel.fireButtonPressed(OkClosePanel.java:148) at net.sourceforge.squirrel_sql.client.gui.OkClosePanel.access$100(OkClosePanel.java:33) at net.sourceforge.squirrel_sql.client.gui.OkClosePanel$1.actionPerformed(OkClosePanel.java:174) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236) at java.awt.Component.processMouseEvent(Component.java:6290) at javax.swing.JComponent.processMouseEvent(JComponent.java:3267) at java.awt.Component.processEvent(Component.java:6055) at java.awt.Container.processEvent(Container.java:2039) at java.awt.Component.dispatchEventImpl(Component.java:4653) at java.awt.Container.dispatchEventImpl(Container.java:2097) at java.awt.Component.dispatchEvent(Component.java:4481) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4575) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4236) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4166) at java.awt.Container.dispatchEventImpl(Container.java:2083) at
[jira] [Updated] (DERBY-5487) Primary key disk pages not reclaimed when using SYSCS_UTIL.SYSCS_COMPRESS_TABLE with just the purge_rows option
[ https://issues.apache.org/jira/browse/DERBY-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5487: -- Issue fix info: (was: Newcomer) Fix Version/s: (was: 10.8.1.2) Labels: derby_triage10_8 (was: derby_triage10_8 patch) Removing fix version and patch label as there is no patch yet and the issue is not yet fixed. Could you please attach a stand-alone java reproduction for the issue? Primary key disk pages not reclaimed when using SYSCS_UTIL.SYSCS_COMPRESS_TABLE with just the purge_rows option --- Key: DERBY-5487 URL: https://issues.apache.org/jira/browse/DERBY-5487 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.8.1.2 Environment: Windows 7, Embedded Derby mode Reporter: Sundar Narayanaswamy Labels: derby_triage10_8 Attachments: DerbyInPlaceCompress.java, screenshot-1.jpg When I continuously insert data, delete the inserted data then compress with purge_rows option in a loop, space is not reclaimed from the primary key file. The inserts are committed every 1 rows, deletes committed every 5 rows. All the rows that were inserted are deleted. The primary key values continually increase (across the inserts) . All the activities occur on a single thread. Included below is the space table output after each iteration in the loop: As can be seen below and in the screenshot attached, the NumAllocatedpages for SQL111029001155930 is continuously increasing. This increase does not happen if the primary key values are reset after each iteration (ie, primary key values for new inserts are in the same range as deleted rows). Iteration: 0 ConglomerateNameIsIndex NumAllocatedPages NumFreePages NumUnFilledPagesPageSize EstimSpaceSaving LOCATION0 1 8031 4096 3289088 SQL111029003533400 1 238 31 179 4096 126976 LOC_INDEX 1 211 185119 4096 757760 Database size: 12993 KB Iteration: 1 ConglomerateNameIsIndex NumAllocatedPages NumFreePages NumUnFilledPagesPageSize EstimSpaceSaving LOCATION0 1 8161 4096 3342336 SQL111029003533400 1 324 192200 4096 786432 LOC_INDEX 1 1 4061 4096 1662976 Database size: 17112 KB Iteration: 2 ConglomerateNameIsIndex NumAllocatedPages NumFreePages NumUnFilledPagesPageSize EstimSpaceSaving LOCATION0 7 8101 4096 3317760 SQL111029003533400 1 579 23 294 4096 94208 LOC_INDEX 1 394 28 2 4096 114688 Database size: 22821 KB Iteration: 3 ConglomerateNameIsIndex NumAllocatedPages NumFreePages NumUnFilledPagesPageSize EstimSpaceSaving LOCATION0 1 8160 4096 3342336 SQL111029003533400 1 631 227451 4096 929792 LOC_INDEX 1 5 4373 4096 1789952 Database size: 18054 KB Iteration: 4 ConglomerateNameIsIndex NumAllocatedPages NumFreePages NumUnFilledPagesPageSize EstimSpaceSaving LOCATION0 1 8170 4096 3346432 SQL111029003533400 1 735 174460 4096 712704 LOC_INDEX 1 1 4411 4096 1806336 Database size: 15632 KB Iteration: 5 ConglomerateNameIsIndex NumAllocatedPages NumFreePages NumUnFilledPagesPageSize EstimSpaceSaving LOCATION0 4 8140 4096 3334144 SQL111029003533400 1 992 21 690 4096 86016 LOC_INDEX 1 378 64 127
[jira] [Updated] (DERBY-5041) NullPointerException in generated code in query with group by
[ https://issues.apache.org/jira/browse/DERBY-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5041: -- Fix Version/s: (was: 10.8.2.2) Umarking fix version as this is not yet fixed. I think should probably resolve cannot reproduce unless someone can provide a reproduction or more information. NullPointerException in generated code in query with group by - Key: DERBY-5041 URL: https://issues.apache.org/jira/browse/DERBY-5041 Project: Derby Issue Type: Bug Components: SQL Reporter: Lily Wei Report on behave of Pavel Bortnovskiy. Our query (which Pavel cannot show here for now) was complex, with case statements and 'group by' generated NullPointerException This is the stack: 2011-02-09 10:39:13,576 ERROR DataProcessor - SQL Exception due to executing statement after shutdown java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. 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.seeNextException(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.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source) at com.jefco.processors.DataProcessor.process(DataProcessor.java:189) at java.lang.Thread.run(Thread.java:619) Caused by: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 13 more 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) 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) ... 10 more Caused by: java.lang.NullPointerException at org.apache.derby.exe.ac96c5c136x012ex0b13x5d52x9ccc25960.e9(Unknown Source) at org.apache.derby.impl.services.reflect.DirectCall.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.doProjection(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowFromSource(Unknown Source) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) ... 5 more Interestingly, as soon as the query was reworked to remove group by clause, the code worked flawlessly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5035) [patch] equal objects should have equal hashcodes
[ https://issues.apache.org/jira/browse/DERBY-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5035: -- Fix Version/s: (was: 10.8.2.2) [patch] equal objects should have equal hashcodes - Key: DERBY-5035 URL: https://issues.apache.org/jira/browse/DERBY-5035 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.7.1.1 Reporter: Dave Brosius Priority: Trivial Attachments: equals_hashcode.diff Original Estimate: 1h Remaining Estimate: 1h equal objects should have equal hashCodes otherwise they don't work correctly in hash collections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4379) Let´s add comments to Derby SQL Syntax
[ https://issues.apache.org/jira/browse/DERBY-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4379: -- Affects Version/s: (was: 11.0.0.0) 10.8.2.2 Summary: Let´s add comments to Derby SQL Syntax (was: Let´s add comments to Derby) Let´s add comments to Derby SQL Syntax -- Key: DERBY-4379 URL: https://issues.apache.org/jira/browse/DERBY-4379 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Environment: N/A Reporter: Rami Ojares Fix For: 11.0.0.0 I could not find any previous issue about adding comments to Derby. I found one suggestion about it on the web somewhere but not here in Jira. DB2 and Oracle seem to have a separate COMMENT ON clause Eg. COMMENT ON TABLE EMPLOYEE IS 'Reflects first quarter 2000 reorganization' COMMENT ON COLUMN mytable.primarykey IS 'Unique ID from Sequence SEQ_MASTER' MySql on the other hand has a more compact syntax CREATE TABLE FOO (A COMMENT 'This col is A') COMMENT='And here is the table comment' I quess SQL standard does not talk about commenting objects like tables columns etc. (Although I am not sure, maybe someone could prove me wrong here). So I propose we start with syntax like CREATE TABLE TBL_NAME (coldefinition COMMENT 'colcomment' ...) COMMENT ' tablecomment' Column comment could appear anywhere where Column-level-constraint can and the same would apply for table comment. View comment could come after the query in view definition. We would only need to add reserved word COMMENT. (Although it is a common word and most certainly is used by someone as a column or tanle name). It might be that there is already a spot for comments (or should we say remarks) because the DatabaseMetadata returns a column with that name for every attribute. It is always empty now. This feature could take the self-documenting property of derby databases to the next level. I could code this feature but now I would like to know what people think about this issue in here and since I have not been coding Derby before then perhaps a few pointers would be helpful from someone who knows the soucecode of Derby well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-1102) Test triggerGeneral triggerStream (at least) uses internal old api's related to triggers.
[ https://issues.apache.org/jira/browse/DERBY-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1102: -- Fix Version/s: (was: 10.4.1.3) Test triggerGeneral triggerStream (at least) uses internal old api's related to triggers. --- Key: DERBY-1102 URL: https://issues.apache.org/jira/browse/DERBY-1102 Project: Derby Issue Type: Bug Components: SQL, Test Affects Versions: 10.2.1.6 Reporter: Daniel John Debrunner Priority: Minor Test uses the methods of TriggerExecutionContext to displat information about the tirgger. These are old non-standard and non-public interfaces from the old Cloudscape product. Tests should be re-written to not use such interfaces, only publshed interfaces which is all SQL for triggers. Methods on TriggerExecutionContext that are no longer required should be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5469) Make it possible to build Derby if you are on Mac OS X and your JDK is JDK 7
[ https://issues.apache.org/jira/browse/DERBY-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5469: -- Fix Version/s: 10.9.0.0 Make it possible to build Derby if you are on Mac OS X and your JDK is JDK 7 Key: DERBY-5469 URL: https://issues.apache.org/jira/browse/DERBY-5469 Project: Derby Issue Type: Improvement Components: Build tools Reporter: Rick Hillegas Assignee: Rick Hillegas Fix For: 10.9.0.0 Attachments: derby-5469-01-ae-add17andJavadoc.diff, derby-5469-01-af-dontSetUprevVariables.diff, derby-5469-01-ag-cleanedUp.diff, derby-5469-01-ah-cleanedUp.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5383) Add articles and blog links to the site's Resources tab
[ https://issues.apache.org/jira/browse/DERBY-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5383: -- Affects Version/s: 10.9.0.0 Fix Version/s: 10.9.0.0 Add articles and blog links to the site's Resources tab --- Key: DERBY-5383 URL: https://issues.apache.org/jira/browse/DERBY-5383 Project: Derby Issue Type: Improvement Components: Web Site Affects Versions: 10.9.0.0 Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Priority: Minor Fix For: 10.9.0.0 Attachments: off.jpg, sitepatch-2.diff.gz, sitepatch-2.stat, sitepatch.diff.gz, sitepatch.stat It would be nice to add some links to stuff people have authored about Derby/Java DB and provide easy access to those in the Resources tab. I have collected some and intend to add a new page with such links. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5370) The toSQL method of the org.apache.derby.vti.Restriction class does not output correct constants for VARCHAR, Timestamp, Date, Time, or CHAR FOR BIT DATA types
[ https://issues.apache.org/jira/browse/DERBY-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5370: -- Fix Version/s: 10.9.0.0 10.8.2.3 The toSQL method of the org.apache.derby.vti.Restriction class does not output correct constants for VARCHAR, Timestamp, Date, Time, or CHAR FOR BIT DATA types --- Key: DERBY-5370 URL: https://issues.apache.org/jira/browse/DERBY-5370 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.8.1.2 Reporter: Brett Bergquist Assignee: Brett Bergquist Fix For: 10.8.2.3, 10.9.0.0 Attachments: derby-5370-01-aa-withTest.diff, derby-5370.diff The toSQL method of the org.apache.derby.vti.Restriction class does not output correct constants for VARCHAR, Timestamp, Date, Time, or CHAR FOR BIT DATA types. This method is useful for building the WHERE clause when implementing a Restricted Table Function. The result of calling the toSQL method with restrictions on columns of these types does not produce valid SQL constants. For example with a VARCHAR column being restricted the single quote characters are not placed round the string constant. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5369) Restricted Table Function support should pass NOT EQUAL restrictions to initScan
[ https://issues.apache.org/jira/browse/DERBY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5369: -- Fix Version/s: 10.8.2.3 Restricted Table Function support should pass NOT EQUAL restrictions to initScan Key: DERBY-5369 URL: https://issues.apache.org/jira/browse/DERBY-5369 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.8.1.2 Reporter: Brett Bergquist Assignee: Rick Hillegas Labels: features Fix For: 10.8.2.3 Attachments: derby-5369-01-aa-inequalityOperator.diff, derby-5369.diff Restricted Table Function support should pass NOT EQUAL restrictions to initScan. Currently any != or constraints on the SQL used in the WHERE clause of a SELECT on a Restricted Table Funtion are not passed to the initScan method. These can be useful depending on how the Restricted Table Function is implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5363) Tighten permissions of DB files to owner with = JDK7
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5363: -- Fix Version/s: 10.9.0.0 Tighten permissions of DB files to owner with = JDK7 - Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Components: Miscellaneous, Services, Store Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Fix For: 10.9.0.0 Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, derby-5363-basic-2.diff, derby-5363-basic-2.stat, derby-5363-basic-3.diff, derby-5363-basic-3.stat, derby-5363-followup-linux.diff, derby-5363-followup-linux.diff, derby-5363-followup-unix.diff, derby-5363-followup-unix.diff, derby-5363-followup-unix.stat, derby-5363-followup.diff, derby-5363-full-1.diff, derby-5363-full-1.stat, derby-5363-full-2.diff, derby-5363-full-2.stat, derby-5363-full-3.diff, derby-5363-full-3.stat, derby-5363-full-4.diff, derby-5363-full-4.stat, derby-5363-full-5.diff, derby-5363-full-5.stat, derby-5363-limit-to-java7.diff, derby-5363-limit-to-java7.stat, derby-5363-limit-to-java7b.diff, derby-5363-limit-to-java7b.stat, derby-5363-server-1.diff, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5576) derby can't start or open in applet on safari 5.1.2
[
https://issues.apache.org/jira/browse/DERBY-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5576:
--
Issue fix info: (was: Newcomer)
Affects Version/s: 10.8.2.2
I think we are going to need a lot more information here to help. At least a
full message and server side stack trace from derby.log
The message XBM02 is as follows, so there is some severe class loader or other
issue preventing Derby from being loaded properly.
nameXBM02.D/name
textStartup failed due to missing functionality for {0}.
Please ensure your classpath includes the correct Derby software./text
argvalue/arg
derby can't start or open in applet on safari 5.1.2
---
Key: DERBY-5576
URL: https://issues.apache.org/jira/browse/DERBY-5576
Project: Derby
Issue Type: Bug
Affects Versions: 10.8.2.2
Environment: java 1.6.0_u30 or 1.7.0_u2
windowns xp sp3 or windows 7 sp1
safari 5.1.2
derby 10.8.2.2(derby.jar, derbyclient.jar, derbynet.jar)
IE work fine but safari error.
Reporter: moonumi
Priority: Critical
Labels: applet, derby, safari
XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams
ERROR XBM02: XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4794) NPE at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.finishAndRTS
[ https://issues.apache.org/jira/browse/DERBY-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4794: -- Affects Version/s: 10.3.3.0 Could you upgrade to 10.8.2 and let us know if you are still seeing this issue. Otherwise I think we should close cannot reproduce. NPE at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.finishAndRTS -- Key: DERBY-4794 URL: https://issues.apache.org/jira/browse/DERBY-4794 Project: Derby Issue Type: Bug Components: Miscellaneous, SQL Affects Versions: 10.3.3.0 Environment: Derby version info -- as seen in MANIFEST.MF Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.5 Created-By: 1.4.2_12-b03 (Sun Microsystems Inc.) Bundle-Vendor: Apache Software Foundation Bundle-Name: Apache Derby 10.3 Bundle-Version: 10.3.104.561794 Sealed: true Reporter: Manoranjan Sahu Labels: derby_triage10_8 Derby is throwing NPE randomly while executing simple sql statements. Stack trace in derby.log 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.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source) at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeSelect(DatabaseAccessor.java:726) at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:501) ... 58 more 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) ... 70 more Caused by: java.lang.NullPointerException at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.finishAndRTS(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.finish(Unknown Source) at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 63 more It is noticed that this issue is happening randomly , during selects and inserts. I did not find any quick reproduction steps for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5605) Calling Blob/Clob free() explicitly after implicit free throws exception in client driver
[ https://issues.apache.org/jira/browse/DERBY-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5605: -- Priority: Minor (was: Trivial) Issue fix info: Newcomer,Repro attached,Workaround attached Urgency: Normal Bug behavior facts: Embedded/Client difference Labels: derby_triage10_9 (was: ) Triage for 10.9. Moved priority from trivial to minor as I think it could be hit by applications expecting this to work. Calling Blob/Clob free() explicitly after implicit free throws exception in client driver - Key: DERBY-5605 URL: https://issues.apache.org/jira/browse/DERBY-5605 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.9.0.0 Reporter: Kristian Waagan Priority: Minor Labels: derby_triage10_9 If a Blob or Clob is freed implicitly in the client driver, calling free explicitly afterwards will throw an exception. Instead, this should probably be a no-op. To reproduce, do something like this: con.setAutoCommit(false); Clob c = con.createClob(); con.commit(); c.free(); == Caused by: org.apache.derby.client.am.SqlException: You cannot invoke other java.sql.Clob/java.sql.Blob methods after calling the free() method or after the Blob/Clob's transaction has been committed or rolled back. at org.apache.derby.client.am.CallableLocatorProcedures.handleInvalidLocator(CallableLocatorProcedures.java:1071) at org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:664) at org.apache.derby.client.am.Clob.free(Clob.java:844) ... 38 more Caused by: org.apache.derby.client.am.SqlException: The exception 'java.sql.SQLException: The locator that was supplied for this CLOB/BLOB is invalid' was thrown while evaluating an expression. at org.apache.derby.client.am.Statement.completeExecute(Statement.java:1604) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:322) at org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:106) at org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) at org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:175) at org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1570) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2156) at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1599) at org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:662) ... 39 more Caused by: org.apache.derby.client.am.SqlException: The locator that was supplied for this CLOB/BLOB is invalid ... 48 more The problem dosen't exist in the embedded driver. The immediate cause seems to be that the client driver state becomes out of sync with the server side. This may be fixable by dealing specifically witht the invalid locator exception in free(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5599) readlocks.sql fails with extra locks.
[ https://issues.apache.org/jira/browse/DERBY-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5599: -- Component/s: Test Summary: readlocks.sql fails with extra locks. (was: readlocks.sql fails with extra locks. Possibly Automatic Index statistics kicking off during test) Changing component to test and adjusting title to remove statistics. Not likely the cause after all. readlocks.sql fails with extra locks. - Key: DERBY-5599 URL: https://issues.apache.org/jira/browse/DERBY-5599 Project: Derby Issue Type: Bug Components: Test Reporter: Kathey Marsden Assignee: Mike Matrigali I saw this failure for the Feb 1 run at: http://people.apache.org/~myrnavl/derby_test_results/v10_8/linux/testlog/ibm15/1239442-derbyall_diff.txt I think it is likely the index statistics update kicking in during the test. I am thinking should not be disabled for the derbyall store tests as having it kick in can cause upredictable reporting of locks pages used, etc. *** Start: readlocks jdk1.5.0 storeall:storemore 2012-02-01 21:11:01 *** 3a4 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE 11122a11124 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE 11131a11134 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE 11138a11142 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE Test Failed. *** End: readlocks jdk1.5.0 storeall:storemore 2012-02-01 21:13:31 *** -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5594) SecureServerTest java.io.IOException: Interrupted system call
[ https://issues.apache.org/jira/browse/DERBY-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5594: -- Component/s: Test Making this test compoent for now. Not sure SecureServerTest java.io.IOException: Interrupted system call -- Key: DERBY-5594 URL: https://issues.apache.org/jira/browse/DERBY-5594 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.2.3 Environment: linix vmware IBM 1.7 java.runtime.version: pxi3270-20110827_01 java.fullversion: JRE 1.7.0 IBM J9 2.6 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled) J9VM - R26_Java726_GA_20110810_1208_B88592 JIT - r11_20110810_20466 GC - R26_Java726_GA_20110810_1208_B88592 J9CL - 20110810_88604 Reporter: Kathey Marsden On 10.8.2.3 - (1236960) linux vmware, I saw the following failure. 1) SecureServerTest( Opened = false, Authenticated= true, CustomDerbyProperties= null, WildCardHost= 0.00.000.0 )junit.framework.AssertionFailedError: Timed out waiting for network server to start:Spawned SpawnedNetworkServer exitCode=143 STDERR: java.io.IOException: Interrupted system call at java.io.FileInputStream.read(FileInputStream.java:255) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) at java.io.FilterInputStream.read(FilterInputStream.java:118) at org.apache.derbyTesting.junit.SpawnedProcess$2.run(SpawnedProcess.java:246) at java.lang.Thread.run(Thread.java:769) STDOUT: Sat Jan 28 06:30:04 PST 2012 : Security manager installed using the Basic server security policy. java.io.IOException: Interrupted system call at java.io.FileInputStream.read(FileInputStream.java:255) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) at java.io.FilterInputStream.read(FilterInputStream.java:118) at org.apache.derbyTesting.junit.SpawnedProcess$2.run(SpawnedProcess.java:246) at java.lang.Thread.run(Thread.java:769) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:210) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5571) IndexStatisticsDaemonImpl.schedule should wrap Thread.setDaemon() in a privilege block
[
https://issues.apache.org/jira/browse/DERBY-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5571:
--
Component/s: Services
IndexStatisticsDaemonImpl.schedule should wrap Thread.setDaemon() in a
privilege block
---
Key: DERBY-5571
URL: https://issues.apache.org/jira/browse/DERBY-5571
Project: Derby
Issue Type: Bug
Components: Services
Reporter: Kathey Marsden
IndexStatisticsDaemonImple.schedule() has the following code. setDaemon can
throw a SecurityException so should be wrapped. It says: SecurityException -
if the current thread cannot modify this thread.
Does this mean that our documentation should require modifyThreadGroup privs
too?
Currently it is in our test policy but not the documentation:
// These permissions are needed by AssertFailure to dump the thread stack
// traces upon failure.
//permission java.lang.RuntimePermission getStackTrace;
permission java.lang.RuntimePermission modifyThreadGroup;
// If we're idle, fire off the worker thread.
if (runningThread == null) {
runningThread = new Thread(this, index-stat-thread);
// Make the thread a daemon thread, we don't want it to
stop
// the JVM from exiting. This is a precaution.
runningThread.setDaemon(true);
Marking as a regression as a security violation could make existing
statements fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5579) Trigger fails with ERROR XSAI2: The conglomerate (136,048) requested does not exist possibly related to compress
[ https://issues.apache.org/jira/browse/DERBY-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5579: -- Component/s: Store Trigger fails with ERROR XSAI2: The conglomerate (136,048) requested does not exist possibly related to compress Key: DERBY-5579 URL: https://issues.apache.org/jira/browse/DERBY-5579 Project: Derby Issue Type: Bug Components: Store Environment: Derby version: 10.5.3.2 - (1073208) ava.vendor=IBM Corporation java.runtime.version=pwi32devifx-20110209 (SR11 FP2 +IZ94331) java.fullversion=J2RE 1.5.0 IBM J9 2.3 Windows Server 2003 x86-32 j9vmwi3223ifx-20100511 (JIT enabled) J9VM - 20100509_57823_lHdSMr JIT - 20091016_1845ifx7_r8 GC - 20091026_AA Reporter: Kathey Marsden I do not have a lot of information on this issue but want to get it filed in case someone sees something in the code that could cause this problem.. After the user started doing regular compress The report was on an error: java.sql.SQLException: The conglomerate (136048) requested does not exist. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.PreparedStatement.execute(Unknown Source) at com.ibm.team.repository.service.internal.db.jdbcwrappers.stat.PreparedStatementStatWrapper.execute(PreparedStatementStatWrapper.java:51) ERROR XSAI2: The conglomerate (136,048) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(Unknown Source) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.init(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.init(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.init(Unknown Source) at org.apache.derby.impl.sql.execute.GenericResultSetFactory.getDeleteResultSet(Unknown Source) at org.apache.derby.exe.acfb160050x0134xa4edxddadx01381ca0102.fillResultSet(Unknown Source) at org.apache.derby.exe.acfb160050x0134xa4edxddadx01381ca0102.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeSubStatement(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) The problem statement was tracked to a trigger that had a invalid conglomerate in its stored plan. Dropping and recreating the triggers resolved the immediate symptoms at the user site. The root cause is thought to be related to some sort of problem with compress that the trigger stored prepared statements did not get invalidated. FYI: There was a prior runtime error (not sure if it was during compress or not). I tend to think this one may related to s JVM JIT issue. java.sql.SQLException: The
[jira] [Updated] (DERBY-5565) Network Server should reject client connections that are not Derby Network Client
[ https://issues.apache.org/jira/browse/DERBY-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5565: -- Component/s: Network Server Affects Version/s: 10.9.0.0 Assignee: Kathey Marsden Network Server should reject client connections that are not Derby Network Client - Key: DERBY-5565 URL: https://issues.apache.org/jira/browse/DERBY-5565 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.9.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Since there have been no other network clients besides Derby Network Client tested or supported with Derby since 10.1 and since any protocol based client needs to understand Derby's DRDA extensions, deviations, and stored procedure usage. I think it would be a good idea in 10.9 for Network Server to outright reject any network clients that are not Derby Network Client. This would eliminate confusion up front for those that might not be aware that the DB2 Universal JDBC Driver and DB2 Runtime Client are not supported. They would get a clean reasonable error instead of hitting various protocol errors. Also it would mean if someone does want to add support for some network client in the future they would at least need to add the one or two lines of code in AppRequester to identify it, which I think would be a good thing. I think the code change would not be hard but the biggest impact might be anyone who still runs tests with JCC on trunk would need to disable those tests. There is a separate issue DERBY-4785 that Jayaram is working on to complete remove the JCC related code from the tests and test infrastructure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5431) If 10.7 or greater derbyclient.jar is in the classpath before an older release's server jars, derby fails to boot with NoSuchFieldError for JVMInfo.JAVA_SQL_TYPES_BOOLEAN
[ https://issues.apache.org/jira/browse/DERBY-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5431: -- Component/s: JDBC Assignee: Kathey Marsden If 10.7 or greater derbyclient.jar is in the classpath before an older release's server jars, derby fails to boot with NoSuchFieldError for JVMInfo.JAVA_SQL_TYPES_BOOLEAN -- Key: DERBY-5431 URL: https://issues.apache.org/jira/browse/DERBY-5431 Project: Derby Issue Type: Bug Components: JDBC Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Critical I noticed if 10.8 derbyclient.jar is before the 10.5 server jars, DERBY fails to boot with the error below. I think this field was removed in 10.7 so most like affects 10.7 as well. The root cause is DERBY-1046, but I am filing a separate issue for this specific case. This issue is currently blocking testing with 10.8 client and 10.5 server. $ java -Dij.exceptionTrace=true org.apache.derby.tools.ij ij version 10.5 ij connect 'jdbc:derby:wombat;create=true'; ERROR XJ041: Failed to create database 'wombat', see the next exception for details. java.sql.SQLException: Failed to create database 'wombat', see the next exception for details. 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.seeNextException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.createDatabase(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.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.AutoloadedDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:322) at java.sql.DriverManager.getConnection(DriverManager.java:297) at org.apache.derby.impl.tools.ij.ij.dynamicConnection(Unknown Source) at org.apache.derby.impl.tools.ij.ij.ConnectStatement(Unknown Source) at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) Caused by: java.sql.SQLException: Failed to create database 'wombat', see the next exception for details. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 19 more Caused by: java.sql.SQLException: Startup failed due to an exception. See next exception for details. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) 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.seeNextException(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) ... 16 more Caused by: java.sql.SQLException: Java exception: 'org/apache/derby/iapi/services/info/JVMInfo.JAVA_SQL_TYPES_BOOLEAN: java.lang.NoSuchFieldError'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) 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) ... 19 more Caused by:
[jira] [Updated] (DERBY-5431) If 10.7 or greater derbyclient.jar is in the classpath before an older release's server jars, derby fails to boot with NoSuchFieldError for JVMInfo.JAVA_SQL_TYPES_BOOLEAN
[ https://issues.apache.org/jira/browse/DERBY-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5431: -- Affects Version/s: 10.9.0.0 10.7.1.1 10.8.1.2 Fix Version/s: 10.8.2.2 10.9.0.0 If 10.7 or greater derbyclient.jar is in the classpath before an older release's server jars, derby fails to boot with NoSuchFieldError for JVMInfo.JAVA_SQL_TYPES_BOOLEAN -- Key: DERBY-5431 URL: https://issues.apache.org/jira/browse/DERBY-5431 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.7.1.1, 10.8.1.2, 10.9.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Critical Fix For: 10.8.2.2, 10.9.0.0 I noticed if 10.8 derbyclient.jar is before the 10.5 server jars, DERBY fails to boot with the error below. I think this field was removed in 10.7 so most like affects 10.7 as well. The root cause is DERBY-1046, but I am filing a separate issue for this specific case. This issue is currently blocking testing with 10.8 client and 10.5 server. $ java -Dij.exceptionTrace=true org.apache.derby.tools.ij ij version 10.5 ij connect 'jdbc:derby:wombat;create=true'; ERROR XJ041: Failed to create database 'wombat', see the next exception for details. java.sql.SQLException: Failed to create database 'wombat', see the next exception for details. 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.seeNextException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.createDatabase(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.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.AutoloadedDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:322) at java.sql.DriverManager.getConnection(DriverManager.java:297) at org.apache.derby.impl.tools.ij.ij.dynamicConnection(Unknown Source) at org.apache.derby.impl.tools.ij.ij.ConnectStatement(Unknown Source) at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) Caused by: java.sql.SQLException: Failed to create database 'wombat', see the next exception for details. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 19 more Caused by: java.sql.SQLException: Startup failed due to an exception. See next exception for details. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) 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.seeNextException(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) ... 16 more Caused by: java.sql.SQLException: Java exception: 'org/apache/derby/iapi/services/info/JVMInfo.JAVA_SQL_TYPES_BOOLEAN: java.lang.NoSuchFieldError'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at
[jira] [Updated] (DERBY-5429) With mixed jar versions the error java.lang.NoSuchMethodError: org/apache/derby/iapi/services/info/JVMInfo.javaDump() can occur because JVMInfo is in both derby.jar and
[ https://issues.apache.org/jira/browse/DERBY-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5429: -- Component/s: Services With mixed jar versions the error java.lang.NoSuchMethodError: org/apache/derby/iapi/services/info/JVMInfo.javaDump() can occur because JVMInfo is in both derby.jar and derbyclient.jar - Key: DERBY-5429 URL: https://issues.apache.org/jira/browse/DERBY-5429 Project: Derby Issue Type: Bug Components: Services Reporter: Kathey Marsden The class org.apache.derby.iapi.services.info.JVMInfo is in both derbyclient.jar and derby.jar. This means that if an older version of derbyclient.jar is in the classpath before derby.jar the following error can occur when a javaDump is triggered. java.lang.NoSuchMethodError: org/apache/derby/iapi/services/info/JVMInfo.javaDump()V at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.cleanupOnError(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.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.EmbeddedDriver.connect(Unknown Source) at org.apache.derby.impl.drda.Database.makeConnection(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) This was discovered running a 10.5.3.2 - (1171883) client (derbclient.jar and derbyTesting.jar) against a 10.8.2.1 - (1170221) server (derby.jar and derbynet.jar) with the derbyclient.jar first in the classpath. The test that failed was testConnectShutdownAuthentication, but but this should be reproducible by reducing derby.stream.error.extendedDiagSeverityLevel=0 and generating any error. Probably client needs its own separate JVMInfo class. I am not sure where it is used. Maybe it s -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5411) Client that does not have Security manager permission to connect gets ERROR 08006: Insufficient data while reading from the network Message should be clearer
[
https://issues.apache.org/jira/browse/DERBY-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5411:
--
Component/s: Network Client
Client that does not have Security manager permission to connect gets ERROR
08006: Insufficient data while reading from the network Message should be
clearer
---
Key: DERBY-5411
URL: https://issues.apache.org/jira/browse/DERBY-5411
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.8.2.2
Reporter: Kathey Marsden
Priority: Minor
I was doing a little remote testing for the release candidate and noticed if
a machine does not have permission to connect, then the client shows the
following exception:
ij connect 'jdbc:derby://9.72.133.41:1527/wombat';
ERROR 08006: Insufficient data while reading from the network - expected a
minimum of 6 bytes and received only 0 bytes. The connection has been term
inated.
java.sql.SQLNonTransientConnectionException: Insufficient data while reading
from the network - expected a minimum of 6 bytes and received only 0 byte
s. The connection has been terminated.
at
org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown
Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:322)
at java.sql.DriverManager.getConnection(DriverManager.java:297)
at org.apache.derby.impl.tools.ij.ij.dynamicConnection(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.ConnectStatement(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown
Source)
at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.main(Unknown Source)
at org.apache.derby.tools.ij.main(Unknown Source)
Caused by: org.apache.derby.client.am.DisconnectException: Insufficient data
while reading from the network - expected a minimum of 6 bytes and receiv
ed only 0 bytes. The connection has been terminated.
at org.apache.derby.client.net.Reply.fill(Unknown Source)
at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown
Source)
at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source)
at org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown
Source)
at
org.apache.derby.client.net.NetConnectionReply.readExchangeServerAttributes(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.readServerAttributesAndKeyExchange(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowConnect(Unknown
Source)
at org.apache.derby.client.net.NetConnection.init(Unknown Source)
at org.apache.derby.client.net.NetConnection40.init(Unknown Source)
at
org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown
Source)
... 12 more
It would be good to have a clearer error message:
To Reproduce, use the script and policy file below changing the url for
derby.codejars to the correct path for your enviroment also in the policy
file my.policy exchange x.x.x.x with the permitted host and y.y.y.y with the
disallowed host. Then try to connect from the disllowed host with connect
'jdbc:derby://x.x.x.x:1527/wombat';
Script startServer.sh:
java -Djava.security.manager
-Dderby.codejars=file:c:/cygwin/home/kmarsden/projects/10.8.2testing/db-derby-10.8.2.1-lib/lib/
-Djava.security.policy=my.policy org.apache.derby.drda.NetworkServerControl
start -h 0.0.0.0
Policy File my.policy (change x.x.x.x and y.y.y.y) to the allowed and
disallowed host respectively. )Since the y.y.y.y line is commented it is not
really relevant except for testing that remote connections work properly)
grant codeBase ${derby.codejars}derby.jar
{
//
// These permissions are needed for everyday, embedded Derby usage.
//
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission derby.*, read;
permission java.util.PropertyPermission user.dir, read;
permission
[jira] [Updated] (DERBY-5341) Client allows insert of stream in excess of column with non-white space characters
[
https://issues.apache.org/jira/browse/DERBY-5341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5341:
--
Component/s: Network Client
Client allows insert of stream in excess of column with non-white space
characters
---
Key: DERBY-5341
URL: https://issues.apache.org/jira/browse/DERBY-5341
Project: Derby
Issue Type: Bug
Components: Network Client
Reporter: Kathey Marsden
In converting LobLimits.java DERBY-1903 and trying to enable
LobLimitsLiteTest with client. I discovered that this case fails with client:
try {
insertClob2(ClobTest #9.1 , conn, insertClob2,
MORE_DATA_THAN_COL_WIDTH, 4, 1,
MORE_DATA_THAN_COL_WIDTH, CHARDATAFILE);
fail(ClobTest #9.1 + should have thrown XSDA4);
} catch (SQLException sqle) {
assertSQLState(XSDA4, sqle);
}
// no row must be retrieved.
selectClob2(ClobTest #9.2 , conn, selectClob2, BIG_LOB_SZ, 4, 0,
CHARDATAFILE);
If I omit the fail assertion, the row actually does get inserted and has
presumably been truncated.
I will check in LobLimits.java soon with this bug number in the comments.
To reproduce, remove the if(!usingDerbyNetClient) condition and run the test
largedata.LobLimitsLiteTest to reproduce the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5137) Enable or remove Derby3980DeadlockTest
[ https://issues.apache.org/jira/browse/DERBY-5137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5137: -- Component/s: Test Enable or remove Derby3980DeadlockTest -- Key: DERBY-5137 URL: https://issues.apache.org/jira/browse/DERBY-5137 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.8.1.2 Reporter: Kathey Marsden As part of early work on DERBY-3980, I checked in an unrun test for this issue when I was working on it a long time ago, Derby3980DeadlockTest. I verified it does pass now but maybe the new DeadLockDetectionTest provides the same coverage. This this test should be enabled or removed if it adds no additional coverage. Derby3980DeadlockTest does seem to have some testing for extendedDiagSeverity level and diagProperties.setProperty(derby.stream.error.extendedDiagSeverityLevel, 3); One thing to note is that it now, with the IBM JVM, I think correctly will print JVMDUMP010I Java dump written to ... I am surprised though not to see a thread dump in derby.log, so maybe there is an issue with extendedDiagSeverity that needs to be looked at too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5069) Since Feb 7,2011 weme 6.2 Junit tests have failed to run completely with Failed to invoke suite():java.lang.reflect.InvocationTargetException
[ https://issues.apache.org/jira/browse/DERBY-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5069: -- Component/s: Test Since Feb 7,2011 weme 6.2 Junit tests have failed to run completely with Failed to invoke suite():java.lang.reflect.InvocationTargetException - Key: DERBY-5069 URL: https://issues.apache.org/jira/browse/DERBY-5069 Project: Derby Issue Type: Bug Components: Test Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Critical Fix For: 10.8.1.2 Attachments: TestWemeLoad.java, derby-5069_diff.txt Since Feb 8, the weme 6.2 Junit tests have failed to run. The only output on the test report is: Failed to invoke suite():java.lang.reflect.InvocationTargetException Below is the list of checkins on the day it started failing. derbyall looks ok. SUBVERSION LOG FROM 1067846 TO 1068253: r1068073 | rhillegas | 2011-02-07 11:34:02 -0800 (Mon, 07 Feb 2011) | 1 line DERBY-4869: Attempt to fix problem in tinderbox tests introduced by a previous commit today. r1067991 | rhillegas | 2011-02-07 08:04:25 -0800 (Mon, 07 Feb 2011) | 1 line DERBY-4869: Always raise SQLFeatureNotSupportedException when Connection.get/setNetworkTimeout() is called. r1067954 | rhillegas | 2011-02-07 06:54:31 -0800 (Mon, 07 Feb 2011) | 1 line DERBY-4869: Add JDBC 4.1 getParentLogger() method to Derby's implementations of Driver and CommonDataSource. This should be promoted to blocker if determined to be a product regression. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5347) Derby loops filling logs and consuming all CPU with repeated error: java.net.SocketException: EDC5122I Input/output error.
[ https://issues.apache.org/jira/browse/DERBY-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5347: -- Component/s: Network Server Derby loops filling logs and consuming all CPU with repeated error: java.net.SocketException: EDC5122I Input/output error. -- Key: DERBY-5347 URL: https://issues.apache.org/jira/browse/DERBY-5347 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.7.1.1 Environment: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-20100215 (SR11 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 Reporter: Force Rs Assignee: Kathey Marsden Fix For: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.2.2, 10.9.0.0 Attachments: derby-5347_10_8_diff.txt, derby-5347_diff.txt When a TCP/IP Stack on a z/OS system running Derby is stopped and started, Derby loops with the following stack trace repeated until disk space is exhausted on the logging file system: Wed Jul 20 07:49:51 CDT 2011 : EDC5122I Input/output error. java.net.SocketException: EDC5122I Input/output error. at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:457) at java.net.ServerSocket.implAccept(ServerSocket.java:473) at java.net.ServerSocket.accept(ServerSocket.java:444) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:241) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source) The derby log we generated was 498 megabytes and had 1,883,750 of these stack traces. Since Derby originated from IBM, the following link may provide a valuable clue as to how to fix the defect in Derby: http://www-01.ibm.com/support/docview.wss?uid=swg1PQ93090 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5599) readlocks.sql fails with extra locks.
[ https://issues.apache.org/jira/browse/DERBY-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5599: -- Affects Version/s: 10.8.2.3 readlocks.sql fails with extra locks. - Key: DERBY-5599 URL: https://issues.apache.org/jira/browse/DERBY-5599 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.2.3 Reporter: Kathey Marsden Assignee: Mike Matrigali I saw this failure for the Feb 1 run at: http://people.apache.org/~myrnavl/derby_test_results/v10_8/linux/testlog/ibm15/1239442-derbyall_diff.txt I think it is likely the index statistics update kicking in during the test. I am thinking should not be disabled for the derbyall store tests as having it kick in can cause upredictable reporting of locks pages used, etc. *** Start: readlocks jdk1.5.0 storeall:storemore 2012-02-01 21:11:01 *** 3a4 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE 11122a11124 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE 11131a11134 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE 11138a11142 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE Test Failed. *** End: readlocks jdk1.5.0 storeall:storemore 2012-02-01 21:13:31 *** -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5571) IndexStatisticsDaemonImpl.schedule should wrap Thread.setDaemon() in a privilege block
[
https://issues.apache.org/jira/browse/DERBY-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5571:
--
Affects Version/s: 10.8.2.2
IndexStatisticsDaemonImpl.schedule should wrap Thread.setDaemon() in a
privilege block
---
Key: DERBY-5571
URL: https://issues.apache.org/jira/browse/DERBY-5571
Project: Derby
Issue Type: Bug
Components: Services
Affects Versions: 10.8.2.2
Reporter: Kathey Marsden
IndexStatisticsDaemonImple.schedule() has the following code. setDaemon can
throw a SecurityException so should be wrapped. It says: SecurityException -
if the current thread cannot modify this thread.
Does this mean that our documentation should require modifyThreadGroup privs
too?
Currently it is in our test policy but not the documentation:
// These permissions are needed by AssertFailure to dump the thread stack
// traces upon failure.
//permission java.lang.RuntimePermission getStackTrace;
permission java.lang.RuntimePermission modifyThreadGroup;
// If we're idle, fire off the worker thread.
if (runningThread == null) {
runningThread = new Thread(this, index-stat-thread);
// Make the thread a daemon thread, we don't want it to
stop
// the JVM from exiting. This is a precaution.
runningThread.setDaemon(true);
Marking as a regression as a security violation could make existing
statements fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5579) Trigger fails with ERROR XSAI2: The conglomerate (136,048) requested does not exist possibly related to compress
[ https://issues.apache.org/jira/browse/DERBY-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5579: -- Affects Version/s: 10.5.3.2 Trigger fails with ERROR XSAI2: The conglomerate (136,048) requested does not exist possibly related to compress Key: DERBY-5579 URL: https://issues.apache.org/jira/browse/DERBY-5579 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.5.3.2 Environment: Derby version: 10.5.3.2 - (1073208) ava.vendor=IBM Corporation java.runtime.version=pwi32devifx-20110209 (SR11 FP2 +IZ94331) java.fullversion=J2RE 1.5.0 IBM J9 2.3 Windows Server 2003 x86-32 j9vmwi3223ifx-20100511 (JIT enabled) J9VM - 20100509_57823_lHdSMr JIT - 20091016_1845ifx7_r8 GC - 20091026_AA Reporter: Kathey Marsden I do not have a lot of information on this issue but want to get it filed in case someone sees something in the code that could cause this problem.. After the user started doing regular compress The report was on an error: java.sql.SQLException: The conglomerate (136048) requested does not exist. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.PreparedStatement.execute(Unknown Source) at com.ibm.team.repository.service.internal.db.jdbcwrappers.stat.PreparedStatementStatWrapper.execute(PreparedStatementStatWrapper.java:51) ERROR XSAI2: The conglomerate (136,048) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(Unknown Source) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.init(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.init(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.init(Unknown Source) at org.apache.derby.impl.sql.execute.GenericResultSetFactory.getDeleteResultSet(Unknown Source) at org.apache.derby.exe.acfb160050x0134xa4edxddadx01381ca0102.fillResultSet(Unknown Source) at org.apache.derby.exe.acfb160050x0134xa4edxddadx01381ca0102.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeSubStatement(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) The problem statement was tracked to a trigger that had a invalid conglomerate in its stored plan. Dropping and recreating the triggers resolved the immediate symptoms at the user site. The root cause is thought to be related to some sort of problem with compress that the trigger stored prepared statements did not get invalidated. FYI: There was a prior runtime error (not sure if it was during compress or not). I tend to think this one may related to s JVM
[jira] [Updated] (DERBY-5429) With mixed jar versions the error java.lang.NoSuchMethodError: org/apache/derby/iapi/services/info/JVMInfo.javaDump() can occur because JVMInfo is in both derby.jar and
[ https://issues.apache.org/jira/browse/DERBY-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5429: -- Affects Version/s: 10.8.2.2 With mixed jar versions the error java.lang.NoSuchMethodError: org/apache/derby/iapi/services/info/JVMInfo.javaDump() can occur because JVMInfo is in both derby.jar and derbyclient.jar - Key: DERBY-5429 URL: https://issues.apache.org/jira/browse/DERBY-5429 Project: Derby Issue Type: Bug Components: Services Affects Versions: 10.8.2.2 Reporter: Kathey Marsden The class org.apache.derby.iapi.services.info.JVMInfo is in both derbyclient.jar and derby.jar. This means that if an older version of derbyclient.jar is in the classpath before derby.jar the following error can occur when a javaDump is triggered. java.lang.NoSuchMethodError: org/apache/derby/iapi/services/info/JVMInfo.javaDump()V at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.cleanupOnError(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.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.EmbeddedDriver.connect(Unknown Source) at org.apache.derby.impl.drda.Database.makeConnection(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) This was discovered running a 10.5.3.2 - (1171883) client (derbclient.jar and derbyTesting.jar) against a 10.8.2.1 - (1170221) server (derby.jar and derbynet.jar) with the derbyclient.jar first in the classpath. The test that failed was testConnectShutdownAuthentication, but but this should be reproducible by reducing derby.stream.error.extendedDiagSeverityLevel=0 and generating any error. Probably client needs its own separate JVMInfo class. I am not sure where it is used. Maybe it s -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5341) Client allows insert of stream in excess of column with non-white space characters
[
https://issues.apache.org/jira/browse/DERBY-5341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5341:
--
Affects Version/s: 10.9.0.0
Client allows insert of stream in excess of column with non-white space
characters
---
Key: DERBY-5341
URL: https://issues.apache.org/jira/browse/DERBY-5341
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.9.0.0
Reporter: Kathey Marsden
In converting LobLimits.java DERBY-1903 and trying to enable
LobLimitsLiteTest with client. I discovered that this case fails with client:
try {
insertClob2(ClobTest #9.1 , conn, insertClob2,
MORE_DATA_THAN_COL_WIDTH, 4, 1,
MORE_DATA_THAN_COL_WIDTH, CHARDATAFILE);
fail(ClobTest #9.1 + should have thrown XSDA4);
} catch (SQLException sqle) {
assertSQLState(XSDA4, sqle);
}
// no row must be retrieved.
selectClob2(ClobTest #9.2 , conn, selectClob2, BIG_LOB_SZ, 4, 0,
CHARDATAFILE);
If I omit the fail assertion, the row actually does get inserted and has
presumably been truncated.
I will check in LobLimits.java soon with this bug number in the comments.
To reproduce, remove the if(!usingDerbyNetClient) condition and run the test
largedata.LobLimitsLiteTest to reproduce the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4143) lang/aggregateOptimization.sql fails with different query plan on zos IBM 1.6 64bit
[ https://issues.apache.org/jira/browse/DERBY-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4143: -- Affects Version/s: 10.8.1.2 lang/aggregateOptimization.sql fails with different query plan on zos IBM 1.6 64bit --- Key: DERBY-4143 URL: https://issues.apache.org/jira/browse/DERBY-4143 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.1.2 Environment: java version 1.6.0 Java(TM) SE Runtime Environment (build pmz6460sr3-20081108_01(SR3)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64 jvmmz6460-20081107_25433 (JIT enabled, AOT enabled) J9VM - 20081105_025433_BHdSMr JIT - r9_20081031_1330 GC - 20081027_AB) JCL - 20081106_01 Reporter: Kathey Marsden Priority: Minor Labels: derby_triage10_8 Attachments: aggregateOptimization.out lang/aggregateOptimization.sql fails with different query plan on zos IBM 1.6 64bit. The query results look fine. See attached out file for the plan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4641) aggregateOptimization.sql fails on z/os with pmz3160sr5 with double quote and question mark output in runtime statistics
[ https://issues.apache.org/jira/browse/DERBY-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4641: -- Affects Version/s: 10.5.3.0 aggregateOptimization.sql fails on z/os with pmz3160sr5 with double quote and question mark output in runtime statistics - Key: DERBY-4641 URL: https://issues.apache.org/jira/browse/DERBY-4641 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.5.3.0 Environment: $ java -version java version 1.6.0 Java(TM) SE Runtime Environment (build pmz3160sr5-20090604_01(SR5)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390-31 jvmmz3160sr5-20090519_3 5743 (JIT enabled, AOT enabled) J9VM - 20090519_035743_bHdSMr JIT - r9_20090518_2017 GC - 20090417_AA) JCL - 20090529_01 $ Reporter: Kathey Marsden Priority: Minor Labels: derby_triage10_8 Attachments: aggregateOptimizationOutputAfterAsciiFtp.zip, aggregateOptimizationOutputAsOnZos.zip With this one test and pmz3160sr5-20090604_01(SR5) the output of runtime statistics has double quote and question mark garbage, e.g Source result set: Scalar Aggregate ResultSet: Number of opens = 1 Rows input = 1 constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 optimizer estimated row count: 15.00 optimizer estimated cost: 21.13 Index Key Optimization = true Source result set: Looking manually at the plans, they look fine. I think this is likely a JVM issue, but don't know actually if it is impacting the test harness, ij, or derby itself. I did not see this with the 64 bit sr5 jvm, nor did I see it in 10.5 runs with earlier versions of the jvm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5610) ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes
[ https://issues.apache.org/jira/browse/DERBY-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5610: -- Affects Version/s: 10.8.2.3 ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes -- Key: DERBY-5610 URL: https://issues.apache.org/jira/browse/DERBY-5610 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.2.3 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Attachments: derby-5610_diff.txt ServerPropertiesTest showed the below output when running. The ping retries and the test passes. I am not sure if in fact a Connection reset is a valid response if the server is not fully up and the test is just being too verbose or if it is real problem that we get this Error. .java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown Source) at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source) at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.shutdownServer(ServerPropertiesTest.java:309) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:484) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source) at
[jira] [Updated] (DERBY-5511) NetworkServerControl start in java applicaton but it's exit with application main thread exit
[
https://issues.apache.org/jira/browse/DERBY-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5511:
--
Issue fix info: (was: Patch Available)
I think this should be closed as not a bug.
Derby network server does not block exit.
Also unmarking patch available.
NetworkServerControl start in java applicaton but it's exit with application
main thread exit
-
Key: DERBY-5511
URL: https://issues.apache.org/jira/browse/DERBY-5511
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.8.2.2
Environment: java 1.6.0_u29 64bit windows 7 sp1
Reporter: moonumi
public static void main(String[] args) {
NetworkServerControl serverControl=new
NetworkServerControl(InetAddress.getByName(localhost),1527);
serverControl.start(new PrintWriter(System.out,true));
}
run java application.
derby started servermode.
but imediate exit with application main thread.
it do not wait other connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5035) [patch] equal objects should have equal hashcodes
[ https://issues.apache.org/jira/browse/DERBY-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5035: -- Issue fix info: (was: Patch Available) Unmarking patch available as there seem to be review comments to address [patch] equal objects should have equal hashcodes - Key: DERBY-5035 URL: https://issues.apache.org/jira/browse/DERBY-5035 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.7.1.1 Reporter: Dave Brosius Priority: Trivial Fix For: 10.8.2.2 Attachments: equals_hashcode.diff Original Estimate: 1h Remaining Estimate: 1h equal objects should have equal hashCodes otherwise they don't work correctly in hash collections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4183: -- Issue fix info: Newcomer (was: Patch Available,Newcomer) umarking patch available as there are outstanding questions on the patch. Our regression tests use various jar files for which we don't have build scripts. - Key: DERBY-4183 URL: https://issues.apache.org/jira/browse/DERBY-4183 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.6.1.0 Reporter: Rick Hillegas Attachments: status.diff, testjars.diff, testjars.diff, testjars.diff, testjars.diff We should add build scripts for these jar files. This is a mini-project suitable for a newcomer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
[ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5552: -- Attachment: derby-5552_withtest_diff.txt reattaching patch to make minor comment correction. I still would like someone more familiar with this area to look and see removing the nulling of the connection is going to cause problems in some scenarios and what those scenarios might be. Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs - Key: DERBY-5552 URL: https://issues.apache.org/jira/browse/DERBY-5552 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.1.2 Environment: Solaris 10, Glassfish V2.1.1, Reporter: Brett Bergquist Assignee: Kathey Marsden Priority: Blocker Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, ReproDerby5552LockTimeout.java, appserverstack.txt, client.tar.Z, derby-5552_withtest_diff.txt, derby-5552_withtest_diff.txt, derby.log, derbystackatshutdown.txt, execute.patch, transactionsleft.txt The issue arrives when multiple XA transactions are done in parallel and there is either a lock timeout or a lock deadlock detected. When this happens the connection is leaked in the Glassfish connection pool and the client thread hangs in org.apache.derby.client.netReply.fill(Reply.java:172). Shutting down the app server fails because the thread has a lock in org.apache.derby.client.net.NetConnection40 and another task is calling org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214) which is waiting for the lock. Killing the appsever using kill and then attempting to shutdown Derby network server causes the Network Server to hang. One of the threads hangs waiting for a lock at org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525) and the main thread has this locked at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242) and it itself is waiting for a lock which belongs to a thread that is stuck at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118) which is in the TIMED_WAITING state. Only by killing the Network Server using kill is possible at this point. There are transactions left even though all clients have been removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5582) Access denied (java.lang.RuntimePermission modifyThreadGroup) in IndexStatisticsDaemonImpl.schedule()
[ https://issues.apache.org/jira/browse/DERBY-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5582: -- Attachment: derby-5582_whitespace_diff.txt Access denied (java.lang.RuntimePermission modifyThreadGroup) in IndexStatisticsDaemonImpl.schedule() -- Key: DERBY-5582 URL: https://issues.apache.org/jira/browse/DERBY-5582 Project: Derby Issue Type: Bug Components: Services Affects Versions: 10.8.2.3 Reporter: Kathey Marsden Attachments: Derby5582Runner.java, MySecurityManager.java, derby-5582_10_8_try1_diff.txt, derby-5582_trunk_withtest_diff.txt, derby-5582_trunk_withtest_diff.txt, derby-5582_whitespace_diff.txt, derby5582.policy I user reported this exception with 10.8.2.3 - (1212722) when running regression tests against 10.8. As soon as the Index Statistics Thread was initialized they got the stack trace below. There was some discussion of this issue on the dev list: http://old.nabble.com/Report-of-security-manager-issue-with-10.8-and-ndexStatisticsDaemonImpl.schedule-to33137398.html I assume the failure is in runningThread = new Thread(this, index-stat-thread); Stack Trace: java.security.AccessControlException: Access denied (java.lang.RuntimePermission modifyThreadGroup) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:544) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:208) at com.ibm.ws.security.core.SecurityManager.checkAccess(SecurityManager.java:407) at java.lang.ThreadGroup.checkAccess(ThreadGroup.java:226) at java.lang.Thread.initialize(Thread.java:345) at java.lang.Thread.init(Thread.java:281) at java.lang.Thread.init(Thread.java:179) at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.schedule(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5610) ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes
[ https://issues.apache.org/jira/browse/DERBY-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5610: -- Component/s: (was: Test) Network Server I think this is actually a NetworkServer bug pingWithNoOpen should catch the IO exception and wrap it and then it would pass vetPing. I am not sure the best way to test. There are a couple of prints to System.out on errors in pingForServerUp. I think maybe these should be removed and just throw the error so test runs that only check for failures and not stack traces in the run output will catch unexpected failures. I tend to think that should be a separate checkin once tests settle down, so we don't introduce more volatility. I will file a separate issue for that. ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes -- Key: DERBY-5610 URL: https://issues.apache.org/jira/browse/DERBY-5610 Project: Derby Issue Type: Bug Components: Network Server Reporter: Kathey Marsden Priority: Minor ServerPropertiesTest showed the below output when running. The ping retries and the test passes. I am not sure if in fact a Connection reset is a valid response if the server is not fully up and the test is just being too verbose or if it is real problem that we get this Error. .java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown Source) at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source) at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.shutdownServer(ServerPropertiesTest.java:309) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:484) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at
[jira] [Updated] (DERBY-5610) ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes
[ https://issues.apache.org/jira/browse/DERBY-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5610: -- Attachment: derby-5610_diff.txt Here is a patch for this issue. I am ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes -- Key: DERBY-5610 URL: https://issues.apache.org/jira/browse/DERBY-5610 Project: Derby Issue Type: Bug Components: Network Server Reporter: Kathey Marsden Priority: Minor Attachments: derby-5610_diff.txt ServerPropertiesTest showed the below output when running. The ping retries and the test passes. I am not sure if in fact a Connection reset is a valid response if the server is not fully up and the test is just being too verbose or if it is real problem that we get this Error. .java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown Source) at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source) at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.shutdownServer(ServerPropertiesTest.java:309) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:484) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown
