[jira] Commented: (DERBY-3378) Derby's timer thread should have a name that identifies it as belong to a derby instance
[ https://issues.apache.org/jira/browse/DERBY-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570600#action_12570600 ] Serge Tsv commented on DERBY-3378: -- I do also think that maintaining some thread-naming policy could be quite helpful for debugging purposes, especially when running embedded in an environment with many threads (including Timer ones) started by other frameworks. I think that having an existing prefix derby. added to a thread name might be sufficient. But somehow a thread name generation should be centralized I guess, so that a thread naming policy could be changed without affecting the rest of the code. Should a new issue be created for this? Thanks! Derby's timer thread should have a name that identifies it as belong to a derby instance Key: DERBY-3378 URL: https://issues.apache.org/jira/browse/DERBY-3378 Project: Derby Issue Type: Improvement Components: Newcomer, Services Reporter: Daniel John Debrunner Priority: Minor Looking at the threads with jconsole when derby is running shows derby's timer thread as Timer-0. All other derby threads are given a name starting with 'derby.', would be useful if the same was true for the timer thread. In SingletonTimerFactory just use the Timer constructor that takes a name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3378) Derby's timer thread should have a name that identifies it as belong to a derby instance
[ https://issues.apache.org/jira/browse/DERBY-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570604#action_12570604 ] Kristian Waagan commented on DERBY-3378: Hi Serge, You are of course welcome to start working on this issue, and other issues you might find interesting! You need developer access in JIRA to assign yourself to this issue. Please send a mail requesting developer access to derby-dev@db.apache.org (include your JIRA user name). From what I read above, I think it will be a good move to fix what is originally described in the issue first. You can find some pieces of advice for Derby development on the wiki: http://wiki.apache.org/db-derby/DerbyDev Feel free to ask questions on the developer mailing list. Welcome to the Derby community :) Derby's timer thread should have a name that identifies it as belong to a derby instance Key: DERBY-3378 URL: https://issues.apache.org/jira/browse/DERBY-3378 Project: Derby Issue Type: Improvement Components: Newcomer, Services Reporter: Daniel John Debrunner Priority: Minor Looking at the threads with jconsole when derby is running shows derby's timer thread as Timer-0. All other derby threads are given a name starting with 'derby.', would be useful if the same was true for the timer thread. In SingletonTimerFactory just use the Timer constructor that takes a name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-3306) jdbc4.StatementEventsTest cannot be run individually in a clean environment
[
https://issues.apache.org/jira/browse/DERBY-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan reopened DERBY-3306:
Reopening to back out what I believe was an inappropriate change
('derby-3306-1c-create_db_by_default_and_test_fixes.diff ', revision 620480).
This commit caused a test regression on the J2ME platform, and it also brings
along some unneeded complexity in the JUnit framework.
The commit was done on the false assumption that there were many tests that had
the same problem as jdbc4.StatementEventsTest, but after writing a script to
run every test individually I found out that test is the only one.
Since the commit cannot be backed out cleanly (a test has been split into two
files), I will attach a patch that backs out the changes, fixes the
jdbc4.StatementEventsTest and resolves the test regression logged as DERBY-3412.
jdbc4.StatementEventsTest cannot be run individually in a clean environment
---
Key: DERBY-3306
URL: https://issues.apache.org/jira/browse/DERBY-3306
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
Fix For: 10.4.0.0
Attachments: derby-3306-1a-create_db_by_default.diff,
derby-3306-1b-create_db_by_default_and_test_fixes.diff,
derby-3306-1b-create_db_by_default_and_test_fixes.stat,
derby-3306-1c-create_db_by_default_and_test_fixes.diff,
derby-3306-errors_with_patch_1a.txt
jdbc4.StatementEventsTest cannot be run individually in a clean environment
because the test database is not created if it does not exist.
Excerpt of output from JUnit:
32)
testErrorEventOnClosedConnection_pooled_prepared(org.apache.derbyTesting.functionTests.tests.jdbc4.StatementEventsTest)java.sql.SQLNonTransientConnectionException:
The connection was refused because the database wombat was not found.
at
org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
at
org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362)
at
org.apache.derby.client.ClientPooledConnection.init(ClientPooledConnection.java:89)
at
org.apache.derby.client.ClientPooledConnection40.init(ClientPooledConnection40.java:47)
at
org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newClientPooledConnection(ClientJDBCObjectFactoryImpl40.java:73)
at
org.apache.derby.jdbc.ClientConnectionPoolDataSource.getPooledConnectionX(ClientConnectionPoolDataSource.java:100)
at
org.apache.derby.jdbc.ClientConnectionPoolDataSource.getPooledConnection(ClientConnectionPoolDataSource.java:63)
at
org.apache.derbyTesting.functionTests.tests.jdbc4.StatementEventsTest.setUp(StatementEventsTest.java:125)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
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: org.apache.derby.client.am.DisconnectException: The connection was
refused because the database wombat was not found.
at
org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java:1022)
at
org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:448)
at
org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:306)
at
org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:133)
at
org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:887)
at
org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:799)
at
org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java:620)
at
org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:435)
at
org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:296)
at
org.apache.derby.client.net.NetConnection.init(NetConnection.java:280)
at
org.apache.derby.client.net.NetConnection40.init(NetConnection40.java:125)
at
[jira] Commented: (DERBY-3306) jdbc4.StatementEventsTest cannot be run individually in a clean environment
[ https://issues.apache.org/jira/browse/DERBY-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570607#action_12570607 ] Kristian Waagan commented on DERBY-3306: Regarding Mikes comment on the 14th of February: The failures are only indirectly JVM specific, as you will only see the failures when the connections are obtained through a DataSource. Since the J2ME platform doesn't support DriverManager, a DataSource is used. jdbc4.StatementEventsTest cannot be run individually in a clean environment --- Key: DERBY-3306 URL: https://issues.apache.org/jira/browse/DERBY-3306 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3306-1a-create_db_by_default.diff, derby-3306-1b-create_db_by_default_and_test_fixes.diff, derby-3306-1b-create_db_by_default_and_test_fixes.stat, derby-3306-1c-create_db_by_default_and_test_fixes.diff, derby-3306-errors_with_patch_1a.txt jdbc4.StatementEventsTest cannot be run individually in a clean environment because the test database is not created if it does not exist. Excerpt of output from JUnit: 32) testErrorEventOnClosedConnection_pooled_prepared(org.apache.derbyTesting.functionTests.tests.jdbc4.StatementEventsTest)java.sql.SQLNonTransientConnectionException: The connection was refused because the database wombat was not found. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) at org.apache.derby.client.ClientPooledConnection.init(ClientPooledConnection.java:89) at org.apache.derby.client.ClientPooledConnection40.init(ClientPooledConnection40.java:47) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newClientPooledConnection(ClientJDBCObjectFactoryImpl40.java:73) at org.apache.derby.jdbc.ClientConnectionPoolDataSource.getPooledConnectionX(ClientConnectionPoolDataSource.java:100) at org.apache.derby.jdbc.ClientConnectionPoolDataSource.getPooledConnection(ClientConnectionPoolDataSource.java:63) at org.apache.derbyTesting.functionTests.tests.jdbc4.StatementEventsTest.setUp(StatementEventsTest.java:125) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96) 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: org.apache.derby.client.am.DisconnectException: The connection was refused because the database wombat was not found. at org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java:1022) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:448) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:306) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:133) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:887) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:799) at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java:620) at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:435) at org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:296) at org.apache.derby.client.net.NetConnection.init(NetConnection.java:280) at org.apache.derby.client.net.NetConnection40.init(NetConnection40.java:125) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(ClientJDBCObjectFactoryImpl40.java:260) at org.apache.derby.client.ClientPooledConnection.init(ClientPooledConnection.java:75) ... 29 more FAILURES!!! Tests run: 32, Failures: 0, Errors: 32 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3378) Derby's timer thread should have a name that identifies it as belong to a derby instance
[ https://issues.apache.org/jira/browse/DERBY-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Serge Tsv updated DERBY-3378: - Attachment: DERBY-3378.diff The patch adds a name derby.timer to a Derby singleton timer thread created by SingletonTimerFactory. The derby.timer thread name is passed to a Timer constructor as an additional parameter, as it has been proposed. Derby's timer thread should have a name that identifies it as belong to a derby instance Key: DERBY-3378 URL: https://issues.apache.org/jira/browse/DERBY-3378 Project: Derby Issue Type: Improvement Components: Newcomer, Services Reporter: Daniel John Debrunner Priority: Minor Attachments: DERBY-3378.diff Looking at the threads with jconsole when derby is running shows derby's timer thread as Timer-0. All other derby threads are given a name starting with 'derby.', would be useful if the same was true for the timer thread. In SingletonTimerFactory just use the Timer constructor that takes a name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3306) jdbc4.StatementEventsTest cannot be run individually in a clean environment
[ https://issues.apache.org/jira/browse/DERBY-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3306: --- Attachment: derby-3306-2a-backout_and_alternative_fix.diff 'derby-3306-2a-backout_and_alternative_fix.diff' backs out the 1c patch (unclean merge, needed trivial tweaking) and implements a simpler alternative fix. Patch ready for review. jdbc4.StatementEventsTest cannot be run individually in a clean environment --- Key: DERBY-3306 URL: https://issues.apache.org/jira/browse/DERBY-3306 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3306-1a-create_db_by_default.diff, derby-3306-1b-create_db_by_default_and_test_fixes.diff, derby-3306-1b-create_db_by_default_and_test_fixes.stat, derby-3306-1c-create_db_by_default_and_test_fixes.diff, derby-3306-2a-backout_and_alternative_fix.diff, derby-3306-errors_with_patch_1a.txt jdbc4.StatementEventsTest cannot be run individually in a clean environment because the test database is not created if it does not exist. Excerpt of output from JUnit: 32) testErrorEventOnClosedConnection_pooled_prepared(org.apache.derbyTesting.functionTests.tests.jdbc4.StatementEventsTest)java.sql.SQLNonTransientConnectionException: The connection was refused because the database wombat was not found. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) at org.apache.derby.client.ClientPooledConnection.init(ClientPooledConnection.java:89) at org.apache.derby.client.ClientPooledConnection40.init(ClientPooledConnection40.java:47) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newClientPooledConnection(ClientJDBCObjectFactoryImpl40.java:73) at org.apache.derby.jdbc.ClientConnectionPoolDataSource.getPooledConnectionX(ClientConnectionPoolDataSource.java:100) at org.apache.derby.jdbc.ClientConnectionPoolDataSource.getPooledConnection(ClientConnectionPoolDataSource.java:63) at org.apache.derbyTesting.functionTests.tests.jdbc4.StatementEventsTest.setUp(StatementEventsTest.java:125) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96) 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: org.apache.derby.client.am.DisconnectException: The connection was refused because the database wombat was not found. at org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java:1022) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:448) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:306) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:133) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:887) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:799) at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java:620) at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:435) at org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:296) at org.apache.derby.client.net.NetConnection.init(NetConnection.java:280) at org.apache.derby.client.net.NetConnection40.init(NetConnection40.java:125) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(ClientJDBCObjectFactoryImpl40.java:260) at org.apache.derby.client.ClientPooledConnection.init(ClientPooledConnection.java:75) ... 29 more FAILURES!!! Tests run: 32, Failures: 0, Errors: 32 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3306) jdbc4.StatementEventsTest cannot be run individually in a clean environment
[ https://issues.apache.org/jira/browse/DERBY-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3306: --- Derby Info: [Patch Available] jdbc4.StatementEventsTest cannot be run individually in a clean environment --- Key: DERBY-3306 URL: https://issues.apache.org/jira/browse/DERBY-3306 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3306-1a-create_db_by_default.diff, derby-3306-1b-create_db_by_default_and_test_fixes.diff, derby-3306-1b-create_db_by_default_and_test_fixes.stat, derby-3306-1c-create_db_by_default_and_test_fixes.diff, derby-3306-2a-backout_and_alternative_fix.diff, derby-3306-errors_with_patch_1a.txt jdbc4.StatementEventsTest cannot be run individually in a clean environment because the test database is not created if it does not exist. Excerpt of output from JUnit: 32) testErrorEventOnClosedConnection_pooled_prepared(org.apache.derbyTesting.functionTests.tests.jdbc4.StatementEventsTest)java.sql.SQLNonTransientConnectionException: The connection was refused because the database wombat was not found. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362) at org.apache.derby.client.ClientPooledConnection.init(ClientPooledConnection.java:89) at org.apache.derby.client.ClientPooledConnection40.init(ClientPooledConnection40.java:47) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newClientPooledConnection(ClientJDBCObjectFactoryImpl40.java:73) at org.apache.derby.jdbc.ClientConnectionPoolDataSource.getPooledConnectionX(ClientConnectionPoolDataSource.java:100) at org.apache.derby.jdbc.ClientConnectionPoolDataSource.getPooledConnection(ClientConnectionPoolDataSource.java:63) at org.apache.derbyTesting.functionTests.tests.jdbc4.StatementEventsTest.setUp(StatementEventsTest.java:125) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96) 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: org.apache.derby.client.am.DisconnectException: The connection was refused because the database wombat was not found. at org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java:1022) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:448) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:306) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:133) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:887) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:799) at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java:620) at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:435) at org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:296) at org.apache.derby.client.net.NetConnection.init(NetConnection.java:280) at org.apache.derby.client.net.NetConnection40.init(NetConnection40.java:125) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(ClientJDBCObjectFactoryImpl40.java:260) at org.apache.derby.client.ClientPooledConnection.init(ClientPooledConnection.java:75) ... 29 more FAILURES!!! Tests run: 32, Failures: 0, Errors: 32 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2667) Create more robust junit TestRunner for running derby tests
[ https://issues.apache.org/jira/browse/DERBY-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570621#action_12570621 ] Knut Anders Hatlen commented on DERBY-2667: --- Is the check for (running != null) necessary? I don't see how it could be null. First two lines use spaces for indentation, the rest use tabs. Would be good to use one of them consistently. Since the surrounding code uses spaces, I think that's the best option. Should the call to getFailureFolder() also be moved inside the if? Then we don't create a folder unless we have to. Would it make sense to put a try/finally block inside the catch block and re-throw the exception in the finally clause? This way we make sure that the original exception is not hidden if saving derby.log fails for some reason. Create more robust junit TestRunner for running derby tests Key: DERBY-2667 URL: https://issues.apache.org/jira/browse/DERBY-2667 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.3.1.4 Reporter: Kathey Marsden Priority: Minor Attachments: DERBY-2667_diff_02_06.txt, DERBY-2667_diff_02_15.txt, DERBY-2667_diff_2_19.txt, DERBY-2667_stat_02_06.txt, DERBY-2667_stat_02_15.txt, DERBY-2667_stat_02_19.txt, JUnitMethodTrace.diff.txt, JUnitMethodTrace_Extra.diff.txt, MemRunner.java, TimeRunner.java Provide a more full featured TestRunner for Derby testing. junit.textui.TestRunner is not very robust. It does not for example print the tests as they run or print chained exceptions, create separate files for the full report and just failures. It would be great to have a standardized TestRunner that everyone uses. Perhaps someone already has one that they would like to contribute as a starter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3412) junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedErro
[ https://issues.apache.org/jira/browse/DERBY-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570611#action_12570611 ] Kristian Waagan commented on DERBY-3412: I have decided to go for options a and c above. See DERBY-3306 for comments / explanation. When the new patch is committed, I expect this issue will be fixed as well. junit regression test failure on j2me in testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError -- Key: DERBY-3412 URL: https://issues.apache.org/jira/browse/DERBY-3412 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: Java Version:J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: c:\jartest\weme6.1 Java classpath: c:/jartest/classes/derby.jar;c:/jartest/classes/derbyLocale_zh_TW.jar;c:/jartest/classes/derbyLocale_zh_CN.jar;c:/jartest/classes/derbyLocale_ru.jar;c:/jartest/classes/derbyLocale_pt_BR.jar;c:/jartest/classes/derbyLocale_pl.jar;c:/jartest/classes/derbyLocale_ko_KR.jar;c:/jartest/classes/derbyLocale_ja_JP.jar;c:/jartest/classes/derbyLocale_it.jar;c:/jartest/classes/derbyLocale_hu.jar;c:/jartest/classes/derbyLocale_fr.jar;c:/jartest/classes/derbyLocale_es.jar;c:/jartest/classes/derbyLocale_de_DE.jar;c:/jartest/classes/derbyLocale_cs.jar;c:/jartest/tools/java/junit.jar;c:/jartest/classes/derbytools.jar;c:/jartest/classes/derbyrun.jar;c:/jartest/classes/derbyTesting.jar;c:/jartest/classes/functionTests.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 2 Java user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\jartest\JarResults.2008-02-11\weme6.1_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 Reporter: Mike Matrigali Attachments: derby-3412-option_b.diff 5 new failures as of 2/11/08 in the ScrollCursors2Test, only seen in j2me test: 1) testForwardOnlyNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testForwardOnlyNegative(ScrollCursors2Test.java:95) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testForwardOnlyPositive(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testForwardOnlyPositive(ScrollCursors2Test.java:263) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 3) testScrollInsensitivePositive(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testScrollInsensitivePositive(ScrollCursors2Test.java:352) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 4) testScrollInsensitiveNegative(org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.ScrollCursors2Test.testScrollInsensitiveNegative(ScrollCursors2Test.java:505)
[jira] Commented: (DERBY-3378) Derby's timer thread should have a name that identifies it as belong to a derby instance
[ https://issues.apache.org/jira/browse/DERBY-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570624#action_12570624 ] Serge Tsv commented on DERBY-3378: -- Hello, Kristian. Have noticed your comment right after submitting the patch. I've just sent a developer access request to derby-dev@db.apache.org, so I'll try to assign the issue to myself right after I get the access rights. Thanks! :-) Derby's timer thread should have a name that identifies it as belong to a derby instance Key: DERBY-3378 URL: https://issues.apache.org/jira/browse/DERBY-3378 Project: Derby Issue Type: Improvement Components: Newcomer, Services Reporter: Daniel John Debrunner Priority: Minor Attachments: DERBY-3378.diff Looking at the threads with jconsole when derby is running shows derby's timer thread as Timer-0. All other derby threads are given a name starting with 'derby.', would be useful if the same was true for the timer thread. In SingletonTimerFactory just use the Timer constructor that takes a name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3422) Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets()
[ https://issues.apache.org/jira/browse/DERBY-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen resolved DERBY-3422. --- Resolution: Fixed Fix Version/s: 10.4.0.0 Derby Info: (was: [Patch Available]) Committed revision 629395. Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets() Key: DERBY-3422 URL: https://issues.apache.org/jira/browse/DERBY-3422 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.4.0.0 Attachments: d3422.diff, d3422.stat, test.diff DatabaseMetaData.autoCommitFailureClosesAllResultSets() returns false both on the client and on embedded. However, the embedded driver does in fact close all open result sets when an error occurs in auto-commit mode. There is a test case in jdbc4.TestDbMetaData to test this (testAutoCommitFailure), but it only uses ResultSet.isClosed() to check whether or not the result set is closed after the failure. Because of DERBY-3404, isClosed() returns false for the result sets that have been closed because of the failure, so the test doesn't reveal the bug. If the test is changed to invoke methods on the result set (e.g. next()) instead of calling isClosed(), we'll see that the result set is in fact closed and get an SQLException with SQL state XCL16. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3436) Embedded closes all open ResultSets on failure in auto-commit mode, whereas client keeps them open
Embedded closes all open ResultSets on failure in auto-commit mode, whereas client keeps them open -- Key: DERBY-3436 URL: https://issues.apache.org/jira/browse/DERBY-3436 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Priority: Minor When an error happens in auto-commit mode, the embedded driver will close all open ResultSets (including holdable ones) in that transaction. The client driver will keep the ResultSets open. The embedded driver and the client driver should have the same behaviour. The test case testAutoCommitFailure() in jdbc4/TestDbMetaData contains code that shows the difference between client and embedded. DatabaseMetaData.autoCommitFailureClosesAllResultSets() currently returns true on the embedded driver (after DERBY-3422) and false on the client driver to account for this difference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3422) Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets()
[ https://issues.apache.org/jira/browse/DERBY-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-3422. - DERBY-3436 is logged to track the difference between embedded and client. Embedded returns wrong value for DatabaseMetaData.autoCommitFailureClosesAllResultSets() Key: DERBY-3422 URL: https://issues.apache.org/jira/browse/DERBY-3422 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.4.0.0 Attachments: d3422.diff, d3422.stat, test.diff DatabaseMetaData.autoCommitFailureClosesAllResultSets() returns false both on the client and on embedded. However, the embedded driver does in fact close all open result sets when an error occurs in auto-commit mode. There is a test case in jdbc4.TestDbMetaData to test this (testAutoCommitFailure), but it only uses ResultSet.isClosed() to check whether or not the result set is closed after the failure. Because of DERBY-3404, isClosed() returns false for the result sets that have been closed because of the failure, so the test doesn't reveal the bug. If the test is changed to invoke methods on the result set (e.g. next()) instead of calling isClosed(), we'll see that the result set is in fact closed and get an SQLException with SQL state XCL16. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen reassigned DERBY-3435: Assignee: John H. Embretsen Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3169) Add documentation for replication
[ https://issues.apache.org/jira/browse/DERBY-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570663#action_12570663 ] Jørgen Løland commented on DERBY-3169: -- I did some experiments with replication on a Derby server with the security manager enabled. The security policy file has to be modified to allow the master-slave network connection. I think this needs to be documented as well: Permission needed in the master policy file (for derby.jar): permission java.net.SocketPermission slaveHost:slavePort, connect,resolve; Permission needed in the slave policy file (for derby.jar): permission java.net.SocketPermission slaveHost, accept,resolve; (replace slaveHost and slavePort with what is specified in the slaveHost and slavePort options.) Add documentation for replication - Key: DERBY-3169 URL: https://issues.apache.org/jira/browse/DERBY-3169 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Kim Haase Attachments: DERBY-3169.diff, DERBY-3169.stat, DERBY-3169.zip -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3192) Cache session data in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3192: -- Attachment: derby-3192-mark2.v5.diff Yet another version, hopefully without trailing white space this time... Cache session data in the client driver --- Key: DERBY-3192 URL: https://issues.apache.org/jira/browse/DERBY-3192 Project: Derby Issue Type: Improvement Components: JDBC, Network Client, Network Server, Performance, SQL Affects Versions: 10.3.1.4 Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Attachments: derby-3192-mark2.v1.diff, derby-3192-mark2.v2.diff, derby-3192-mark2.v3.diff, derby-3192-mark2.v4.diff, derby-3192-mark2.v5.diff, derby-3192-test.fup1.diff, derby-3192-test.fup2.diff, derby-3192-test.v1.diff, derby-3192-test.v1.stat, derby-3192.prelim1.diff The reason for doing this is to avoid a rather substantial performance hit observed when the client driver is used together with an appserver that uses connection pooling. There are two problems: 1) The connection pool will compare the isolation level it has stored for the connection with the value returned from Connection.getTransactionIsolation() each and every time someone requests a new connection from the pool. 2) The users of the connection pool (ab)use it to avoid having to keep track of their current connection. So each time a query needs to be executed a call to the connection pool's getConnection() method is made. Getting a connection from the connection pool like this also means that a new PreparedStatement must be prepared each time. The net result is that each query results in the following sequence: getConnection() getTransactionIsolation() -- roundtrip + lookup in server's statement cache prepareStatment() -- roundtrip + lookup in server's statement cache executeQuery()-- roundtrip Arguably this is a user error but when suggesting this I'm kindly informed that this works just fine with other datbases (such as PostgreSQL and ORACLE). The reason why it works is that these databases do statement caching in the driver. I've tried to implement a very (too) simple statement cache in Derby's client driver and to re-enable caching of the isolation level (see https://issues.apache.org/jira/browse/DERBY-1148). With these changes I observe a marked performance improvement when running with appserver load. A proper statment cache cannot be implemented without knowing what the current schema is. If the current schema has changed since the statement was prepared, it is no longer valid and must be evicted from the cache. The problem with caching both the isolation level and the current schema in the driver is that both can change on the server without the client detecting it (through SQL and XA and possibly stored procedures). I think this problem can be overcome if we piggy-back the information we would like to cache on messages going back to the client. This can be done by utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume 3, page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD in the reply, I think it would be possible to cache additional session information when this becomes relevant. It would also be possible to use EXCSQLSET to batch session state changes going from the client to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3437) Give all replication threads meaningfull names
Give all replication threads meaningfull names -- Key: DERBY-3437 URL: https://issues.apache.org/jira/browse/DERBY-3437 Project: Derby Issue Type: Improvement Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Priority: Minor Some threads are created for replication purposes: * The log shipper thread on the master * The database boot thread on the slave * The log receiver thread on the slave These threads should be given names to simplify debugging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3437) Give all replication threads meaningfull names
[ https://issues.apache.org/jira/browse/DERBY-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3437: - Component/s: Newcomer Give all replication threads meaningfull names -- Key: DERBY-3437 URL: https://issues.apache.org/jira/browse/DERBY-3437 Project: Derby Issue Type: Improvement Components: Newcomer, Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Priority: Minor Some threads are created for replication purposes: * The log shipper thread on the master * The database boot thread on the slave * The log receiver thread on the slave These threads should be given names to simplify debugging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3404: -- Derby Info: [Patch Available, Regression] (was: [Regression]) Now DERBY-3422 has been fixed, and suites.All and derbyall run cleanly with the d3404-v1 patch. EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java, d3404-v1.diff, d3404-v1.stat The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2871) XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO.
[ https://issues.apache.org/jira/browse/DERBY-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570673#action_12570673 ] Knut Anders Hatlen commented on DERBY-2871: --- It seems like Dan's comment from 05/Feb/08 12:19 PM hasn't been addressed. ResourceAdapterImpl.cancelXATransaction() calls findConnection() twice. Is that intentional? Is the comment about synchronization in ResourceAdapter.cancelXATransaction() still valid in the latest patch? Could you comment on why you call DatabasePropertyTestSetup.setLockTimeouts() in XATransactionTest.suite()? As far as I can see, the timeout values specified (20 sec deadlock, 60 sec wait) are the same as the default values, so it doesn't change anything. Tiny nit: assertTrue(xaConn[i] != null) could be replaced with assertNotNull(xaConn[i]). XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. -- Key: DERBY-2871 URL: https://issues.apache.org/jira/browse/DERBY-2871 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4 Environment: OS: HP-UX v1.11 i JDK: HP 1.5.0.03 Reporter: Henri van de Scheur Assignee: Julius Stroffek Priority: Minor Attachments: d2871-test.diff, d2871-test.stat, d2871.diff, d2871.diff, d2871.diff, d2871.diff, d2871.stat, d2871.stat, d2871.stat, d2871.stat, DERBY-2871_020108.diff Method: org.apache.derbyTesting.functionTests.tests.jdbcapi.XATransactionTest Signature: %XAER_PROTO : Error executing a XAResource.commit(), server returned XAER_PROTO% Also see: http://dbtg.thresher.com/derby/test/10.3.1.0_RC/jvm1.5/testing/testlog/hpux/548006-suitesAll_diff.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3439) Support getGeneratedKeys() for multirow inserts
Support getGeneratedKeys() for multirow inserts Key: DERBY-3439 URL: https://issues.apache.org/jira/browse/DERBY-3439 Project: Derby Issue Type: Improvement Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kathey Marsden Priority: Minor Our getGeneratedKeys() implementation currently does not support retrieving keys for multirow inserts or an insert statement with full select. This is because we use the IDENTITY_VAL_LOCAL function to retrieve values. I am not sure how to implement this, especially for client, but it would be nice to have. We document that getGeneratedKeys uses IDENTITY_VAL_LOCAL and that IDENTITY_VAL_LOCAL is not affected by a multiple row insert, so filing this as an improvement and not a bug. After this is changed I think we could change our DatabaseMetaData.supportsGetGeneratedKeys to be true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3437) Give all replication threads meaningfull names
[ https://issues.apache.org/jira/browse/DERBY-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3437: - Component/s: Replication Give all replication threads meaningfull names -- Key: DERBY-3437 URL: https://issues.apache.org/jira/browse/DERBY-3437 Project: Derby Issue Type: Improvement Components: Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Priority: Minor Some threads are created for replication purposes: * The log shipper thread on the master * The database boot thread on the slave * The log receiver thread on the slave These threads should be given names to simplify debugging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3437) Give all replication threads meaningfull names
[ https://issues.apache.org/jira/browse/DERBY-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3437: - Description: Some threads are created for replication purposes: * The log shipper thread on the master (o.a.d.i.services.master.MasterController) * The database boot thread on the slave (o.a.d.i.db.SlaveDatabase) * The log receiver thread on the slave (o.a.d.i.services.slave.SlaveController) These threads should be given names to simplify debugging. was: Some threads are created for replication purposes: * The log shipper thread on the master * The database boot thread on the slave * The log receiver thread on the slave These threads should be given names to simplify debugging. Give all replication threads meaningfull names -- Key: DERBY-3437 URL: https://issues.apache.org/jira/browse/DERBY-3437 Project: Derby Issue Type: Improvement Components: Newcomer, Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Priority: Minor Some threads are created for replication purposes: * The log shipper thread on the master (o.a.d.i.services.master.MasterController) * The database boot thread on the slave (o.a.d.i.db.SlaveDatabase) * The log receiver thread on the slave (o.a.d.i.services.slave.SlaveController) These threads should be given names to simplify debugging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3438) Allow SQL query text to be null in StatementKey
Allow SQL query text to be null in StatementKey --- Key: DERBY-3438 URL: https://issues.apache.org/jira/browse/DERBY-3438 Project: Derby Issue Type: Bug Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Because the SQL isn't checked before the cache is queried, StatementKey should allow the SQL query text to be null. This simplifies handling this exceptional situations, hopefully without complications. What will happen is, the cache is queried, null is returned (no match) and then prepare will fail in the driver. Because the statement is never prepared, it will never be inserted into the cached, nor (incorrectly) fetched from the cache in the first step. Of course, one could also explicitly check for null in either the Logical(Prepared|Callable)Statement[40], StatementKeyFactory or StatementCacheInteractor. However, the proposed change is small, isolated to one class and makes the exceptional case be handled by the normal code path. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570696#action_12570696 ] Kathey Marsden commented on DERBY-3310: --- I was hoping to pick up this issue, but must admit I am quite stuck. I am really not sure at the time of the sort whether both template and row data should be SQLInteger or SQLLongInt. If someone could explain which and why, I might better understand my destination and be able to make some progress on the issue. Before the DERBY-2775 both were SQLInteger but I don't know that that was correct. It may have been wrong for both values. Any help or hints would be greatly appreciated. Thanks Kathey ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions -- Key: DERBY-3310 URL: https://issues.apache.org/jira/browse/DERBY-3310 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: cast-repro.sql The following code CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; gives ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3438) Allow SQL query text to be null in StatementKey
[ https://issues.apache.org/jira/browse/DERBY-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3438: --- Attachment: derby-3438-1a-allow_sql_null.diff 'derby-3438-1a-allow_sql_null.diff' makes StatementKey capable of handling a null SQL query text. Patch ready for review. Allow SQL query text to be null in StatementKey --- Key: DERBY-3438 URL: https://issues.apache.org/jira/browse/DERBY-3438 Project: Derby Issue Type: Bug Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3438-1a-allow_sql_null.diff Because the SQL isn't checked before the cache is queried, StatementKey should allow the SQL query text to be null. This simplifies handling this exceptional situations, hopefully without complications. What will happen is, the cache is queried, null is returned (no match) and then prepare will fail in the driver. Because the statement is never prepared, it will never be inserted into the cached, nor (incorrectly) fetched from the cache in the first step. Of course, one could also explicitly check for null in either the Logical(Prepared|Callable)Statement[40], StatementKeyFactory or StatementCacheInteractor. However, the proposed change is small, isolated to one class and makes the exceptional case be handled by the normal code path. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3375) Localize new error messages added in 10.3
[ https://issues.apache.org/jira/browse/DERBY-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3375: -- Attachment: derby-3375.v2.diff New patch which fixes 42818 and the errors in the German translation. Also capitalizes the SQL keywords for 42818 in messages.xml Localize new error messages added in 10.3 - Key: DERBY-3375 URL: https://issues.apache.org/jira/browse/DERBY-3375 Project: Derby Issue Type: Improvement Components: Localization Affects Versions: 10.3.2.1 Reporter: Dyre Tjeldvoll Priority: Minor Fix For: 10.4.0.0 Attachments: CheckMessages.java, checkMessages.sql, derby-3375.diff, derby-3375.v2.diff, drda_messages.zip, engine_messages.zip New error messages added in 10.3 have not been localized. Should translate these into as many languages as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Using EMMA for codecoverage analysis
I got suites.All to run with EMMA, but I had to add 7-8 lines to derby_tests.policy and modify a couple of tests before it ran cleanly. I think it would be good if this worked without editing the source, so I'll make a Jira and upload a patch with these changes. I'm thinking about adding some ant tasks for instrumenting classes/jars and running the junit-tests with EMMA, making it easier to do this. Vemund Vemund Ostgaard wrote: Hi, I've been trying to run the Derby testsuites with EMMA to measure codecoverage, and after troubling a little I have a few questions and comments. I hit some problems both with the old test harness and the new junit testsuite in relation to the securitymanager. I haven't analyzed it fully, but both seemed to be caused by the emma codebase wanting to access files on the disk and/or system properties. I also stumbled on a test for derbyrun.jar in the old harness. It forks a java process running derbyrun.jar with the -jar option, so no matter what you set your CLASSPATH env to you still only have derbyrun.jar in the classpath. This test then failed when running with instrumented jarfiles as it couldn't find the classes it needed from emma.jar. There might be other tests with similar problems, this was just the first one I stumbled on when running the derbytools subsuite. Ideally I think the tests should be run in their normal configuration (with security manager if that is the default), also when running codecoverage measurements. It would also be good if it was possible to run all the tests. My immediate thought was that this would require modifications to policy files and possibly individual tests like the test for derbyrun.jar, but there may be better ways to get around these issues that I haven't thought about. I know that EMMA is being used by others in the community, how did you get around these problems? Is there in principle anything wrong with making changes to policy files and/or tests to make it easier to run codecoverage measurements with the EMMA tool? Vemund
[jira] Commented: (DERBY-3375) Localize new error messages added in 10.3
[
https://issues.apache.org/jira/browse/DERBY-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570700#action_12570700
]
Rick Hillegas commented on DERBY-3375:
--
I'm skeptical that we will find an off-the-shelf xml dialect which we can just
use as-is. The existing grammar in messages.dtd was designed for a very
specific problem, viz., making it easy to generate the error summary in our
user guides. In particular, I don't see the arg tags modelled in either of
the alternate grammars which have been proposed. I think we might be able to
use the LDIFF grammar if we rewrote the message text itself, replacing the {n}
argument placeholders with other markup.
Localize new error messages added in 10.3
-
Key: DERBY-3375
URL: https://issues.apache.org/jira/browse/DERBY-3375
Project: Derby
Issue Type: Improvement
Components: Localization
Affects Versions: 10.3.2.1
Reporter: Dyre Tjeldvoll
Priority: Minor
Fix For: 10.4.0.0
Attachments: CheckMessages.java, checkMessages.sql, derby-3375.diff,
drda_messages.zip, engine_messages.zip
New error messages added in 10.3 have not been localized. Should translate
these into as many languages as possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570713#action_12570713 ] Bryan Pendleton commented on DERBY-3310: Hi Kathey, Beware, you're getting a WAG here. :) But my opinion is that SQLInteger is the correct datatype, and SQLLongInt is incorrect. I'm guessing that the overall query tree looks something like: - InsertNode - NormalizeResultSetNode - SelectNode / ProjectRestrictNode It seems to me that the data being sorted is the SELECT data, and that data uses the constant 2, and so that data should have been sorted as simple integers. Then, the NormalizeResultSetNode should have generated a CAST operation to convert the integer to a biginit when the data is retrieved from the sorter. And, the VirtualColumnNodes used by the InsertNode should have pointed to the values returned by the NormalizeResultSetNode, so it seems correct that the VCN instance that the InsertNode references should be working with a SQLLongInt. So I'd suggest investigating the NormalizeResultSetNode, and whether it is generating the proper buffering CAST operations. ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions -- Key: DERBY-3310 URL: https://issues.apache.org/jira/browse/DERBY-3310 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: cast-repro.sql The following code CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; gives ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2653: -- Attachment: derby-2653_doc_diff.txt crefjavstateautogen.html Attached is the documentation change for this issue. I just used Dan's wording for the change. Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: crefjavstateautogen.html, derby-2653_columnIndexes_diff.txt, derby-2653_columnNames2_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_doc_diff.txt, derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen updated DERBY-3435: - Attachment: d3435_v01.stat d3435_v01.diff The patch d3435_v01.diff defines and implements an MBean for monitoring and (future work) management of the Network Server. Although the MBean works, it is currently limited to exposing read-only attributes only (i.e. no management functionality), in addition to the ping() operation, so I consider this just to be a start of what could eventually become a very useful bean for server administrators. Patch contents: A java/engine/org/apache/derby/mbeans/drda New package for Network Server mbeans (included in derbynet.jar) A java/engine/org/apache/derby/mbeans/drda/NetworkServerMBean.java The defining interface of the MBean. The following read-only attributes are available: ([Attribute]- [associated server property]) DrdaHost- derby.drda.host DrdaKeepAlive - derby.drda.keepAlive DrdaMaxThreads - derby.drda.maxThreads DrdaPortNumber - derby.drda.portNumber DrdaSecurityMechanism - derby.drda.securityMechanism DrdaSslMode - derby.drda.sslMode DrdaStreamOutBufferSize - derby.drda.streamOutBufferSize DrdaTimeSlice - derby.drda.timeSlice DrdaTraceAll- derby.drda.traceAll DrdaTraceDirectory - derby.drda.traceDirectory The ping() operation requires the permission permission java.net.SocketPermission *, connect,resolve; (* may be replaced, depending on the -h option of the server) granted to derbynet.jar in order to work, due to the way the network server is currently implemented. A java/drda/org/apache/derby/impl/drda/NetworkServerMBeanImpl.java The implementation of NetworkServerMBean. Instruments NetworkServerControlImpl. M java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java - removes some unused imports - registers the MBean at server startup - unregisters the MBean at server shutdown - relaxes the modifier of the method getPropertyValues() from private to package-private in order to allow access to server settings from the MBean impl. without having to use a network connection. M tools/javadoc/publishedapi.ant Adds org.apache.derby.mbeans.drda to the publishedAPI javadocs. The patch includes some commented code copied from patch 9 of DERBY-1387, as a temporary reminder of the functionality initially proposed as part of that Jira issue. This code should eventually be removed and/or replaced by real code once the community agrees on and implements a security model for Derby's JMX functionality. Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen updated DERBY-3435: - Derby Info: [Patch Available] Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription
Filter: Derby: JIRA issues with patch available (20 issues)
Subscriber: derby-dev
Key Summary
DERBY-3435 Add an MBean for monitoring and managing the Network Server
https://issues.apache.org/jira/browse/DERBY-3435
DERBY-2653 Expose existing auto-generated key functionality through more JDBC
APIs in Derby Client.
https://issues.apache.org/jira/browse/DERBY-2653
DERBY-3404 EmbedResultSet.getString() returns wrong value after auto-commit
with CLOSE_CURSORS_AT_COMMIT
https://issues.apache.org/jira/browse/DERBY-3404
DERBY-2871 XATransactionTest gets XaException: Error executing a
XAResource.commit(), server returned XAER_PROTO.
https://issues.apache.org/jira/browse/DERBY-2871
DERBY-3306 jdbc4.StatementEventsTest cannot be run individually in a clean
environment
https://issues.apache.org/jira/browse/DERBY-3306
DERBY-3327 SQL roles: Implement authorization stack (and SQL session context
to hold it)
https://issues.apache.org/jira/browse/DERBY-3327
DERBY-3299 Uniqueness violation error (23505) occurs after dropping a PK
constraint if there exists a foreign key on the same columns.
https://issues.apache.org/jira/browse/DERBY-3299
DERBY-3382 Replication: Slave must inform master if DBs are out of sync.
https://issues.apache.org/jira/browse/DERBY-3382
DERBY-3073 SQL roles: add parser support
https://issues.apache.org/jira/browse/DERBY-3073
DERBY-3409 Remove JDBC 2.0-specific topics from Reference Manual and merge
implementation notes as needed
https://issues.apache.org/jira/browse/DERBY-3409
DERBY-3001 SYSTABLES documentation for TABLETYPE should include 'A' (Synonym)
https://issues.apache.org/jira/browse/DERBY-3001
DERBY-3326 Introduce a caching logical connection and logical prepared
statement in the client driver
https://issues.apache.org/jira/browse/DERBY-3326
DERBY-3329 Enable statement pooling in the client JDBC driver
https://issues.apache.org/jira/browse/DERBY-3329
DERBY-3328 Extend client JDBC object factory with methods to create objects
required for statement pooling
https://issues.apache.org/jira/browse/DERBY-3328
DERBY-3379 No Current connection on PooledConnection.getConnection() if
pooled connection is reused during connectionClosed processing
https://issues.apache.org/jira/browse/DERBY-3379
DERBY-3014 Make
SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.username') return NULL
instead of the hash value of the password
https://issues.apache.org/jira/browse/DERBY-3014
DERBY-3205 Replication: Add connection url command options for starting,
stopping slave and for failover
https://issues.apache.org/jira/browse/DERBY-3205
DERBY-2954 Add commands to NetworkServerControl for interacting with the
replication functionality
https://issues.apache.org/jira/browse/DERBY-2954
DERBY-2953 Dump the information about rollbacks of the global transaction
(introduced in DERBY-2220 and DERBY-2432) to derby.log
https://issues.apache.org/jira/browse/DERBY-2953
DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227
[jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570739#action_12570739 ] Daniel John Debrunner commented on DERBY-3435: -- I'll commit the patch in a few minutes with a minor change: changed the implementation of the bean to be package private. Minor comments. The ping command didn't work for me, maybe a permission issue. I also think the javadoc for the ping operation should clearly indicate it's a ping from the same machine as the network server. Exception handling for ping and the set methods (when added) may need changing. If the exception chain includes a class that is not present on the client. I hit this yesterday with a EmbedSQLException from a test MBean. Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570741#action_12570741 ] Daniel John Debrunner commented on DERBY-3435: -- I think the o.a.d.mbeans.drda package should be under java/drda, not java/engine. Any reason it was added to java/engine? Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3440) Run suites.All with statement pooling enabled and classify the problems occurring
Run suites.All with statement pooling enabled and classify the problems occurring - Key: DERBY-3440 URL: https://issues.apache.org/jira/browse/DERBY-3440 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 The patches for the statement pooling feature should soon make it possible to run suites.All with statement caching enabled. I will post a patch that modifies TestConfiguration to return connections from a ConnectionPoolDataSource. There will be a substantial numbers of errors, and I hope to classify these and maybe refer to JIRA issues that will make them go away. I have already tried this, and ended up at around 180 failures/errors, a report will follow soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - Daily 629162 - Sun DBTG
[Auto-generated mail] *Daily* 629162/2008-02-19 18:01:04 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0271271 073.91% derbyall 01022610226 0 1433.59% suitesAll linN+1 1271270 0 101.32% derbyall 01022610226 0 118.20% suitesAll sles 0271271 074.93% derbyall 01022610226 0 952.51% suitesAll sol 0271271 075.81% derbyall 01022610226 0 1505.53% suitesAll solN+1 0271271 096.75% derbyall 01022610226 0 200.81% suitesAll sparc 0271271 065.66% derbyall 01022610226 0 358.02% suitesAll vista 0271271 093.38% derbyall 091739173 066.58% suitesAll w2003 0271271 096.79% derbyall 091739173 0 132.82% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-629162.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/629162_bySig.html *Jvm: 1.5* lin 0272272 071.56% derbyall 085088508 0 890.30% suitesAll linN+1 0272272 097.77% derbyall 085088508 0 118.75% suitesAll sles 0272272 070.89% derbyall 085088508 0 575.07% suitesAll sol 0272272 079.68% derbyall 085088508 0 853.01% suitesAll solN+1 0272272 088.23% derbyall 085088508 0 798.46% suitesAll sparc 0272272 066.19% derbyall 085088508 0 696.41% suitesAll vista 0272272 071.56% derbyall 074557455 0 398.07% suitesAll w2003 0272272 074.29% derbyall F:0,E:274557453 0 260.99% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-629162.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/629162_bySig.html *Jvm: 1.4* lin 0269269 272.94% derbyall 084568456 0 799.83% suitesAll linN+1 0269269 298.10% derbyall 084568456 0 115.97% suitesAll sles 0269269 270.34% derbyall 084568456 0 531.43% suitesAll sol 0269269 277.37% derbyall 084568456 0 686.68% suitesAll solN+1 0269269 288.60% derbyall 084568456 0 757.39% suitesAll sparc 0269269 266.79% derbyall 084568456 0 705.54% suitesAll vista 0269269 271.23% derbyall 074037403 0 390.83% suitesAll w2003 0269269 275.03% derbyall 074077407 0 252.44% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-629162.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/629162_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/629162.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570746#action_12570746 ] Kim Haase commented on DERBY-2653: -- I've been following this issue to check on the possible impact on our JDBC documentation. If I've understood correctly (not a sure thing), the restriction that the user must specify an array of columnIndexes of length 1 would be a new one. Currently in http://db.apache.org/derby/docs/dev/ref/rrefjdbcjavasqlconnection30.html and http://db.apache.org/derby/docs/dev/ref/rrefjdbcjavasqlstatement30.html we say, for Connection.prepareStatement, Statement.execute, and Statement.executeUpdate, Every column index in the array must correlate to an auto-increment column within the target table of the INSERT. (And similarly for the methods that take a columnNames argument.) These statements imply that the array can have more than one element, so people might have to change existing code. The change in the documentation would be no problem, but the change in behavior (if real) might be a concern. What have I misunderstood? I think a table can have more than one autoincrement column, although that might be an unusual practice -- I don't see any restriction on this in the generated-column-spec topic (http://db.apache.org/derby/docs/dev/ref/rrefsqlj37836.html). I think the rrefjdbcjavasqlconnection30 and rrefjdbcjavasqlstatement30 topics would need to be changed along with crefjavstateautogen, although if I do all the work described in my DERBY-2388 proposal, the information in them would be folded into other topics. Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: crefjavstateautogen.html, derby-2653_columnIndexes_diff.txt, derby-2653_columnNames2_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_doc_diff.txt, derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570736#action_12570736 ] John H. Embretsen commented on DERBY-3435: -- Some suggestions for follow-up work: - add attributes for monitoring: - number of active sessions - total number of connections since server started (connNum) - replication status - size of queue of sessions waiting for a free thread (runQueue) - number of DRDAConnThreads waiting for something to do (freeThreads) (etc.) - add the rest of the NetworkServerControl functionality as operations and attribute setters (once we have adequate security mechanisms in place) Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570747#action_12570747 ] John H. Embretsen commented on DERBY-3435: -- Thanks for looking at the patch! Package placement: No reason, I just didn't think of placing it in java/drda, so feel free to move it. The Exception handling issue is known from DERBY-1387 - I did not provide a solution as part of this patch. Yes, the ping command requires a SocketPermission (as stated above). Even with the permission I'm not sure it will always work, since the NetworkServerControlImpl instance is not designed to ping itself. For example, if -h 0.0.0.0 is specified, it pings the host 0.0.0.0 instead of localhost (which works, but there may be other values of -h that won't, I guess). I agree with the javadoc suggestion and that the implementation class should be package private. Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570752#action_12570752 ] Kathey Marsden commented on DERBY-2653: --- In Derby currently you can only have one identity column per table, so the restriction to a one element array is not a new one. If a user specifies multiple columns, The difference is with the embedded driver will throw an exception that the column is not an identity column (X0X0E, X0X0F) and client will throw an exception that the array is too long (XOXOD). Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: crefjavstateautogen.html, derby-2653_columnIndexes_diff.txt, derby-2653_columnNames2_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_doc_diff.txt, derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570756#action_12570756 ] Daniel John Debrunner commented on DERBY-3435: -- Commited slightly modified version of v01 patch with revisions Revision: 629536 629537. Make the MBean implemetation package private Put o.a.d.mbeans.drda under java/drda Thanks John. Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570761#action_12570761 ] Bryan Pendleton commented on DERBY-3310: If the immediate child result of the InsertNode is a Normalize node, then I think the VCN instances for the columns in the InsertNode should have sourceResultSet pointing to a NormalizeResultSet, and sourceColumn pointing to a column in the NRS's ResultColumnList. In that case, it seems correct for that sourceColumn to be of type longint, because it represents the *result* of the normalization. That is: - the PRN should sort values with integer type, and feed them up to the NRSN - the NRS should invoke normalizeRow() to convert the int to a long - the InsertNode should pull long values from the NRS and insert them into the target table. However, it looks like maybe this was the intent of the design, but never completed? Here's a snip from a comment in NormalizeResultSet.java: * Normalize a row. For now, this means calling constructors through * the type services to normalize a type to itself. For example, * if you're putting a char(30) value into a char(15) column, it * calls a SQLChar constructor with the char(30) value, and the * constructor truncates the value and makes sure that no non-blank * characters are truncated. * * In the future, this mechanism will be extended to do type conversions * as well. I didn't implement type conversions yet because it looks * like a lot of work, and we needed char and varchar right away. As I said before, though, I'm just guessing. It would be good to have some more eyes and thoughts on how this is supposed to behave. ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions -- Key: DERBY-3310 URL: https://issues.apache.org/jira/browse/DERBY-3310 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: cast-repro.sql The following code CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; gives ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3326) Introduce a caching logical connection and logical prepared statement in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3326: --- Attachment: derby-3326-3c-new_classes.diff 'derby-3326-3c-new_classes.diff' contains some changes from the earlier versions, but the design is the same. I will commit this later today and use it as a baseline for further work, unless someone want time to review it before it goes in. I expect there will be some changes later, and please note that the patch in partial and does not enable any of the statement pooling code. Introduce a caching logical connection and logical prepared statement in the client driver -- Key: DERBY-3326 URL: https://issues.apache.org/jira/browse/DERBY-3326 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Fix For: 10.4.0.0 Attachments: derby-3326-1a_cpds_testing_preparation.diff, derby-3326-1a_cpds_testing_preparation.stat, derby-3326-1b_cpds_testing_preparation.diff, derby-3326-2a-method_rename.diff, derby-3326-3a-new_classes.diff, derby-3326-3a-new_classes.stat, derby-3326-3b-new_classes.diff, derby-3326-3b-new_classes.stat, derby-3326-3c-new_classes.diff A logical connection with statement caching capabilities is required to support JDBC prepared statement pooling. Further, a logical prepared statement object is also needed. The logical prepared statements will be generated by the logical connection's 'prepareStatement'-method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570758#action_12570758 ] Mamta A. Satoor commented on DERBY-3404: Thanks for working on this issue, Knut. While working on DERBY-3304, I have a need to know if JDBC Resultset is closed but not just by checking the EmbedResultset but also the underlying language resultset. I made a temporary code change in my codeline to do this check myself only in the area of the code where I need this check and my test case now works as expected. So, I would love to see a fix for DERBY-3404 checked in to make sure that it will make the test case run without my temporary change for language resultset close check. EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java, d3404-v1.diff, d3404-v1.stat The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[
https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570748#action_12570748
]
Kathey Marsden commented on DERBY-3310:
---
VirtualColumnNode has this comment
/* A VirtualColumnNode contains a pointer to the immediate child result
* that is materializing the virtual column and the ResultColumn
* that represents that materialization.
*/
private ResultSetNode sourceResultSet;
private ResultColumnsourceColumn;
The DERBY-2775 change overrode the setType from ValueNode:
public void setType(DataTypeDescriptor dataTypeServices) throws
StandardException
{
this.dataTypeServices = dataTypeServices;
}
with
public void setType(DataTypeDescriptor dtd) throws StandardException
{
sourceColumn.setType(dtd);
}
Doesn't this end up incorrectly end up affecting the child result, changing it
from
SQLInteger to SQLLongInt?
ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
--
Key: DERBY-3310
URL: https://issues.apache.org/jira/browse/DERBY-3310
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.4.0.0
Reporter: Dyre Tjeldvoll
Priority: Minor
Attachments: cast-repro.sql
The following code
CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT);
-- This triggers an ASSERT (because 2 is INTEGER and not BIGINT)
INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2
FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID;
gives
ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class
org.apache.derby.iapi.types.SQLInteger) expected to be the same as
col2.getClass() (class org.apache.derby.iapi.types.SQLLongint):
org.apache.derby.shared.common.sanity.AssertFailure'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3441) Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool --- Key: DERBY-3441 URL: https://issues.apache.org/jira/browse/DERBY-3441 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Fix For: 10.4.0.0 Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool. A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code. Correctness is of course the most important thing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3303) ArrayIndexOutOfBoundsException at MergeSort.compare
[
https://issues.apache.org/jira/browse/DERBY-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-3303:
---
Fix Version/s: 10.3.2.2
Ported the fix for this issue back to 10.3 by commiting d3303_10_3_merge.patch
with svn # 629535:
URL: http://svn.apache.org/viewvc?rev=629535view=rev
Donatas, if you have a moment can you check to see if your issue is fixed with
this commit, and report back?
ArrayIndexOutOfBoundsException at MergeSort.compare
---
Key: DERBY-3303
URL: https://issues.apache.org/jira/browse/DERBY-3303
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Environment: -- Java Information --
Java Version:1.6.0_03
Java Vendor: Sun Microsystems Inc.
Java home: D:\Programs\Java\jre1.6.0_03
Java classpath: derbytools.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: Donatas
Java user home: C:\Documents and Settings\Donatas
Java user dir: d:\java\derby-10.3.2.1\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[D:\java\derby-10.3.2.1\lib\derbytools.jar] 10.3.2.1 - (599110)
--
- Locale Information -
--
Reporter: Donatas Ciuksys
Assignee: A B
Priority: Blocker
Fix For: 10.3.2.2, 10.4.0.0
Attachments: d3303_10_3_merge.patch, d3303_v1.patch, d3303_v2.patch,
db.zip, ddl.sql
Derby throws ArrayIndexOutOfBoundsException when I try to execute SQL query
shown below.
This is a regression, since Derby 10.2.2.0 executes this query without
problems.
Attached are DDL statements to create DB tables, and database itself (with
data).
2008-01-08 12:32:34.461 GMT Thread[DRDAConnThread_5,6,derby.daemons] (XID =
1497), (SESSIONID = 0), (DATABASE = InventorizacijaDB), (DRDAID =
NF01.G46A-666250070078662256{1}), Failed Statement is: select
MAX(preke0_.BARKODAS) as col_0_0_, MAX(preke0_.PAVADINIMAS) as col_1_0_,
MAX(preke0_.KIEKIS) as col_2_0_, SUM(irasas1_.FAKTINIS_KIEKIS) as col_3_0_
from PREKE preke0_, IRASAS irasas1_, IRASU_BLOKAS irasubloka2_ where
irasas1_.IRASU_BLOKAS=irasubloka2_.ID and
preke0_.UNIKALUS_KODAS=irasas1_.UNIKALUS_KODAS and
irasubloka2_.INVENTORIZACIJA=? group by irasas1_.UNIKALUS_KODAS order by
abs(SUM(irasas1_.FAKTINIS_KIEKIS)-MAX(preke0_.KIEKIS)) DESC with 1 parameters
begin parameter #1: 1 :end parameter
java.lang.ArrayIndexOutOfBoundsException: 5
at org.apache.derby.impl.store.access.sort.MergeSort.compare(Unknown
Source)
at org.apache.derby.impl.store.access.sort.SortBuffer.insert(Unknown
Source)
at org.apache.derby.impl.store.access.sort.MergeInserter.insert(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.ProjectRestrictResultSet.openCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(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.processCommands(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Using EMMA for codecoverage analysis
Vemund Ostgaard wrote: I got suites.All to run with EMMA, but I had to add 7-8 lines to derby_tests.policy and modify a couple of tests before it ran cleanly. I think it would be good if this worked without editing the source, so I'll make a Jira and upload a patch with these changes. It might be good to separate out the test changes, I'd be interested to understand why they needed to be changed to run under code coverage. I'm thinking about adding some ant tasks for instrumenting classes/jars and running the junit-tests with EMMA, making it easier to do this. +1 Thanks, Dan.
[jira] Commented: (DERBY-3378) Derby's timer thread should have a name that identifies it as belong to a derby instance
[ https://issues.apache.org/jira/browse/DERBY-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570771#action_12570771 ] Daniel John Debrunner commented on DERBY-3378: -- I applied the patch but it fails to compile for me. Turns out the Timer constructors that take a name were only added in JDK 1.5 and so do not compile with JDK 1.4 and J2ME/CDC/Foundation which Derby still supports. A specific implementation of the TimerFactory could be added for JDK 1.5 (that used new Timer(derby.timer, ...)) but I'm not sure it's worth it. Sorry, I didn't realize that the constructor was new to JDK 1.5. Derby's timer thread should have a name that identifies it as belong to a derby instance Key: DERBY-3378 URL: https://issues.apache.org/jira/browse/DERBY-3378 Project: Derby Issue Type: Improvement Components: Newcomer, Services Reporter: Daniel John Debrunner Priority: Minor Attachments: DERBY-3378.diff Looking at the threads with jconsole when derby is running shows derby's timer thread as Timer-0. All other derby threads are given a name starting with 'derby.', would be useful if the same was true for the timer thread. In SingletonTimerFactory just use the Timer constructor that takes a name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570765#action_12570765 ] Daniel John Debrunner commented on DERBY-3435: -- Some potential javadoc improvements for NetworkServerMBean - add a package.html - Have the class javadoc define what type and other key properties are used (see the other MBeans) - Remove this vacuous sentence: This interface consists of getter and setter methods for attributes that may be read and/or modified, and methods representing operations that can be invoked. (it's adds no value, it's the definition of what an MBean is, it's like adding a comment to other classes this interface consists of methods that can be called and fields that can be referenced). - Correct the comment for getDrdaHost related to 0.0.0.0, it indicates it affects which clients can connect, I think it means that the server listens on all network interfaces - For each attribute getXXX method add a summary of what the property does, just saying it gets derby.drda.XXX doesn't really help much. - Make the first javadoc sentence of the getXXX methods be the (English) summary of what the attribute represents and not just that it maps to derby.drda.XXX. This means the class summary in javadoc becomes more useful, e.g. Gets the host name for the network server instead of the current Gets the value of the derby.drda.host network server setting. Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570768#action_12570768 ] Daniel John Debrunner commented on DERBY-3435: -- To complete the last thought, I think the javadoc should continue to contain the reference to the derby.drda.XXX setting, just not as the primary sentence. Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3435) Add an MBean for monitoring and managing the Network Server
[ https://issues.apache.org/jira/browse/DERBY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570772#action_12570772 ] John H. Embretsen commented on DERBY-3435: -- Thanks for the commit. Seems like you forgot to actually move the MBean interface to java/drda (?) - now I see the org.apache.derby.mbeans.drda package in java/engine as well as in java/drda. The suggested javadoc comments seem valid to me. The host property is a bit tricky as always (probably because it should be called derby.drda.connectionInterface or some such instead). The suggested 0.0.0.0 description change is fine, although the first sentence of the javadoc should be something like Gets the name of the network interface on which the network server is listening instead of Gets the host name for the network server ;-) Add an MBean for monitoring and managing the Network Server --- Key: DERBY-3435 URL: https://issues.apache.org/jira/browse/DERBY-3435 Project: Derby Issue Type: Sub-task Components: Network Server, Services Reporter: John H. Embretsen Assignee: John H. Embretsen Attachments: d3435_v01.diff, d3435_v01.stat Most functionality of and information about a running instance of the Network Server is currently only available from the host running the Network Server, using the NetworkServerControl API. With a JMX Management and Monitoring service in place utilizing JMX (DERBY-1387), it is possible to expose some of the Network Server functionality and information through an MBean that is specific to the Network Server, to both local and remote users (JMX clients), subject to security restrictions. Access to Derby libraries on the client side is not even a requirement, potentially making a server administrator's job a lot easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3094) Grouping of expressions causes NullPointerException
[ https://issues.apache.org/jira/browse/DERBY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570783#action_12570783 ] A B commented on DERBY-3094: Thank you for the updated patch, Bryan. Is there a more detailed writeup forthcoming for this change, or are the code comments the extent of it? The reason I ask is that, after reading the code comments and the comments in this issue, I can't quite see the correlation between the patch and the NPE that it fixes. That is, it's clear that the patch fixes the issue, but I think I'm missing the details on _why_. The code comments say: // then we don't want the replacement of the // simple column reference C1 to affect the // compound expression C1 * (C2 / 100). but it's not clear to me how replacement of the simple column reference can negatively affect the compound expressions. Is it an issue of VCN's pointing to the wrong place? If so, any idea as to why that happens? Similarly, in an earlier comment you noted: I think it's instructive to note that, with this patch applied, the following statement gets b and a backward: ij select b, a, count(*) from xx group by b, a; B |A |3 - 2.0 |3.0 |1 Is it possible to say what it is about processing simple column references _after_ compound expressions that fixes this problem? Apologies if I'm missing something obvious. I'm not by any means opposed to the patch, I'm just hoping to gain an understanding about why it resolves the discussion/issues raised thus far for this issue... And thanks for your continued diligence with this one, Bryan. Grouping of expressions causes NullPointerException --- Key: DERBY-3094 URL: https://issues.apache.org/jira/browse/DERBY-3094 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4 Environment: Windows XP, Eclipse 3.2.2, java 1.5.0.11 Reporter: Peter Balon Assignee: Bryan Pendleton Priority: Critical Attachments: modifyVisitorDoesntWork.diff, twoPass.diff, TwoPassVisitor.diff, TwoPassVisitorWithCommentsAndTests.diff Following steps to reproduce the bug: create table xx (a double, b double); insert into xx values (2, 3); select a, a*(b/100.00), count(*) from xx group by a, a*(b/100.00); Starting run select a, a*(b/100.00), count(*) from xx group by a, a*(b/100.00) Run successful SQL State = 38000 SQL Code = 2 SQL Message = Bei der Auswertung eines Ausdrucks wurde die Ausnahme 'java.lang.NullPointerException' ausgelöst. Exception message = java.sql.SQLException: Bei der Auswertung eines Ausdrucks wurde die Ausnahme 'java.lang.NullPointerException' ausgelöst. Work around: select a, a*(b/100.00), count(*) from xx group by a, b, a*(b/100.00) Stack trace from application: java.sql.SQLException: Bei der Auswertung eines Ausdrucks wurde die Ausnahme 'java.lang.NullPointerException' ausgelöst. at org.apache.derby.impl.jdbc.SQLExceptionFactory.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 de.arcor.billy.report.views.designer.ReportViewerView.setInput(ReportViewerView.java:255) at de.arcor.billy.report.views.designer.ReportViewerView.createPartControl(ReportViewerView.java:113) at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566) at org.eclipse.ui.internal.Perspective.showView(Perspective.java:1675) at org.eclipse.ui.internal.WorkbenchPage.busyShowView(WorkbenchPage.java:987) at org.eclipse.ui.internal.WorkbenchPage.access$13(WorkbenchPage.java:968) at org.eclipse.ui.internal.WorkbenchPage$13.run(WorkbenchPage.java:3514) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at
[jira] Commented: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570781#action_12570781 ] Kim Haase commented on DERBY-2653: -- Oh, I see. No problem, then, as far as behavior goes. But I looked all over, and I don't think we actually say that explicitly anywhere -- not in the Reference Manual, anyway. I see an error message to that effect, but that's all. Should that information be added to the generated-column-spec topic (http://db.apache.org/derby/docs/dev/ref/rrefsqlj37836.html)? If so, I can file and fix a JIRA issue. Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: crefjavstateautogen.html, derby-2653_columnIndexes_diff.txt, derby-2653_columnNames2_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_doc_diff.txt, derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570794#action_12570794 ] Kim Haase commented on DERBY-2653: -- Thanks, Kathey, I'll file an issue. There is no need to hold off on the changes to the crefjavstateautogen topic. That information will be important to have. The only change I was going to make to that topic was to remove the specific reference to JDBC 3.0, because the information applies to all versions of JDBC that we currently support. You could do that yourself if you would like to. If you wanted to fix the 3.0-specific Connection and Statement topics to correct the information about column indexes and column names, that would be okay too, since I haven't gotten to those and won't for a while. (I'm still waiting for feedback on DERBY-3409 (fixes related to the JDBC 2.0 topics). Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: crefjavstateautogen.html, derby-2653_columnIndexes_diff.txt, derby-2653_columnNames2_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_doc_diff.txt, derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570788#action_12570788 ] Kathey Marsden commented on DERBY-2653: --- Kim asked: Should that information be added to the generated-column-spec topic (http://db.apache.org/derby/docs/dev/ref/rrefsqlj37836.html)? If so, I can file and fix a JIRA issue. That would be great. Also should I hold off on the doc for this issue and let it get rolled in with DERBY-2388? Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: crefjavstateautogen.html, derby-2653_columnIndexes_diff.txt, derby-2653_columnNames2_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_doc_diff.txt, derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3442) Reference Manual doesn't state limit on number of identity columns
Reference Manual doesn't state limit on number of identity columns -- Key: DERBY-3442 URL: https://issues.apache.org/jira/browse/DERBY-3442 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.2.1 Reporter: Kim Haase Assignee: Kim Haase Priority: Minor An error message in the Reference Manual says, Only one identity column is allowed in a table. This limitation is not stated explicitly anywhere else, however, though it is implied in a number of places. The topic generated-column-spec, http://db.apache.org/derby/docs/dev/ref/rrefsqlj37836.html, needs to make this limitation clear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1387) Add JMX extensions to Derby
[ https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570797#action_12570797 ] Daniel John Debrunner commented on DERBY-1387: -- Patch jmxPolicyFileChanges_v1.diff committed (revision 629575) - Thanks John. Add JMX extensions to Derby --- Key: DERBY-1387 URL: https://issues.apache.org/jira/browse/DERBY-1387 Project: Derby Issue Type: New Feature Components: Services Reporter: Sanket Sharma Assignee: John H. Embretsen Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff, DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff, DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip, DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat, derby1387_simple_9_1.txt, derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, jmxFuncspec.html, jmxFuncspec.html, jmxPolicyFileChanges_v1.diff, Requirements for JMX Updated.html, Requirements for JMX.html, Requirements for JMX.zip This is a draft requirement specification for adding monitoring and management extensions to Apache Derby using JMX. The requirements document has been uploaded on JIRA as well as the Derby Wiki page at http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX Developers and Users are requested to please look at the document (feature list in particular) and add their own rating to features by adding a coloumn to the table. Comments are welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3441) Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570799#action_12570799 ] Kristian Waagan commented on DERBY-3441: The ones you mention are not too heavy weight. What about result sets? When running some of the tests, I observed lock timeouts. The failing tests were all SUR tests, and I think the locking behavior might be a bit special there. I tried a very experimental patch, where I closed the result sets on logical statement close and when running suites.All I was down to around 20+ errors/failures (as opposed to around 180). Most of these I could link to an existing bug. So even though I can't provide a proper answer now, I do believe there is more to be handled than what you mentioned above. I'll come back with more info as soon I as have any. All of this is a bit in the blue currently, so feedback is very much appreciated. I hope to get the basic machinery into place, and then work on issues one by one from there. Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool --- Key: DERBY-3441 URL: https://issues.apache.org/jira/browse/DERBY-3441 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Fix For: 10.4.0.0 Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool. A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code. Correctness is of course the most important thing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3430) Inconsistency in JDBC autogen APIs between Connection.prepareStatement(...) and Statement.execute(...)
[ https://issues.apache.org/jira/browse/DERBY-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3430. --- Resolution: Fixed Fixed in trunk with revision 629578 Inconsistency in JDBC autogen APIs between Connection.prepareStatement(...) and Statement.execute(...) -- Key: DERBY-3430 URL: https://issues.apache.org/jira/browse/DERBY-3430 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: derby-3430_diff.txt In EmbedStatement.java the execute(String, String[]), execute(String, int[]), executeUpdate(String, String[]), and executeUpdate(String, int[]) methods treat a 0-length array to mean NO_GENERATED_KEYS. But in EmbedConnection.java the prepareStatement(String, String[]) and prepareStatement(String, int[]) methods treat a 0-length array to mean RETURN_GENERATED_KEYS. For the sake of consistency, the two classes should treat 0-length arrays in the same way--which probably means changing EmbedConnection to match EmbedStatement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3442) Reference Manual doesn't state limit on number of identity columns
[ https://issues.apache.org/jira/browse/DERBY-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-3442: - Derby Info: [Patch Available] Reference Manual doesn't state limit on number of identity columns -- Key: DERBY-3442 URL: https://issues.apache.org/jira/browse/DERBY-3442 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.2.1 Reporter: Kim Haase Assignee: Kim Haase Priority: Minor Attachments: DERBY-3442.diff, rrefsqlj37836.html An error message in the Reference Manual says, Only one identity column is allowed in a table. This limitation is not stated explicitly anywhere else, however, though it is implied in a number of places. The topic generated-column-spec, http://db.apache.org/derby/docs/dev/ref/rrefsqlj37836.html, needs to make this limitation clear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570805#action_12570805 ] Kathey Marsden commented on DERBY-2653: --- I received a request to port this change to the 10.3 branch. I was wondering if anyone had any objections to my porting this to 10.3? Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: crefjavstateautogen.html, derby-2653_columnIndexes_diff.txt, derby-2653_columnNames2_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_doc_diff.txt, derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2653) Expose existing auto-generated key functionality through more JDBC APIs in Derby Client.
[ https://issues.apache.org/jira/browse/DERBY-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570803#action_12570803 ] Kathey Marsden commented on DERBY-2653: --- I checked in the doc change with revision 629580, but only made the changes for DERBY-2653. Expose existing auto-generated key functionality through more JDBC APIs in Derby Client. Key: DERBY-2653 URL: https://issues.apache.org/jira/browse/DERBY-2653 Project: Derby Issue Type: Improvement Components: JDBC Environment: Runnning with Derby Client. Reporter: A B Assignee: Kathey Marsden Priority: Minor Attachments: crefjavstateautogen.html, derby-2653_columnIndexes_diff.txt, derby-2653_columnNames2_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_columnNames_diff.txt, derby-2653_doc_diff.txt, derby-2653_proto_diff.txt See DERBY-2631 for details. Desired functionality is the same as for DERBY-2631, except that this issue is specifically for Derby Client (DERBY-2631 only addressed embedded mode). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3443) With IBM 1.6 derbynet/sysinfo.java nad derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties
With IBM 1.6 derbynet/sysinfo.java nad derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties - Key: DERBY-3443 URL: https://issues.apache.org/jira/browse/DERBY-3443 Project: Derby Issue Type: Bug Components: Regression Test Failure, Test Affects Versions: 10.3.2.2, 10.4.0.0 Reporter: Kathey Marsden Priority: Trivial thes tests on IBM 1.6 fail with: 4d3 - listing properties -- 37d35 - listing properties -- 71d68 - listing properties -- Test Failed. *** End: sysinfo_withproperties jdk1.6.0 DerbyNetClient Just a difference of how the JVM outputs the property listing. I think it can be fixed with a sed file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3442) Reference Manual doesn't state limit on number of identity columns
[ https://issues.apache.org/jira/browse/DERBY-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-3442: - Attachment: DERBY-3442.diff rrefsqlj37836.html Attaching fix to the generated-column-spec topic, with one sentence added, in DERBY-3442.diff and rrefsqlj37836.html. Reference Manual doesn't state limit on number of identity columns -- Key: DERBY-3442 URL: https://issues.apache.org/jira/browse/DERBY-3442 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.2.1 Reporter: Kim Haase Assignee: Kim Haase Priority: Minor Attachments: DERBY-3442.diff, rrefsqlj37836.html An error message in the Reference Manual says, Only one identity column is allowed in a table. This limitation is not stated explicitly anywhere else, however, though it is implied in a number of places. The topic generated-column-spec, http://db.apache.org/derby/docs/dev/ref/rrefsqlj37836.html, needs to make this limitation clear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3378) Derby's timer thread should have a name that identifies it as belong to a derby instance
[ https://issues.apache.org/jira/browse/DERBY-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570816#action_12570816 ] Serge Tsv commented on DERBY-3378: -- Hmmm... I should apologize myself first I guess for not actually verifying the patch. I haven't actually compiled the changed code using a Derby build.xml, as my Netbeans haven't displayed any error. Sorry for that. Not quite professional :-(, I guess it's a good lesson for a future. I do also think that implementing a Java SE 5 specific TimerFactory won't give many benefits which ant won't overweight a difficulty of maintaining an additional code. But anyway some common thread-naming scheme could be considered when and if there're plans for porting entirely to JDK 5. Thanks! Derby's timer thread should have a name that identifies it as belong to a derby instance Key: DERBY-3378 URL: https://issues.apache.org/jira/browse/DERBY-3378 Project: Derby Issue Type: Improvement Components: Newcomer, Services Reporter: Daniel John Debrunner Priority: Minor Attachments: DERBY-3378.diff Looking at the threads with jconsole when derby is running shows derby's timer thread as Timer-0. All other derby threads are given a name starting with 'derby.', would be useful if the same was true for the timer thread. In SingletonTimerFactory just use the Timer constructor that takes a name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3094) Grouping of expressions causes NullPointerException
[ https://issues.apache.org/jira/browse/DERBY-3094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-3094: --- Attachment: TwoPassForHavingClauseAlso.diff Attached is TwoPassForHavingClauseAlso.diff, which addresses the problem I noted with the HAVING clause in an earlier comment. Army, thanks for having a look at the patch. I am still intending to complete a more thorough description of the why behind the changes that should hopefully make it more clear. But for now, two quick responses: 1) substituting the column references with VCN's during group-by rewriting changes which result set is pointed to, but when we process the C1 portion of the compound expression but not the compound expression as a whole, we never correct the C2 column reference (since C2 by itself is not a grouping column), leaving the compound expression with C1 pointing to the correct result set, but C2 pointing to a non-existing result set, causing an NPE at runtime. 2) the earlier comment about getting b and a backward was simply a red herring. That particular patch attempt (modifyVisitorDoesntWork.diff) was simply flat-out wrong. :) I'll try to get a more thorough writeup completed soon. Grouping of expressions causes NullPointerException --- Key: DERBY-3094 URL: https://issues.apache.org/jira/browse/DERBY-3094 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4 Environment: Windows XP, Eclipse 3.2.2, java 1.5.0.11 Reporter: Peter Balon Assignee: Bryan Pendleton Priority: Critical Attachments: modifyVisitorDoesntWork.diff, twoPass.diff, TwoPassForHavingClauseAlso.diff, TwoPassVisitor.diff, TwoPassVisitorWithCommentsAndTests.diff Following steps to reproduce the bug: create table xx (a double, b double); insert into xx values (2, 3); select a, a*(b/100.00), count(*) from xx group by a, a*(b/100.00); Starting run select a, a*(b/100.00), count(*) from xx group by a, a*(b/100.00) Run successful SQL State = 38000 SQL Code = 2 SQL Message = Bei der Auswertung eines Ausdrucks wurde die Ausnahme 'java.lang.NullPointerException' ausgelöst. Exception message = java.sql.SQLException: Bei der Auswertung eines Ausdrucks wurde die Ausnahme 'java.lang.NullPointerException' ausgelöst. Work around: select a, a*(b/100.00), count(*) from xx group by a, b, a*(b/100.00) Stack trace from application: java.sql.SQLException: Bei der Auswertung eines Ausdrucks wurde die Ausnahme 'java.lang.NullPointerException' ausgelöst. at org.apache.derby.impl.jdbc.SQLExceptionFactory.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 de.arcor.billy.report.views.designer.ReportViewerView.setInput(ReportViewerView.java:255) at de.arcor.billy.report.views.designer.ReportViewerView.createPartControl(ReportViewerView.java:113) at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566) at org.eclipse.ui.internal.Perspective.showView(Perspective.java:1675) at org.eclipse.ui.internal.WorkbenchPage.busyShowView(WorkbenchPage.java:987) at org.eclipse.ui.internal.WorkbenchPage.access$13(WorkbenchPage.java:968) at org.eclipse.ui.internal.WorkbenchPage$13.run(WorkbenchPage.java:3514) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:3511) at de.arcor.billy.report.data.ReportDataAdvisor$2.perspectiveChanged(ReportDataAdvisor.java:268) at de.arcor.billy.system.actions.AbstractOpenPerspectiveActionDelegate$1.run(AbstractOpenPerspectiveActionDelegate.java:66) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at
[jira] Updated: (DERBY-3443) With IBM 1.6 derbynet/sysinfo.java, derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties
[ https://issues.apache.org/jira/browse/DERBY-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3443: -- Summary: With IBM 1.6 derbynet/sysinfo.java, derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties (was: With IBM 1.6 derbynet/sysinfo.java nad derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties) With IBM 1.6 derbynet/sysinfo.java, derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties -- Key: DERBY-3443 URL: https://issues.apache.org/jira/browse/DERBY-3443 Project: Derby Issue Type: Bug Components: Regression Test Failure, Test Affects Versions: 10.3.2.2, 10.4.0.0 Reporter: Kathey Marsden Priority: Trivial thes tests on IBM 1.6 fail with: 4d3 - listing properties -- 37d35 - listing properties -- 71d68 - listing properties -- Test Failed. *** End: sysinfo_withproperties jdk1.6.0 DerbyNetClient Just a difference of how the JVM outputs the property listing. I think it can be fixed with a sed file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JIRA developer access request
Hello! I'm new to the Derby development. I've just started working on the https://issues.apache.org/jira/browse/DERBY-3378 issue. I was instructed that I'll need a developer access in JIRA in order to assign myself to the issue. Could I be assigned a corresponding permissions please? My JIRA username is: serge.tsv Thanks!
[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570848#action_12570848 ] Kathey Marsden commented on DERBY-3310: --- Thank you so much Bryan for your help with this issue. I am a bit of a novice in this area so forgive if my questions are basic. You said: - the PRN should sort values with integer type, and feed them up to the NRSN - the NRS should invoke normalizeRow() to convert the int to a long - the InsertNode should pull long values from the NRS and insert them into the target table. and also said in an earlier comment. So I'd suggest investigating the NormalizeResultSetNode, and whether it is generating the proper buffering CAST operations. If the sort happens before normalization, how could CAST operations in NormalizeResultSetNode have an effect on the sort? ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions -- Key: DERBY-3310 URL: https://issues.apache.org/jira/browse/DERBY-3310 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: cast-repro.sql The following code CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; gives ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JIRA developer access request
Serge Tsaregorodtsev wrote: Hello! I'm new to the Derby development. I've just started working on the https://issues.apache.org/jira/browse/DERBY-3378 issue. I was instructed that I'll need a developer access in JIRA in order to assign myself to the issue. Could I be assigned a corresponding permissions please? My JIRA username is: serge.tsv Hello Serge, I have granted you (serge.tsv) developer access to the Derby project in JIRA. Again, welcome to the Derby community :) -- Kristian Thanks!
[jira] Updated: (DERBY-3426) Remove unused code for autogenerated keys columnNames
[ https://issues.apache.org/jira/browse/DERBY-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3426: -- Affects Version/s: 10.3.2.2 Remove unused code for autogenerated keys columnNames - Key: DERBY-3426 URL: https://issues.apache.org/jira/browse/DERBY-3426 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.3.2.2, 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3426_diff.txt, derby-3426_diff2.txt There is unused code for autogenerated keys that processes columnNames by flowing a select from final table statement to the server. This syntax is not supported or used by Derby and should be removed from client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3426) Remove unused code for autogenerated keys columnNames
[ https://issues.apache.org/jira/browse/DERBY-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3426: -- Fix Version/s: 10.3.2.2 Remove unused code for autogenerated keys columnNames - Key: DERBY-3426 URL: https://issues.apache.org/jira/browse/DERBY-3426 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.3.2.2, 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Fix For: 10.3.2.2, 10.4.0.0 Attachments: derby-3426_diff.txt, derby-3426_diff2.txt There is unused code for autogenerated keys that processes columnNames by flowing a select from final table statement to the server. This syntax is not supported or used by Derby and should be removed from client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3444) Tearoff database demo
Tearoff database demo - Key: DERBY-3444 URL: https://issues.apache.org/jira/browse/DERBY-3444 Project: Derby Issue Type: Task Components: Demos/Scripts Affects Versions: 10.4.0.0 Reporter: Rick Hillegas Create a demonstration of tearoff databases. This shows how to use arbitrary, parameterized queries to tearoff datasets from an arbitrary server-hosted database and load those datasets into a Derby database running on a handset. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3444) Tearoff database demo
[ https://issues.apache.org/jira/browse/DERBY-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3444: - Attachment: derby-3444-01-initial.diff Attach a demo, derby-3444-01-initial.diff. This demonstrates how easy it is to mobilize SQL data stored on a server and load that data into Derby databases running on handsets. Touches the following files: M build.xml Top level targets for building the demo and its javadoc. M java/demo/build.xml Helper targets invoked from the top level. A java/demo/tearoffs/README.html Description of the demo and instructions on how to build and run it. The demo consists of 3 processes: 1) A Derby server which hosts the demo data. 2) A scrap of servlet code which runs in a Tomcat server. 3) A game which uses the data and which runs on a handset. A java/demo/tearoffs/toolkit/... A toolkit for declaring parameterized subscriptions of server-hosted data. The data could live in any database with a jdbc driver, including DB2, Oracle, MySQL, Postgres, and Derby itself. A java/demo/tearoffs/example/customizeMe.properties A set of variables which you need to customize in order to build and run the demo. A java/demo/tearoffs/example/db/... A little bit of code for running a Derby server and loading it with demo data. A java/demo/tearoffs/example/handset/... The game which runs on a handset. A java/demo/tearoffs/example/tomcat/... The servlet which runs in Tomcat. Tearoff database demo - Key: DERBY-3444 URL: https://issues.apache.org/jira/browse/DERBY-3444 Project: Derby Issue Type: Task Components: Demos/Scripts Affects Versions: 10.4.0.0 Reporter: Rick Hillegas Attachments: derby-3444-01-initial.diff Create a demonstration of tearoff databases. This shows how to use arbitrary, parameterized queries to tearoff datasets from an arbitrary server-hosted database and load those datasets into a Derby database running on a handset. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570893#action_12570893 ] Bryan Pendleton commented on DERBY-3310: By itself, CAST operations in NormalizeResultSet would not fix the sort problem you are seeing, I agree. My comments are with respect to your earlier question: I am really not sure at the time of the sort whether both template and row data should be SQLInteger or SQLLongInt. If someone could explain which and why I think I am trying to propose a two-part theory: 1) at the time of the sort, both template and row data should be SQLInteger. 2) Since the Insert requires a SQLLongInteger, I think the conversion from Int to LongInt should occur in NormalizeResultSet, rather than in the sort. So working on NormalizeResultSet by itself would be only part of the solution, it still would also be necessary to change things so that the sort doesn't see the type mismatch. Does that make more sense? thanks, bryan ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions -- Key: DERBY-3310 URL: https://issues.apache.org/jira/browse/DERBY-3310 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: cast-repro.sql The following code CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; gives ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3443) With IBM 1.6 derbynet/sysinfo.java, derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties
[ https://issues.apache.org/jira/browse/DERBY-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-3443: - Assignee: Kathey Marsden With IBM 1.6 derbynet/sysinfo.java, derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties -- Key: DERBY-3443 URL: https://issues.apache.org/jira/browse/DERBY-3443 Project: Derby Issue Type: Bug Components: Regression Test Failure, Test Affects Versions: 10.3.2.2, 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Trivial thes tests on IBM 1.6 fail with: 4d3 - listing properties -- 37d35 - listing properties -- 71d68 - listing properties -- Test Failed. *** End: sysinfo_withproperties jdk1.6.0 DerbyNetClient Just a difference of how the JVM outputs the property listing. I think it can be fixed with a sed file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
[ https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570901#action_12570901 ] Kathey Marsden commented on DERBY-3310: --- Thanks Bryan, that makes sense to me. My primary focus is to change the sort so it doesn't see the type mismatch. From what you say, the change to VirtualColumnNode http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/VirtualColumnNode.java?p2=%2Fdb%2Fderby%2Fcode%2Ftrunk%2Fjava%2Fengine%2Forg%2Fapache%2Fderby%2Fimpl%2Fsql%2Fcompile%2FVirtualColumnNode.javap1=%2Fdb%2Fderby%2Fcode%2Ftrunk%2Fjava%2Fengine%2Forg%2Fapache%2Fderby%2Fimpl%2Fsql%2Fcompile%2FVirtualColumnNode.javar1=554012r2=554011view=diffpathrev=554012 should not have affected the sort phase, but clearly it did. I think it would help a lot to understand why this change was made. Dan could you elaborate? ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions -- Key: DERBY-3310 URL: https://issues.apache.org/jira/browse/DERBY-3310 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Dyre Tjeldvoll Priority: Minor Attachments: cast-repro.sql The following code CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT); -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT) INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2 FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID; gives ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class org.apache.derby.iapi.types.SQLInteger) expected to be the same as col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): org.apache.derby.shared.common.sanity.AssertFailure'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3443) With IBM 1.6 derbynet/sysinfo.java, derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties
[ https://issues.apache.org/jira/browse/DERBY-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570928#action_12570928 ] Daniel John Debrunner commented on DERBY-3443: -- Just to add, the listing properties line comes from the Java library class method java.util.Properties.list(). When these tests are converted to Junit it would be good to get rid of this dependency on a method intended for debugging (and thus producing different outpput on different vms). With IBM 1.6 derbynet/sysinfo.java, derbynet/sysinfo_withproperties and derbynet/getCurrentProperties fail with missing line listing properties -- Key: DERBY-3443 URL: https://issues.apache.org/jira/browse/DERBY-3443 Project: Derby Issue Type: Bug Components: Regression Test Failure, Test Affects Versions: 10.3.2.2, 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Trivial thes tests on IBM 1.6 fail with: 4d3 - listing properties -- 37d35 - listing properties -- 71d68 - listing properties -- Test Failed. *** End: sysinfo_withproperties jdk1.6.0 DerbyNetClient Just a difference of how the JVM outputs the property listing. I think it can be fixed with a sed file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3428) Doing a replication failover should shutdown the database and the connection should no longer be available
[ https://issues.apache.org/jira/browse/DERBY-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3428: --- Attachment: Derby3428.stat Derby3428.diff Thank you for the suggestions Jorgen on the reply to the email requesting more information on the handleException method in EmbedConnection. Following the suggested steps I found that throwing an exception with a Database severity does shutdown the database, but, only if it is not frozen :-/. During failover, before flushing the log records from the master to the slave, we freeze the database in question to prevent any more transactions from committing, since, these would never be conveyed to the slave. Allowing them to proceed would result in inconsistency. We do not unfreeze before throwing a database severity exception to cause a shutdown in case of a successful failover. This causes a hang when we try to shutdown. The obvious workaround was to unfreeze and then throw the exception. But this exposes a window, between unfreezing and throwing the exception when I suspect there is the danger of transactions commmiting. But the exception that is thrown upon failover should alert the clients that the danger of the previous transaction being lost exists. I am submitting a patch using the workaround above and hoping that the community can advice me more here. During the course of developing this patch I observed that we should have a tearDown method on the transmitter that the log shipper could call when it does a stopShipment. This would basically bring down the socket and the associated streams. I am *not* submitting this as part of this patch. Also the socket needs a timeout for reads on the InputStream obtained from it but I guess there is a JIRA for that already. Doing a replication failover should shutdown the database and the connection should no longer be available -- Key: DERBY-3428 URL: https://issues.apache.org/jira/browse/DERBY-3428 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: Derby3428.diff, Derby3428.stat Oystein says (as part of comments in Derby-3205) After executing a failover, I am told that the database is shut down, but I still able to use the connection to access the database: ij version 10.4 ij connect 'jdbc:derby:masterDB;user=oystein;password=pass'; ij call syscs_util.syscs_freeze_database(); 0 rows inserted/updated/deleted ij connect 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost'; ij(CONNECTION1) call syscs_util.syscs_unfreeze_database(); 0 rows inserted/updated/deleted ij(CONNECTION1) connect 'jdbc:derby:masterDB;user=oystein;password=pass;failover=true'; ERROR XRE20: Failover performed successfully for database 'null', the database has been shutdown. ij(CONNECTION1) select * from t; I --- 1 2 3 4 5 6 7 8 9 10 10 11 rows selected ij(CONNECTION1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3428) Doing a replication failover should shutdown the database and the connection should no longer be available
[ https://issues.apache.org/jira/browse/DERBY-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570964#action_12570964 ] V.Narayanan commented on DERBY-3428: The repro says this with the attached patch. ij version 10.4 ij connect 'jdbc:derby:masterDB;user=oystein;password=pass'; ij call syscs_util.syscs_freeze_database(); 0 rows inserted/updated/deleted ij connect 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost'; ij(CONNECTION1) connect 'jdbc:derby:masterDB;user=oystein;password=pass;failover=true'; ERROR XRE20: Failover performed successfully for database 'masterDB', the database has been shutdown. ij(CONNECTION1) select * from t; ERROR 08003: No current connection. ij(CONNECTION1) Doing a replication failover should shutdown the database and the connection should no longer be available -- Key: DERBY-3428 URL: https://issues.apache.org/jira/browse/DERBY-3428 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: Derby3428.diff, Derby3428.stat Oystein says (as part of comments in Derby-3205) After executing a failover, I am told that the database is shut down, but I still able to use the connection to access the database: ij version 10.4 ij connect 'jdbc:derby:masterDB;user=oystein;password=pass'; ij call syscs_util.syscs_freeze_database(); 0 rows inserted/updated/deleted ij connect 'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost'; ij(CONNECTION1) call syscs_util.syscs_unfreeze_database(); 0 rows inserted/updated/deleted ij(CONNECTION1) connect 'jdbc:derby:masterDB;user=oystein;password=pass;failover=true'; ERROR XRE20: Failover performed successfully for database 'null', the database has been shutdown. ij(CONNECTION1) select * from t; I --- 1 2 3 4 5 6 7 8 9 10 10 11 rows selected ij(CONNECTION1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3388) Improve message handling for replication messages to derby.log
[ https://issues.apache.org/jira/browse/DERBY-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland reassigned DERBY-3388: Assignee: Jørgen Løland Improve message handling for replication messages to derby.log -- Key: DERBY-3388 URL: https://issues.apache.org/jira/browse/DERBY-3388 Project: Derby Issue Type: Improvement Components: Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Priority: Minor The asynchronous replication functionality writes information to the derby log. It would be good to improve this in the following ways: 1: startSlave and stopSlave stack traces are written twice to the log - one is obviously enough :) 2: It should be possible to configure if replication messages written to the log should be followed by a stack trace of the cause. 3: logged messages should have a timestamp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3378) Derby's timer thread should have a name that identifies it as belong to a derby instance
[ https://issues.apache.org/jira/browse/DERBY-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Serge Tsv reassigned DERBY-3378: Assignee: Serge Tsv Derby's timer thread should have a name that identifies it as belong to a derby instance Key: DERBY-3378 URL: https://issues.apache.org/jira/browse/DERBY-3378 Project: Derby Issue Type: Improvement Components: Newcomer, Services Reporter: Daniel John Debrunner Assignee: Serge Tsv Priority: Minor Attachments: DERBY-3378.diff Looking at the threads with jconsole when derby is running shows derby's timer thread as Timer-0. All other derby threads are given a name starting with 'derby.', would be useful if the same was true for the timer thread. In SingletonTimerFactory just use the Timer constructor that takes a name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3404) EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT
[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570971#action_12570971 ] Mamta A. Satoor commented on DERBY-3404: Knut, just wanted you to know that I have applied your patch to my codeline and running derbyall and junit tests because I have some changes of my own for DERBY-3404. If everything runs fine, then I will go ahead and commit your patch alongwith my changes tomorrow. EmbedResultSet.getString() returns wrong value after auto-commit with CLOSE_CURSORS_AT_COMMIT - Key: DERBY-3404 URL: https://issues.apache.org/jira/browse/DERBY-3404 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: CloseOnCommit.java, d3404-v1.diff, d3404-v1.stat The following code prints null to the console with the embedded driver: Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs = s.executeQuery(select * from sysibm.sysdummy1); rs.next(); c.createStatement().executeQuery(values 1).close(); // causes auto-commit System.out.println(rs.getString(1)); The call to rs.getString() should perhaps have thrown SQLException, since the auto-commit between next() and getString() should close the ResultSet when the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3364) Replication failover implementation must be modified to fail at the master after slave has been stopped
[ https://issues.apache.org/jira/browse/DERBY-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570972#action_12570972 ] Jørgen Løland commented on DERBY-3364: -- To test the fix you describe, you could modify SlaveDatabase#stopSlave to call SlaveController#stopSlave(true) instead of stopSlave(false). That will reenable stopSlave when the network connection is working. This hack is only for testing your fix, of course... Replication failover implementation must be modified to fail at the master after slave has been stopped --- Key: DERBY-3364 URL: https://issues.apache.org/jira/browse/DERBY-3364 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Jorgen says... I tried to run the failover command on the master, which seems to work fine as long as the master and slave are still connected. If the slave has been stopped for some reason, however, failover hangs on MasterController#startFailover here: ack = transmitter.readMessage(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
