[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581015#action_12581015 ] V.Narayanan commented on DERBY-3551: I feel that the stored procedure will not be required. Turning on logging with the present logic will happen when the master is booted ( connection url with startMaster=true) Turning our attention to the future enhancements planned for 10.5 as mentioned in the functional specification How to start replication - Future enhancement (10.5) When replication is started, the slave checks that the database does not already exist, and that the user is authorized to create a database. The slave then starts to listen for a master on the specified host and port. The master connects to the slave and performs a handshake to ensure that only one master connects to a slave. The master then sends the whole database, including the active log files, to the slave via this connection. Hence, the database is only booted, not created, on the slave. -- The database copying operation happens when the master is connection to the slave. This is also where we turn on logging for unlogged operations. The stored procedure will then result in a series of redundant steps that would need to be performed again when we do the shipping automatically in the future enhancements for 10.5. That said, I think we need to move the steps mentioned above, to when we start the master controller. But I think this can wait till the above enhancements are implemented. For now the series of steps the user follows to start replication combined with the following check during replication startup "Check if any unlogged operations are currently running, if yes unfreeze and throw an exception saying that replication cannot be started since the database has unlogged operations running" Should suffice. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581020#action_12581020 ] V.Narayanan commented on DERBY-3551: >"Check if any unlogged operations are currently running, if yes unfreeze and >throw an exception >saying that replication cannot be started since the database has unlogged >operations running" Not sure if we should unfreeze or just throw an exception informing an user about the unlogged operations and let the user unfreeze the database > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3496) CallableStatement with output parameter leaves cursor open after execution
[ https://issues.apache.org/jira/browse/DERBY-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581023#action_12581023 ] Knut Anders Hatlen commented on DERBY-3496: --- The fix looks correct to me, but the new line in EmbedCallableStatement is not indented correctly (probably due to incorrect tab size setting in your IDE). > CallableStatement with output parameter leaves cursor open after execution > -- > > Key: DERBY-3496 > URL: https://issues.apache.org/jira/browse/DERBY-3496 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Dyre Tjeldvoll >Priority: Minor > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: derby-3496.diff, junit-repro.diff > > > When executing a CallableStatement which has an output parameter, the > language result set is left open and makes subsequent calls to > Connection.setTransactionIsolation() fail with "ERROR X0X03: Invalid > transaction state - held cursor requires same isolation level". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3562) Number of log files (and log dir size) on the slave increases continuously
[ https://issues.apache.org/jira/browse/DERBY-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581024#action_12581024 ] V.Narayanan commented on DERBY-3562: Not sure if the analysis here points at the rate of increase in the slave or the increase in the slave relative to the master. But isn't an increase in the log size of a slave expected, because the Slave receives log records from the master and use LogToFile#appendLogRecord to write these to disk. So basically the slave uses the logs received from the master to recover and move to a transaction consistent state. Incase you have not seen the following points from Derby-3071 (Modify logging subsystem for slave replication mode) * SlaveFactory (DERBY-3021) will receive log records from the master and use LogToFile#appendLogRecord to write these to disk. While in slave mode, only SlaveFactory will be allowed to append log records. * The thread running LogToFile#recover will recover (redo) one log file at a time (like now), but will not be allowed to open a log file X until that file is no longer being written to. Thus, while appenLogFile writes to logX.dat, recover will be allowed to read all log files up to and including logX-1.dat but will then have to wait until appendLogRecord starts writing to logX+1.dat. > Number of log files (and log dir size) on the slave increases continuously > -- > > Key: DERBY-3562 > URL: https://issues.apache.org/jira/browse/DERBY-3562 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 > Environment: - >Reporter: Ole Solberg > Attachments: master_slave-db_size-6.jpg > > > I did a simple test inserting tuples in a table during replication: > The attached file 'master_slave-db_size-6.jpg' shows that > the size of the log directory (and number of files in the log directory) > increases continuously during replication, while on master the size > (and number of files) never exceeds ~12Mb (12 files?) in this scenario. > The seg0 directory on the slave stays at the same size as the master > seg0 directory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3551: --- Attachment: Derby3551_2.stat Derby3551_2.diff I have modified Derby3551_1.diff to now throw an error when unlogged operations are running. I feel we should not unfreeze and instead should let the user unfreeze. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3562) Number of log files (and log dir size) on the slave increases continuously
[ https://issues.apache.org/jira/browse/DERBY-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581046#action_12581046 ] Øystein Grøvlen commented on DERBY-3562: I think the issue may be that checkpointing is only happening at the master. Hence, log files are garbage-collected on the master, but not on the slave. If that is the case, one risk that with a long-running replication, the disk on the slave side will fill up. I do not think this is acceptable, and we need to look into how the recovery thread can be modified to garbage collect log files when checkpoint log records are encountered. > Number of log files (and log dir size) on the slave increases continuously > -- > > Key: DERBY-3562 > URL: https://issues.apache.org/jira/browse/DERBY-3562 > Project: Derby > Issue Type: Bug > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 > Environment: - >Reporter: Ole Solberg > Attachments: master_slave-db_size-6.jpg > > > I did a simple test inserting tuples in a table during replication: > The attached file 'master_slave-db_size-6.jpg' shows that > the size of the log directory (and number of files in the log directory) > increases continuously during replication, while on master the size > (and number of files) never exceeds ~12Mb (12 files?) in this scenario. > The seg0 directory on the slave stays at the same size as the master > seg0 directory. -- 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 (18 issues) Subscriber: derby-dev Key Summary DERBY-3496 CallableStatement with output parameter leaves cursor open after execution https://issues.apache.org/jira/browse/DERBY-3496 DERBY-3563 Create eclipse doc and ui plgin for 10.4 release https://issues.apache.org/jira/browse/DERBY-3563 DERBY-3169 Add documentation for replication https://issues.apache.org/jira/browse/DERBY-3169 DERBY-3162 Create a framework for replication tests https://issues.apache.org/jira/browse/DERBY-3162 DERBY-3382 Replication: Slave must inform master if DBs are out of sync. https://issues.apache.org/jira/browse/DERBY-3382 DERBY-3527 The slave will not notice that a network cable is unplugged and will therefore reject failover/stopSlave commands https://issues.apache.org/jira/browse/DERBY-3527 DERBY-3447 Shutdown on a database without stopping replication hangs https://issues.apache.org/jira/browse/DERBY-3447 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-3542 New ROW_NUMBER function topic needs a few minor fixes https://issues.apache.org/jira/browse/DERBY-3542 DERBY-3474 update unique constraint sections of refrence manual https://issues.apache.org/jira/browse/DERBY-3474 DERBY-3445 Make it easier to use the EMMA tool to measure the code coverage of the Derby testing https://issues.apache.org/jira/browse/DERBY-3445 DERBY-3494 Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode https://issues.apache.org/jira/browse/DERBY-3494 DERBY-3460 SQL roles: patch to mask off roles on 10.4 release branch https://issues.apache.org/jira/browse/DERBY-3460 DERBY-3327 SQL roles: Implement authorization stack (and SQL session context to hold it) https://issues.apache.org/jira/browse/DERBY-3327 DERBY-2871 XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. https://issues.apache.org/jira/browse/DERBY-2871 DERBY-3409 Remove JDBC 2.0-specific topics from Reference Manual and merge implementation notes as needed https://issues.apache.org/jira/browse/DERBY-3409 DERBY-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] Resolved: (DERBY-3560) build failure: Error running ${jdk16}/bin/javac compiler if jdk16 is not set on 10.3
[
https://issues.apache.org/jira/browse/DERBY-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden resolved DERBY-3560.
---
Resolution: Fixed
Committed patch to 10.3. On 10.3 thread dumps will only print if jdk16 is set
during build.
> build failure: Error running ${jdk16}/bin/javac compiler if jdk16 is not set
> on 10.3
>
>
> Key: DERBY-3560
> URL: https://issues.apache.org/jira/browse/DERBY-3560
> Project: Derby
> Issue Type: Bug
> Components: Build tools
>Affects Versions: 10.3.2.2
>Reporter: Kathey Marsden
>Assignee: Kathey Marsden
>Priority: Minor
> Attachments: derby-3560_diff.txt
>
>
> Bryan reported this issue after the change to print thread dumps on 10.3 with
> stress.multi when he didn't have jdk16 set. The build of ThreadDump should
> not occur if jdk16 is not set.
> /home2/bpendleton/src/derby/10_3/10.3/java/testing/build.xml:62: The
> following error occurred while executing this line:
> /home2/bpendleton/src/derby/10_3/10.3/java/testing/org/apache/derbyTesting/functionTests/util/build.xml:104:
> Error running ${jdk16}/bin/javac compiler
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (DERBY-3560) build failure: Error running ${jdk16}/bin/javac compiler if jdk16 is not set on 10.3
Kathey Marsden resolved DERBY-3560. --- Committed patch to 10.3. On 10.3 thread dumps will only print if jdk16 is set during build. Thanks Kathey! This seems like a good resolution to me. bryan
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581103#action_12581103 ] Kathey Marsden commented on DERBY-2109: --- Will there be documentation updates and a release note for this issue? It seems like it would make sense to file a separate issue for the work that has been done and submit doc changes and releaseNote with that, then it can be resolved and show up in the 10.4 release notes. > System privileges > - > > Key: DERBY-2109 > URL: https://issues.apache.org/jira/browse/DERBY-2109 > Project: Derby > Issue Type: New Feature > Components: Security >Affects Versions: 10.3.1.4 >Reporter: Rick Hillegas > Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, > derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, > DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, > DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, > DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, > DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, > DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, > DERBY-2109-12.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, > systemPrivs.html, systemPrivs.html, systemPrivs.html > > > Add mechanisms for controlling system-level privileges in Derby. See the > related email discussion at > http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. > The 10.2 GRANT/REVOKE work was a big step forward in making Derby more > secure in a client/server configuration. I'd like to plug more client/server > security holes in 10.3. In particular, I'd like to focus on authorization > issues which the ANSI spec doesn't address. > Here are the important issues which came out of the email discussion. > Missing privileges that are above the level of a single database: > - Create Database > - Shutdown all databases > - Shutdown System > Missing privileges specific to a particular database: > - Shutdown that Database > - Encrypt that database > - Upgrade database > - Create (in that Database) Java Plugins (currently Functions/Procedures, > but someday Aggregates and VTIs) > Note that 10.2 gave us GRANT/REVOKE control over the following > database-specific issues, via granting execute privilege to system > procedures: > Jar Handling > Backup Routines > Admin Routines > Import/Export > Property Handling > Check Table > In addition, since 10.0, the privilege of connecting to a database has been > controlled by two properties (derby.database.fullAccessUsers and > derby.database.defaultConnectionMode) as described in the security section of > the Developer's Guide (see > http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result
[ https://issues.apache.org/jira/browse/DERBY-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581113#action_12581113 ] Bryan Pendleton commented on DERBY-2351: Merged the modifySynonymResult.diff patch to the 10.3 branch as revision 639696. > ORDER BY with expression with distinct in the select list returns incorrect > result > -- > > Key: DERBY-2351 > URL: https://issues.apache.org/jira/browse/DERBY-2351 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4 > Environment: Any >Reporter: Yip Ng >Assignee: Bryan Pendleton > Fix For: 10.3.2.2, 10.4.0.0, 10.4.1.0, 10.5.0.0 > > Attachments: d2351_aliasing.diff, d2351_aliasing.diff, > d2351_aliasing_checkQualifiedName.diff, derby_2351.diff, derby_2351_v2.diff, > modifySynonymResults.diff, releaseNote.html, releaseNote.html, reproTests.diff > > > When distinct is in the select list and the query has order by with > expression, the resultset produced contains an additional column. > ij> create table t1 (c1 int, c2 varchar(10)) > 0 rows inserted/updated/deleted > ij> insert into t1 values (1,'a'),(2,'b'),(3,'c'); > 3 rows inserted/updated/deleted > select distinct c1, c2 from t1 order by c1; > C1 |C2 > -- > 1 |a > 2 |b > 3 |c > 3 rows selected > ij> select distinct c1, c2 from t1 order by c1+1; > C1 |C2|3 <=returns 3 > columns, incorrect result returned > -- > 1 |a |2 > 2 |b |3 > 3 |c |4 > 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-1168) Incorrect SQLState used in EmbedConnection.java.close() when there is an active transaction
[ https://issues.apache.org/jira/browse/DERBY-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-1168. --- Resolution: Duplicate This is a duplicate of DERBY-2065 now fixed. > Incorrect SQLState used in EmbedConnection.java.close() when there is an > active transaction > --- > > Key: DERBY-1168 > URL: https://issues.apache.org/jira/browse/DERBY-1168 > Project: Derby > Issue Type: Bug > Components: JDBC >Reporter: David Van Couvering >Priority: Minor > > EmbedConnection.close() should use SQLState 25001 - Invalid transaction state > - active SQL-Transaction, when an attempt to close is made with an open > transaction. From the specification of disconnect in SQL 2003: 'If any > SQL-connection in L is active, then an exception condition is raised: invalid > transaction state ? active SQL-transaction." Currently it is using 25000, > which simply means "Invalid transaction state." Note the message is also > very unhelpful, it simply says "Invalid transaction state." > Although this is currently under debate, at this point we need to assume that > SQL States can not change except across major release boundaries, so I am > logging this bug but we can't fix it until 11.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2983) The ResultSet returned by DatabaseMetaData.getFunctions() does not contain a required column named FUNCTION_TYPE.
[ https://issues.apache.org/jira/browse/DERBY-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-2983. --- Resolution: Fixed Derby Info: (was: [Release Note Needed]) This looks fixed in 10.4. Per Dan's comments a release note is probably not needed, since it is unlikely a user would be dependent on the wrong behavior. If I am mistaken please reopen, remark Release Note Needed flag. Kathey > The ResultSet returned by DatabaseMetaData.getFunctions() does not contain a > required column named FUNCTION_TYPE. > - > > Key: DERBY-2983 > URL: https://issues.apache.org/jira/browse/DERBY-2983 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.4.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.4.0.0 > > Attachments: derby-2983-01-newColumn.diff, releaseNote.html > > > The FUNCTION_TYPE column, sandwiched between REMARKS and SPECIFIC_NAME, is > supposed to describe the return type of the function. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3563) Create eclipse doc and ui plgin for 10.4 release
[ https://issues.apache.org/jira/browse/DERBY-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjula Kutty updated DERBY-3563: - Attachment: DERBY-3563_diff_03_21.txt DERBY-3563_stat_03_21.txt I did change the version in the plugin.xml for both ui and doc plugins. But they are not checked in. Can any one please check this in? > Create eclipse doc and ui plgin for 10.4 release > > > Key: DERBY-3563 > URL: https://issues.apache.org/jira/browse/DERBY-3563 > Project: Derby > Issue Type: Task > Components: Eclipse Plug-in >Affects Versions: 10.4.1.0 >Reporter: Manjula Kutty >Assignee: Manjula Kutty > Fix For: 10.4.1.0 > > Attachments: DERBY-3563_diff_03_21.txt, DERBY-3563_stat_03_21.txt, > derby_doc_plugin_1.1.2.zip, derby_ui_plugin_1.1.2.zip > > > Place holder to upload the eclipse plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3564) With IBM 1.6 JVMDUMP006I Processing Dump Event "abort" or OOM running Suites.All
[ https://issues.apache.org/jira/browse/DERBY-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3564. --- Resolution: Invalid Resolving invalid since it is a JVM issue. Just wanted to get it filed in case someone hits it and needs the workaround. > With IBM 1.6 JVMDUMP006I Processing Dump Event "abort" or OOM running > Suites.All > > > Key: DERBY-3564 > URL: https://issues.apache.org/jira/browse/DERBY-3564 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.4.0.0, 10.5.0.0 > Environment: Windows XP > java version "1.6.0" > Java(TM) SE Runtime Environment (build pwi3260sr1-20080309_01) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 > jvmwi3260-20080308_17822 (JIT enabled, AOT enabled) > J9VM - 20080308_017822_lHdSMr > JIT - r9_20080307_1821 > GC - 20080305_AB) > JCL - 20080301_01 > [C:/kmarsden/repro/derby-2109] >Reporter: Kathey Marsden > > Running suites.All with the IBM 16 jvm the test run aborted > with > testGetSchemasModify used 1922 ms . > testGetTablesReadOnly used 10187 ms .JVMDUMP006I Processing > Dump Event "abort", detail "" - Please Wait. > JVMDUMP007I JVM Requesting System Dump using > 'C:\test6\core.20071107.211247.2712.0001.dmp' > JVMDUMP012E Error in System Dump: Dump failed - could not link > MiniDumpWriteDump in DBGHELP.DLL > JVMDUMP007I JVM Requesting Snap Dump using > 'C:\test6\Snap.20071107.211247.2712.0002.trc' > JVMDUMP010I Snap Dump written to > C:\test6\Snap.20071107.211247.2712.0002.trc > JVMDUMP007I JVM Requesting Java Dump using > 'C:\test6\javacore.20071107.211247.2712.0003.txt' > UTE430: can't allocate buffer > UTE437: Unable to load formatStrings for j9mm > UTE430: can't allocate buffer > UTE437: Unable to load formatStrings for j9mm > UTE430: can't allocate buffer > Sometimes it will abort with an OOM error. > This appears to be a JVM issue. The workaround is to set > -Xjit:disableInterpreterProfiling > I am tracking the issue as bug 481847. Please let me know if you need > updates on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3564) With IBM 1.6 JVMDUMP006I Processing Dump Event "abort" or OOM running Suites.All
With IBM 1.6 JVMDUMP006I Processing Dump Event "abort" or OOM running Suites.All Key: DERBY-3564 URL: https://issues.apache.org/jira/browse/DERBY-3564 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.4.0.0, 10.5.0.0 Environment: Windows XP java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr1-20080309_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080308_17822 (JIT enabled, AOT enabled) J9VM - 20080308_017822_lHdSMr JIT - r9_20080307_1821 GC - 20080305_AB) JCL - 20080301_01 [C:/kmarsden/repro/derby-2109] Reporter: Kathey Marsden Running suites.All with the IBM 16 jvm the test run aborted with testGetSchemasModify used 1922 ms . testGetTablesReadOnly used 10187 ms .JVMDUMP006I Processing Dump Event "abort", detail "" - Please Wait. JVMDUMP007I JVM Requesting System Dump using 'C:\test6\core.20071107.211247.2712.0001.dmp' JVMDUMP012E Error in System Dump: Dump failed - could not link MiniDumpWriteDump in DBGHELP.DLL JVMDUMP007I JVM Requesting Snap Dump using 'C:\test6\Snap.20071107.211247.2712.0002.trc' JVMDUMP010I Snap Dump written to C:\test6\Snap.20071107.211247.2712.0002.trc JVMDUMP007I JVM Requesting Java Dump using 'C:\test6\javacore.20071107.211247.2712.0003.txt' UTE430: can't allocate buffer UTE437: Unable to load formatStrings for j9mm UTE430: can't allocate buffer UTE437: Unable to load formatStrings for j9mm UTE430: can't allocate buffer Sometimes it will abort with an OOM error. This appears to be a JVM issue. The workaround is to set -Xjit:disableInterpreterProfiling I am tracking the issue as bug 481847. Please let me know if you need updates on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3558) regression test failure in testDerbyJarAttributeAlpha - Security Exception
[ https://issues.apache.org/jira/browse/DERBY-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali reassigned DERBY-3558: - Assignee: Mike Matrigali > regression test failure in testDerbyJarAttributeAlpha - Security Exception > -- > > Key: DERBY-3558 > URL: https://issues.apache.org/jira/browse/DERBY-3558 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.5.0.0 > Environment: ibm16 jvm > windows XP > SANE, classes >Reporter: Mike Matrigali >Assignee: Mike Matrigali > > I am getting 41 errors in this test of the following form, all security > exceptions from the management test suite. I can post others > if necessary. > 2) > testDerbyJarAttributeAlpha(org.apache.derbyTesting.functionTests.tests.management.VersionMBeanTest)javax.management.RuntimeMBeanException: > java.lan > g.SecurityException: Access denied > (org.apache.derby.security.SystemPermission engine monitor) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:856) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:869) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:670) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest$4.run(MBeanTest.java:382) > at java.security.AccessController.doPrivileged(AccessController.java:251) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getAttribute(MBeanTest.java:379) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.checkBooleanAttributeValue(MBeanTest.java:431) > at > org.apache.derbyTesting.functionTests.tests.management.VersionMBeanTest.testDerbyJarAttributeAlpha(VersionMBeanTest.java:120) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > Caused by: java.lang.SecurityException: Access denied > (org.apache.derby.security.SystemPermission engine monitor) > at > org.apache.derby.iapi.services.info.Version.checkMonitor(Version.java:70) > at org.apache.derby.iapi.services.info.Version.isAlpha(Version.java:121) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) > at > com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) > at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65) > at > com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216) > at javax.management.StandardMBean.getAttribute(StandardMBean.java:358) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666) > ... 40 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3558) regression test failure in testDerbyJarAttributeAlpha - Security Exception
[ https://issues.apache.org/jira/browse/DERBY-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali resolved DERBY-3558. --- Resolution: Fixed Fix Version/s: 10.5.0.0 commited change to trunk to fix this classes only issue. > regression test failure in testDerbyJarAttributeAlpha - Security Exception > -- > > Key: DERBY-3558 > URL: https://issues.apache.org/jira/browse/DERBY-3558 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.5.0.0 > Environment: ibm16 jvm > windows XP > SANE, classes >Reporter: Mike Matrigali >Assignee: Mike Matrigali > Fix For: 10.5.0.0 > > > I am getting 41 errors in this test of the following form, all security > exceptions from the management test suite. I can post others > if necessary. > 2) > testDerbyJarAttributeAlpha(org.apache.derbyTesting.functionTests.tests.management.VersionMBeanTest)javax.management.RuntimeMBeanException: > java.lan > g.SecurityException: Access denied > (org.apache.derby.security.SystemPermission engine monitor) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:856) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:869) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:670) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest$4.run(MBeanTest.java:382) > at java.security.AccessController.doPrivileged(AccessController.java:251) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getAttribute(MBeanTest.java:379) > at > org.apache.derbyTesting.functionTests.tests.management.MBeanTest.checkBooleanAttributeValue(MBeanTest.java:431) > at > org.apache.derbyTesting.functionTests.tests.management.VersionMBeanTest.testDerbyJarAttributeAlpha(VersionMBeanTest.java:120) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > Caused by: java.lang.SecurityException: Access denied > (org.apache.derby.security.SystemPermission engine monitor) > at > org.apache.derby.iapi.services.info.Version.checkMonitor(Version.java:70) > at org.apache.derby.iapi.services.info.Version.isAlpha(Version.java:121) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) > at > com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) > at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65) > at > com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216) > at javax.management.StandardMBean.getAttribute(StandardMBean.java:358) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666) > ... 40 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2682) org.apache.derbyTesting.functionTests.tests.store.EncryptionKeyAESTest tests fail with java.security.AccessControlException: access denied (java.util.PropertyPermission use
[ https://issues.apache.org/jira/browse/DERBY-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-2682. - Resolution: Cannot Reproduce I tried this test on IBM 1.4.2 and it seems to pass fine now. > org.apache.derbyTesting.functionTests.tests.store.EncryptionKeyAESTest tests > fail with java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read) on IBM 1.4.2 > - > > Key: DERBY-2682 > URL: https://issues.apache.org/jira/browse/DERBY-2682 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure > Environment: Java(TM) 2 Runtime Environment, Standard Edition (build > 1.4.2) > Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142-20061124 (SR7) > (JIT enabled: jitc)) >Reporter: Kathey Marsden >Priority: Minor > > On IBM jdk 1.4.2 the File.mkdirs() call requires permission > (java.util.PropertyPermission user.dir read) causing this > test failure. This does not occur with IBM 1.5. Below is the failure. Also > failures with EncryptionKeyDESTest and EncryptionKeyBlowFishTest > [C:/test] java junit.textui.TestRunner > org.apache.derbyTesting.functionTests.tests.store.EncryptionKeyAESTest > ...E.E.E.E..F > Time: 10.64 > There were 4 errors: > 1) > testBackupEncryptedDatabase(org.apache.derbyTesting.functionTests.tests.store.EncryptionKeyAESTest)java.sql.SQLExcept > ion: The exception 'java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read)' wa > s thrown while evaluating an expression. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown > Source) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown > Source) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown > Source) > at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown > Source) > at > org.apache.derbyTesting.functionTests.tests.store.EncryptionKeyTest.testBackupEncryptedDatabase(EncryptionKey > Test.java:242) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > Caused by: ERROR 38000: The exception 'java.security.AccessControlException: > access denied (java.util.PropertyPermission > user.dir read)' was thrown while evaluating an expression. > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.iapi.error.StandardException.unexpectedUserException(Unknown > Source) > at > org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) > at > org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > ... 26 more > Caused by: java.security.AccessControlException: access denied > (java.util.PropertyPermission user.dir read) > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java(Compiled > Code)) > at > java.security.AccessController.checkPermission(AccessController.java(Compiled > Code)) > at > java.lang.SecurityManager.checkPermission(SecurityManager.java(Compiled Code)) > at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1290) > at java.lang.System.getProperty(System.java(Inlined Compiled Code)) > at java.io.Win32FileSystem.getUserPath(Win32Fil
[jira] Updated: (DERBY-3560) build failure: Error running ${jdk16}/bin/javac compiler if jdk16 is not set on 10.3
[
https://issues.apache.org/jira/browse/DERBY-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3560:
--
Fix Version/s: 10.3.2.2
> build failure: Error running ${jdk16}/bin/javac compiler if jdk16 is not set
> on 10.3
>
>
> Key: DERBY-3560
> URL: https://issues.apache.org/jira/browse/DERBY-3560
> Project: Derby
> Issue Type: Bug
> Components: Build tools
>Affects Versions: 10.3.2.2
>Reporter: Kathey Marsden
>Assignee: Kathey Marsden
>Priority: Minor
> Fix For: 10.3.2.2
>
> Attachments: derby-3560_diff.txt
>
>
> Bryan reported this issue after the change to print thread dumps on 10.3 with
> stress.multi when he didn't have jdk16 set. The build of ThreadDump should
> not occur if jdk16 is not set.
> /home2/bpendleton/src/derby/10_3/10.3/java/testing/build.xml:62: The
> following error occurred while executing this line:
> /home2/bpendleton/src/derby/10_3/10.3/java/testing/org/apache/derbyTesting/functionTests/util/build.xml:104:
> Error running ${jdk16}/bin/javac compiler
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3551: --- Attachment: runscript_import.sql I tested the patch Derby3551_2 with imports and it worked fine. Attached is a ij script that automatically exports and imports data, from tables it creates by itself. It tests the procedures SYSCS_UTIL.SYSCS_IMPORT_DATA and SYSCS_UTIL.SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE To use it to test imports in replication just do the initial replication setup in ij and then do run 'runscript_import.sql'; I thought the script might be helpful for people who wants to test imports with this patch without going through the creation of the tables and files necessary. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat, runscript_import.sql > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (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 updated DERBY-3430: -- Fix Version/s: 10.4.0.0 > 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 > Fix For: 10.4.0.0 > > 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] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581141#action_12581141 ] V.Narayanan commented on DERBY-3551: I had also earlier tested this patch for a simple index creation and it worked fine. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat, runscript_import.sql > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3560) build failure: Error running ${jdk16}/bin/javac compiler if jdk16 is not set on 10.3
[
https://issues.apache.org/jira/browse/DERBY-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden closed DERBY-3560.
-
> build failure: Error running ${jdk16}/bin/javac compiler if jdk16 is not set
> on 10.3
>
>
> Key: DERBY-3560
> URL: https://issues.apache.org/jira/browse/DERBY-3560
> Project: Derby
> Issue Type: Bug
> Components: Build tools
>Affects Versions: 10.3.2.2
>Reporter: Kathey Marsden
>Assignee: Kathey Marsden
>Priority: Minor
> Fix For: 10.3.2.2
>
> Attachments: derby-3560_diff.txt
>
>
> Bryan reported this issue after the change to print thread dumps on 10.3 with
> stress.multi when he didn't have jdk16 set. The build of ThreadDump should
> not occur if jdk16 is not set.
> /home2/bpendleton/src/derby/10_3/10.3/java/testing/build.xml:62: The
> following error occurred while executing this line:
> /home2/bpendleton/src/derby/10_3/10.3/java/testing/org/apache/derbyTesting/functionTests/util/build.xml:104:
> Error running ${jdk16}/bin/javac compiler
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3564) With IBM 1.6 JVMDUMP006I Processing Dump Event "abort" or OOM running Suites.All
[ https://issues.apache.org/jira/browse/DERBY-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3564. - > With IBM 1.6 JVMDUMP006I Processing Dump Event "abort" or OOM running > Suites.All > > > Key: DERBY-3564 > URL: https://issues.apache.org/jira/browse/DERBY-3564 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.4.0.0, 10.5.0.0 > Environment: Windows XP > java version "1.6.0" > Java(TM) SE Runtime Environment (build pwi3260sr1-20080309_01) > IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 > jvmwi3260-20080308_17822 (JIT enabled, AOT enabled) > J9VM - 20080308_017822_lHdSMr > JIT - r9_20080307_1821 > GC - 20080305_AB) > JCL - 20080301_01 > [C:/kmarsden/repro/derby-2109] >Reporter: Kathey Marsden > > Running suites.All with the IBM 16 jvm the test run aborted > with > testGetSchemasModify used 1922 ms . > testGetTablesReadOnly used 10187 ms .JVMDUMP006I Processing > Dump Event "abort", detail "" - Please Wait. > JVMDUMP007I JVM Requesting System Dump using > 'C:\test6\core.20071107.211247.2712.0001.dmp' > JVMDUMP012E Error in System Dump: Dump failed - could not link > MiniDumpWriteDump in DBGHELP.DLL > JVMDUMP007I JVM Requesting Snap Dump using > 'C:\test6\Snap.20071107.211247.2712.0002.trc' > JVMDUMP010I Snap Dump written to > C:\test6\Snap.20071107.211247.2712.0002.trc > JVMDUMP007I JVM Requesting Java Dump using > 'C:\test6\javacore.20071107.211247.2712.0003.txt' > UTE430: can't allocate buffer > UTE437: Unable to load formatStrings for j9mm > UTE430: can't allocate buffer > UTE437: Unable to load formatStrings for j9mm > UTE430: can't allocate buffer > Sometimes it will abort with an OOM error. > This appears to be a JVM issue. The workaround is to set > -Xjit:disableInterpreterProfiling > I am tracking the issue as bug 481847. Please let me know if you need > updates on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3544) If NetworkServer fails to shutdown when run as a separate process by NetworkServerTestSetup, test run will hang
[ https://issues.apache.org/jira/browse/DERBY-3544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3544. - > If NetworkServer fails to shutdown when run as a separate process by > NetworkServerTestSetup, test run will hang > --- > > Key: DERBY-3544 > URL: https://issues.apache.org/jira/browse/DERBY-3544 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.2.2, 10.4.1.0, 10.5.0.0 >Reporter: Kathey Marsden >Assignee: Daniel John Debrunner > Fix For: 10.5.0.0 > > Attachments: derby3544_diff.txt > > > If the NetworkServer fails to shutdown for some reason, we do not clean up > the process but will just hang the tests. We should kill off the process if > the server fails to shutdown and continue. To reproduce try runnning the > test derbynet.SecureServerTest with 10.3 derbyTesting.jar and 10.4 jars. See > DERBY-3534 for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3487) stress.multi fails with org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED No page at pagenumber: 6; ContainerHandle = BaseContainerHandle:(Container(0, 65)
[ https://issues.apache.org/jira/browse/DERBY-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3487. - > stress.multi fails with org.apache.derby.shared.common.sanity.AssertFailure: > ASSERT FAILED No page at pagenumber: 6; ContainerHandle = > BaseContainerHandle:(Container(0, 65)) > - > > Key: DERBY-3487 > URL: https://issues.apache.org/jira/browse/DERBY-3487 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Store >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Priority: Critical > Attachments: derbylog.zip > > > Running stress.multi on Linux IBM 1.5 the test failed with the following > trace in the derby.log: > select * from main2 :End prepared statement > 2008-03-01 04:31:39.460 GMT Thread[Thread-4,5,workers] (XID = 149271), > (SESSIONID = 12253), (DATABASE = mydb), (DRDAID = null), Committing > Exception trace: > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED No page at > pagenumber: 6; ContainerHandle = BaseContainerHandle:(Container(0, 65)) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147) > at > org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:838) > at > org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:820) > at > org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(BTreePostCommit.java:462) > at > org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(BTreePostCommit.java:278) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) > at > org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) > at > org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) > at java.lang.Thread.run(Thread.java:803) > 2008-03-01 04:31:39.515 GMT Thread[derby.rawStoreDaemon,5,derby.daemons] > Cleanup action starting > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED No page at > pagenumber: 6; ContainerHandle = BaseContainerHandle:(Container(0, 65)) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162) > at > org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147) > at > org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:838) > at > org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:820) > at > org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(BTreePostCommit.java:462) > at > org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(BTreePostCommit.java:278) > at > org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) > at > org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) > at > org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) > at java.lang.Thread.run(Thread.java:803) > Cleanup action completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3485) TransactionTable.sql fails
[ https://issues.apache.org/jira/browse/DERBY-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3485. - > TransactionTable.sql fails > --- > > Key: DERBY-3485 > URL: https://issues.apache.org/jira/browse/DERBY-3485 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure, Store >Affects Versions: 10.4.0.0 > Environment: IBM JDK 1.5 >Reporter: Kathey Marsden > > ** Start: TransactionTable jdk1.5.0 storeall:storemore 2008-02-29 03:17:47 *** > 242a243 > > NULL > > |SystemTransaction > >|IDLE|readonly|NULL > > > > > > > > > > > > > > > Test Failed. > *** End: TransactionTable jdk1.5.0 storeall:storemore 2008-02-29 03:18:01 > *** > -- > May be somewhat intermittent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3493) stress.multi times out waiting on testers with blocked testers waiting on the same statement
[
https://issues.apache.org/jira/browse/DERBY-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden closed DERBY-3493.
-
> stress.multi times out waiting on testers with blocked testers waiting on the
> same statement
>
>
> Key: DERBY-3493
> URL: https://issues.apache.org/jira/browse/DERBY-3493
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure, SQL, Test
>Affects Versions: 10.4.0.0
> Environment: IBM 1.5 Linux
>Reporter: Kathey Marsden
>Assignee: Knut Anders Hatlen
> Fix For: 10.4.0.0
>
> Attachments: d3493-1a.diff, d3493-1b.diff,
> threaddump-1204806990660.tdump
>
>
> The diff is:
> 7 del
> < ...running last checks via final.sql
> 7 add
> > ...timed out trying to kill all testers,
> >skipping last scripts (if any). NOTE: the
> >likely cause of the problem killing testers is
> >probably not enough VM memory OR test cases that
> >run for very long periods of time (so testers do not
> >have a chance to notice stop() requests
> Test Failed.
> The testers that are stuck are stuck on the same statement e.g.
> --
> update main2 set y = 'zzz' where x = 5;
> ERROR 08000: Connection closed by unknown interrupt.
> ERROR XJ001: Java exception: ': java.lang.InterruptedException'.
> The interupt exception shows:
> java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:199)
> at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:195)
> at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConn
> ctionContext.java:768)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
> at
> org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508)
> at
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
> The code at line 195 of GenericStatement shows:
>
> try {
> preparedStmt.wait();
> } catch (InterruptedException ie) {
> throw StandardException.interrupt(ie);
> }
> My first guess is that this is perhaps some type of Statement cache
> concurrency bug, but perhaps
> I am reading it wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3348) Small typo in table functions documentation. Should have EmployeeTable not EmployeesTable
[ https://issues.apache.org/jira/browse/DERBY-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3348. - > Small typo in table functions documentation. Should have EmployeeTable not > EmployeesTable > -- > > Key: DERBY-3348 > URL: https://issues.apache.org/jira/browse/DERBY-3348 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Abhishek Bhaskaran >Priority: Trivial > Attachments: derby3348.diff, derby3348.zip > > > I tried the table function example at: > http://db.apache.org/derby/docs/dev/devguide/cdevspecialtfbasic.html > There is small typo that the create function example. It uses EmployeesTable > instead of EmployeeTable to match the code example. I also am not sure if > using com.acme is ok. > CREATE FUNCTION externalEmployees > () > RETURNS TABLE > ( > employeeIdINT, > lastName VARCHAR( 50 ), > firstName VARCHAR( 50 ), > birthday DATE > ) > LANGUAGE JAVA > PARAMETER STYLE DERBY_JDBC_RESULT_SET > NO SQL > EXTERNAL NAME 'com.acme.hrSchema.EmployeesTable.read' > Should be > EXTERNAL NAME 'com.acme.hrSchema.EmployeeTable.read' > to match code example at > http://db.apache.org/derby/docs/dev/devguide/cdevspecialtfexample.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3001) SYSTABLES documentation for TABLETYPE should include 'A' (Synonym)
[ https://issues.apache.org/jira/browse/DERBY-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581146#action_12581146 ] Kathey Marsden commented on DERBY-3001: --- It's strange I don't see the change at http://db.apache.org/derby/manuals/reference/sqlj165.html Why would this be? > SYSTABLES documentation for TABLETYPE should include 'A' (Synonym) > -- > > Key: DERBY-3001 > URL: https://issues.apache.org/jira/browse/DERBY-3001 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.3.1.4 >Reporter: Kathey Marsden >Assignee: Abhilash T.G >Priority: Trivial > Fix For: 10.4.0.0 > > Attachments: derby-3001.diff > > > Add tabletype 'A' (SYNONYM) to doc at: > http://db.apache.org/derby/manuals/reference/sqlj165.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581159#action_12581159 ] Øystein Grøvlen commented on DERBY-3551: Since I guess unlogged operations will be blocked when the database is frozen, I think it will be safe to delay the check until starting the master. I think the proposed patch looks good. Do you plan to add some test cases? Some suggestions on wording: * LogToFile#replicationLogUnlogged: This method returns whether db is in master mode or not, and I think inReplicationMasterMode or something would be a better name. (The way the javadoc is written, it may lead you to think that you should call this method to activate logging.) * messages.xml: I would say 'cannot be started' , not 'booted' since the operation is called startMaster.' > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat, runscript_import.sql > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3563) Create eclipse doc and ui plgin for 10.4 release
[ https://issues.apache.org/jira/browse/DERBY-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-3563: -- Derby Info: (was: [Patch Available]) committed the patch DERBY-3563_diff_03_21.txt with revision 639755 > Create eclipse doc and ui plgin for 10.4 release > > > Key: DERBY-3563 > URL: https://issues.apache.org/jira/browse/DERBY-3563 > Project: Derby > Issue Type: Task > Components: Eclipse Plug-in >Affects Versions: 10.4.1.0 >Reporter: Manjula Kutty >Assignee: Manjula Kutty > Fix For: 10.4.1.0 > > Attachments: DERBY-3563_diff_03_21.txt, DERBY-3563_stat_03_21.txt, > derby_doc_plugin_1.1.2.zip, derby_ui_plugin_1.1.2.zip > > > Place holder to upload the eclipse plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3534) Run 10.3 tests against 10.4 to help identify any compatibility issues
[ https://issues.apache.org/jira/browse/DERBY-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3534: -- Attachment: 10.3.2.1_test_changes.txt I created the branch https://svn.apache.org/repos/asf/db/derby/code/branches/10.3.2.1_test to contain changes needed to run the 10.3.2.1 tests with 10.4 beta jars. The only two changes that I am really concerned about from a user perspective are r638422 | kmarsden | 2008-03-18 08:51:22 -0700 (Tue, 18 Mar 2008) | 5 lines Port test changes for DERBY-3160 (590720), to avoid authentication errors in AuthenticationTest, PoolDSAuthenticationTest and XADSAuthenticationTest with 10.4 r638155 | kmarsden | 2008-03-17 17:31:12 -0700 (Mon, 17 Mar 2008) | 4 lines Portions of DERBY-2109 test changes (632502) for required user/password for network server shutdown with authentication. Also put in stubs for new NetworkServerControl commands. Neither of these issues have a release note at this time, but should.The full list of changes to get the tests running with IBM 1.6 are attached in the file 10.3.2.1_test_changes.txt. With these changes suites.All runs cleanly against 10.4 beta jars. I am running derbyall to see if there is anything significant, but don't plan to make the changes on the branch to get derbyall to pass. > Run 10.3 tests against 10.4 to help identify any compatibility issues > - > > Key: DERBY-3534 > URL: https://issues.apache.org/jira/browse/DERBY-3534 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: 10.3.2.1_test_changes.txt, > derby-3534_changes_for_running_tests_DO_NOT_COMMIT.txt, rjall.out > > > It would be good to run the 10.3 tests against 10.4 to identify any compat > issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3563) Create eclipse doc and ui plgin for 10.4 release
[ https://issues.apache.org/jira/browse/DERBY-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581169#action_12581169 ] Myrna van Lunteren commented on DERBY-3563: --- backported revision 639755 to 10.4 with revision 639769. > Create eclipse doc and ui plgin for 10.4 release > > > Key: DERBY-3563 > URL: https://issues.apache.org/jira/browse/DERBY-3563 > Project: Derby > Issue Type: Task > Components: Eclipse Plug-in >Affects Versions: 10.4.1.0 >Reporter: Manjula Kutty >Assignee: Manjula Kutty > Fix For: 10.4.1.0 > > Attachments: DERBY-3563_diff_03_21.txt, DERBY-3563_stat_03_21.txt, > derby_doc_plugin_1.1.2.zip, derby_ui_plugin_1.1.2.zip > > > Place holder to upload the eclipse plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3001) SYSTABLES documentation for TABLETYPE should include 'A' (Synonym)
[ https://issues.apache.org/jira/browse/DERBY-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581170#action_12581170 ] Kim Haase commented on DERBY-3001: -- It looks as if the fix was applied only to the trunk version of the topic, http://db.apache.org/derby/docs/dev/ref/rrefsistabs24269.html. The statement that the Fix Version is 10.4 bears this out. The topic is still incorrect in the 10.3, 10.2, and 10.1 versions as well as in the 10.0 version that the issue refers to. (The topic file name changed from sqlj165 to rrefsistabs24269 at 10.1.) I don't know if it's necessary to backport the fix to all those releases -- kind of a judgment call. > SYSTABLES documentation for TABLETYPE should include 'A' (Synonym) > -- > > Key: DERBY-3001 > URL: https://issues.apache.org/jira/browse/DERBY-3001 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.3.1.4 >Reporter: Kathey Marsden >Assignee: Abhilash T.G >Priority: Trivial > Fix For: 10.4.0.0 > > Attachments: derby-3001.diff > > > Add tabletype 'A' (SYNONYM) to doc at: > http://db.apache.org/derby/manuals/reference/sqlj165.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3494) Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode
[ https://issues.apache.org/jira/browse/DERBY-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581178#action_12581178 ] Mamta A. Satoor commented on DERBY-3494: Kathey, I went through your changes and the great writeup that Army wrote and based on that, this code movement/cleanup looks good. Now NormalizeResultSetNode would be generated just like other nodes rather than the special genNormalizeResultSetNode method. The patch looks good for commit. > Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode > > > Key: DERBY-3494 > URL: https://issues.apache.org/jira/browse/DERBY-3494 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Priority: Minor > Attachments: d3494_npe_writeup.html, d3494_npe_writeup.html, > decompile.out, derby-3494_remove_genNormalizeResultSetNode_diff.txt, npe.sql > > > In DERBY-3310 Dan suggested ... > Setting up a NormalizeResultSetNode is spread over three locations, the class > itself (very little, it's almost acting like a C struct), > the genNormalizeResultSetNode method and then copyLengthsAndTypesToSource. A > good O-O implementation would have > the logic to create a NormalizeResultSetNode self-contained in > NormalizeResultSetNode. > Since the ResultColumnList of the original ResultSetNode correctly describes > the desired outcome, it's not clear to > me why NormalizeResultSetNode can't just refer to the same list and use it > for its processing. They may be some chance > that this would cause recursion at some point, where a NormalizeResultSetNode > would think it needed to be wrapped > in a NormalizeResultSetNode since the types of its columns and expression > don't match (i.e. when it is handled as a regular ResultSetNode). > I think moving the setup of a NormalizeResultSetNode into the class itself, > so that its inputs are just the ResultSetNode to wrap > would help clear up the code, especially if comments were added indicating > why certain actions were being taken. > I am separating this task out into a separate issue, so that it can be worked > on independently of DERBY-3310. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3001) SYSTABLES documentation for TABLETYPE should include 'A' (Synonym)
[ https://issues.apache.org/jira/browse/DERBY-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3001. - Thanks Kim, I guess I was looking at the wrong version of the docs. Change looks fine. I think there is no need to backport. > SYSTABLES documentation for TABLETYPE should include 'A' (Synonym) > -- > > Key: DERBY-3001 > URL: https://issues.apache.org/jira/browse/DERBY-3001 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.3.1.4 >Reporter: Kathey Marsden >Assignee: Abhilash T.G >Priority: Trivial > Fix For: 10.4.0.0 > > Attachments: derby-3001.diff > > > Add tabletype 'A' (SYNONYM) to doc at: > http://db.apache.org/derby/manuals/reference/sqlj165.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-3320:
---
Attachment: DERBY_3320_Collator_Support_Check_stat_v2.txt
DERBY_3320_Collator_Support_Check_diff_v2.txt
I am attaching a patch DERBY_3320_Collator_Support_Check_diff_v2.txt which will
make sure during the database create time that Collator support is available
from the JVM otherwise an exception will be thrown. As for the subsequent boot
times, the Collator support from the JVM will be checked the first time there
is a need to access Collator functionality. This may or may not be at the
database boot time. The first access to Collator object can happen under 2
scenarios 1)during database boot time because Store has to recover the database
or 2)if user exectues a SQL which requires territory based collation.
In order to do the check for Collator support during database create time, I
had to add code in DataValueFactoryImpl.boot to look at the collation attribute
on the JDBC url, verify it's value and see if user has requested territory
based collation. If yes, then verify that JVM supports the Collator for the
database's locale. Because the attribute value validation happens here in
DVF.boot, we do not need to do the value validation again in
DataDictionaryImpl.boot and hence I removed the collation attribute value
validation from DataDictionaryImpl.boot.
Also, BasicDatabase.boot does not have to make special call to DVF.setLocal to
set the locale on DVF because it now happens in DVF.boot method. This makes the
code fit more into the existing boot machinery rather than relying on special
calls like DVF.setLocale.
The Collator support is being done in a new method DVF.verifyCollatorSupport
and this method gets called both during database create time and during
subsequent database boot times, it gets called when the Collator object is
accessed for the first time.
I have added a new error message for unavailability of Collator and the message
reads as follows
Collator support not available from the JVM for the database's locale '{0}'.
If anyone has any other suggestion for the error message, please let me know.
Lastly, I could use some help in coming up with test cases for database
recovery such that the Collator support is available during create time, then
the database is crashed and during next boot time, store will try to recover
the database but should run into the situation that the Collator support is no
more available. This kind of test case will make sure that Collator
unavailability exception is thrown properly to the user even in case of store
recovery.
As for the non-recovery database case, I think we have test cases
already(CollationTest and CollationTest2) in place which run into problem on
phoneME. With revision 618507, we changed those tests to first check if the
collation support is available or not and run the tests only if the support is
available. These tests can be modified to not do the check. Instead let
database create fail with the new error message on phoneME and other platforms
that do not support the Collator for locales required by CollationTest and
CollationTest2. I can go ahead and make those changes to the test once I know
that the attached patch looks good to the community.
Please send in your comments, if any, on the attached patch.
> Database creation and boot should fail if collation=TERRITORY_BASED and the
> selected locale is not supported
>
>
> Key: DERBY-3320
> URL: https://issues.apache.org/jira/browse/DERBY-3320
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.4.0.0
> Environment: Java ME:
> Product: phoneME Advanced (phoneme_advanced_mr2-b34)
> Profile: Foundation Profile Specification 1.1
> Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386
> GNU/Linux
>Reporter: Vemund Østgaard
>Assignee: Mamta A. Satoor
> Attachments: DERBY_3320_Collator_Support_Check_diff_v2.txt,
> DERBY_3320_Collator_Support_Check_stat_v2.txt,
> DERBY_3320_not_ready_for_commit_diff_v1.txt,
> DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java
>
>
> A problem I've discovered when testing with the phoneME advanced platform is
> that the collationtests expect other locales than Locale.US to be available
> on the platform that is used for the test, and for phoneME advanced (when
> compiled as foundation profile) only Locale.US is available. From the jdk1.6
> javadoc of Collator.getAvailableLocales() I see that only Locale.US is
> strictly required:
> public static Locale[] getAvailableLocales()
> Returns an array of all locales for which the getInstance methods of this
> class
[jira] Created: (DERBY-3565) NullPointerException creating table in BaseDataFileFactory.addContainer with stress.multi test
NullPointerException creating table in BaseDataFileFactory.addContainer with
stress.multi test
--
Key: DERBY-3565
URL: https://issues.apache.org/jira/browse/DERBY-3565
Project: Derby
Issue Type: Bug
Components: Regression Test Failure, Store
Affects Versions: 10.3.2.2
Reporter: Kathey Marsden
In 10.3.2.2 (639527) I saw a NullPointerException in the stress.multi test
running wtih derby network client. The trace is below. I will attach or
reference the full test output.
2008-03-21 15:19:47.920 GMT Thread[DRDAConnThread_9,5,main] (XID = 213715),
(SESSIONID = 7842), (DATABASE = mydb), (DRDAID =
NF01.G537-867223197132743404{7844}), Failed Statement is: create table z (x
int)
java.lang.NullPointerException
at
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.addContainer(Unknown
Source)
at org.apache.derby.impl.store.raw.xact.Xact.addContainer(Unknown
Source)
at org.apache.derby.impl.store.access.heap.Heap.create(Unknown Source)
at
org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(Unknown
Source)
at
org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(Unknown
Source)
at
org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown
Source)
at org.apache.derby.impl.sql.execute.MiscResultSet.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.EmbedStatement.execute(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
Cleanup action completed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3565) NullPointerException creating table in BaseDataFileFactory.addContainer with stress.multi test
[
https://issues.apache.org/jira/browse/DERBY-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3565:
--
Attachment: multi_npe.zip
Attached is a zip file of the test output and database. This occurred on
Windows XP.
> NullPointerException creating table in BaseDataFileFactory.addContainer with
> stress.multi test
> --
>
> Key: DERBY-3565
> URL: https://issues.apache.org/jira/browse/DERBY-3565
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure, Store
>Affects Versions: 10.3.2.2
>Reporter: Kathey Marsden
> Attachments: multi_npe.zip
>
>
> In 10.3.2.2 (639527) I saw a NullPointerException in the stress.multi test
> running wtih derby network client. The trace is below. I will attach or
> reference the full test output.
> 2008-03-21 15:19:47.920 GMT Thread[DRDAConnThread_9,5,main] (XID = 213715),
> (SESSIONID = 7842), (DATABASE = mydb), (DRDAID =
> NF01.G537-867223197132743404{7844}), Failed Statement is: create table z
> (x int)
> java.lang.NullPointerException
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.addContainer(Unknown
> Source)
> at org.apache.derby.impl.store.raw.xact.Xact.addContainer(Unknown
> Source)
> at org.apache.derby.impl.store.access.heap.Heap.create(Unknown Source)
> at
> org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.MiscResultSet.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.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown
> Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
> Cleanup action completed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported
Do you have some way of creating a database, but then making the
Collator not available when you next try to boot the database. I am
trying to think of the recovery test case, but need to be able to create
the db using a territory based sorting and then the next test case needs
to boot the db and find that collator not available.
I assume you have the simple test case for creating the db with just
picking a territory that does not exist anywhere.
Mamta A. Satoor (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-3320:
---
Attachment: DERBY_3320_Collator_Support_Check_stat_v2.txt
DERBY_3320_Collator_Support_Check_diff_v2.txt
I am attaching a patch DERBY_3320_Collator_Support_Check_diff_v2.txt which will
make sure during the database create time that Collator support is available
from the JVM otherwise an exception will be thrown. As for the subsequent boot
times, the Collator support from the JVM will be checked the first time there
is a need to access Collator functionality. This may or may not be at the
database boot time. The first access to Collator object can happen under 2
scenarios 1)during database boot time because Store has to recover the database
or 2)if user exectues a SQL which requires territory based collation.
In order to do the check for Collator support during database create time, I
had to add code in DataValueFactoryImpl.boot to look at the collation attribute
on the JDBC url, verify it's value and see if user has requested territory
based collation. If yes, then verify that JVM supports the Collator for the
database's locale. Because the attribute value validation happens here in
DVF.boot, we do not need to do the value validation again in
DataDictionaryImpl.boot and hence I removed the collation attribute value
validation from DataDictionaryImpl.boot.
Also, BasicDatabase.boot does not have to make special call to DVF.setLocal to
set the locale on DVF because it now happens in DVF.boot method. This makes the
code fit more into the existing boot machinery rather than relying on special
calls like DVF.setLocale.
The Collator support is being done in a new method DVF.verifyCollatorSupport
and this method gets called both during database create time and during
subsequent database boot times, it gets called when the Collator object is
accessed for the first time.
I have added a new error message for unavailability of Collator and the message
reads as follows
Collator support not available from the JVM for the database's locale '{0}'.
If anyone has any other suggestion for the error message, please let me know.
Lastly, I could use some help in coming up with test cases for database
recovery such that the Collator support is available during create time, then
the database is crashed and during next boot time, store will try to recover
the database but should run into the situation that the Collator support is no
more available. This kind of test case will make sure that Collator
unavailability exception is thrown properly to the user even in case of store
recovery.
As for the non-recovery database case, I think we have test cases
already(CollationTest and CollationTest2) in place which run into problem on
phoneME. With revision 618507, we changed those tests to first check if the
collation support is available or not and run the tests only if the support is
available. These tests can be modified to not do the check. Instead let
database create fail with the new error message on phoneME and other platforms
that do not support the Collator for locales required by CollationTest and
CollationTest2. I can go ahead and make those changes to the test once I know
that the attached patch looks good to the community.
Please send in your comments, if any, on the attached patch.
Database creation and boot should fail if collation=TERRITORY_BASED and the
selected locale is not supported
Key: DERBY-3320
URL: https://issues.apache.org/jira/browse/DERBY-3320
Project: Derby
Issue Type: Bug
Affects Versions: 10.4.0.0
Environment: Java ME:
Product: phoneME Advanced (phoneme_advanced_mr2-b34)
Profile: Foundation Profile Specification 1.1
Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386
GNU/Linux
Reporter: Vemund Østgaard
Assignee: Mamta A. Satoor
Attachments: DERBY_3320_Collator_Support_Check_diff_v2.txt,
DERBY_3320_Collator_Support_Check_stat_v2.txt,
DERBY_3320_not_ready_for_commit_diff_v1.txt,
DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java
A problem I've discovered when testing with the phoneME advanced platform is
that the collationte
Regression Test Report - tinderbox_trunk16 639724 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 639724/2008-03-21 18:32:12 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 0274274 086.86% derbyall F:1,E:01045710456 0 1151.02% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-639724.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/639724_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/639724.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581199#action_12581199 ] Martin Zaun commented on DERBY-2109: > Will there be documentation updates and a release note for this issue? I'm working on a documentation update and a release note proposal for NetworkServerControl authentication. > System privileges > - > > Key: DERBY-2109 > URL: https://issues.apache.org/jira/browse/DERBY-2109 > Project: Derby > Issue Type: New Feature > Components: Security >Affects Versions: 10.3.1.4 >Reporter: Rick Hillegas > Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, > derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, > DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, > DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, > DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, > DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat, > DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, > DERBY-2109-12.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, > systemPrivs.html, systemPrivs.html, systemPrivs.html > > > Add mechanisms for controlling system-level privileges in Derby. See the > related email discussion at > http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. > The 10.2 GRANT/REVOKE work was a big step forward in making Derby more > secure in a client/server configuration. I'd like to plug more client/server > security holes in 10.3. In particular, I'd like to focus on authorization > issues which the ANSI spec doesn't address. > Here are the important issues which came out of the email discussion. > Missing privileges that are above the level of a single database: > - Create Database > - Shutdown all databases > - Shutdown System > Missing privileges specific to a particular database: > - Shutdown that Database > - Encrypt that database > - Upgrade database > - Create (in that Database) Java Plugins (currently Functions/Procedures, > but someday Aggregates and VTIs) > Note that 10.2 gave us GRANT/REVOKE control over the following > database-specific issues, via granting execute privilege to system > procedures: > Jar Handling > Backup Routines > Admin Routines > Import/Export > Property Handling > Check Table > In addition, since 10.0, the privilege of connecting to a database has been > controlled by two properties (derby.database.fullAccessUsers and > derby.database.defaultConnectionMode) as described in the security section of > the Developer's Guide (see > http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-2109) System privileges
Martin Zaun (JIRA) wrote: Will there be documentation updates and a release note for this issue? I'm working on a documentation update and a release note proposal for NetworkServerControl authentication. Thanks Martin! I think this will be very important to users coping with the change.
[jira] Updated: (DERBY-3534) Run 10.3 tests against 10.4 to help identify any compatibility issues
[ https://issues.apache.org/jira/browse/DERBY-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3534: -- Attachment: derbyall_report.txt Attached is the report from the derbyall run. I think the store unit tests failed because my tests were built sane and I was running against insane jars. Nothing else caught my eye as particularly troublesome. Kathey > Run 10.3 tests against 10.4 to help identify any compatibility issues > - > > Key: DERBY-3534 > URL: https://issues.apache.org/jira/browse/DERBY-3534 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: 10.3.2.1_test_changes.txt, > derby-3534_changes_for_running_tests_DO_NOT_COMMIT.txt, derbyall_report.txt, > rjall.out > > > It would be good to run the 10.3 tests against 10.4 to identify any compat > issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3537) Invalid use shutdown authentication checks in NetworkServerControlImpl.directShutdown()
[ https://issues.apache.org/jira/browse/DERBY-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Zaun updated DERBY-3537: --- Attachment: DERBY-3537-01.diff DERBY-3537-01.stat > ... especially since the code that started the server is the code that is > calling this shutdown and a user/password is not required for startup. Convinced. Please, find attached a patch: - NetworServerControlImpl.directShutdownInternal() changed from private to package access - ClientThread changed to call directShutdownInternal() circumventing any authentication/authorization checks The junit tests succeeded. A few derbayall tests failed because of unexpected output due to a debugging println() I'd overlooked (posted -01 patch is clean). Will run derbyall on posted patch again next week but really don't expect any difference. > Invalid use shutdown authentication checks in > NetworkServerControlImpl.directShutdown() > > > Key: DERBY-3537 > URL: https://issues.apache.org/jira/browse/DERBY-3537 > Project: Derby > Issue Type: Bug > Components: Network Server >Reporter: Daniel John Debrunner >Priority: Minor > Attachments: DERBY-3537-01.diff, DERBY-3537-01.stat > > > If ClientThread hits an SSLException exception it will call > NetworkServerControlImpl.directShutdown(). > DERBY-2109 added privilege checking to directShutdown() that includes > authentication. > I can't see how this call by ClientThread can be valid. Authentication is not > required to start the network server, thus a NetworkServerControl with no > user,password may be used and thus passed onto directShutdown() failing > authentication and then failing to perform the failed shutdown? > I think the error was adding the privilege check in DERBY-2109, it looks like > this method is for use only within the network server (actually this is the > only use of it), maybe the correct security mechanism would have been to make > the method package private? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3494) Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode
[ https://issues.apache.org/jira/browse/DERBY-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-3494: - Assignee: Kathey Marsden > Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode > > > Key: DERBY-3494 > URL: https://issues.apache.org/jira/browse/DERBY-3494 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Attachments: d3494_npe_writeup.html, d3494_npe_writeup.html, > decompile.out, derby-3494_remove_genNormalizeResultSetNode_diff.txt, npe.sql > > > In DERBY-3310 Dan suggested ... > Setting up a NormalizeResultSetNode is spread over three locations, the class > itself (very little, it's almost acting like a C struct), > the genNormalizeResultSetNode method and then copyLengthsAndTypesToSource. A > good O-O implementation would have > the logic to create a NormalizeResultSetNode self-contained in > NormalizeResultSetNode. > Since the ResultColumnList of the original ResultSetNode correctly describes > the desired outcome, it's not clear to > me why NormalizeResultSetNode can't just refer to the same list and use it > for its processing. They may be some chance > that this would cause recursion at some point, where a NormalizeResultSetNode > would think it needed to be wrapped > in a NormalizeResultSetNode since the types of its columns and expression > don't match (i.e. when it is handled as a regular ResultSetNode). > I think moving the setup of a NormalizeResultSetNode into the class itself, > so that its inputs are just the ResultSetNode to wrap > would help clear up the code, especially if comments were added indicating > why certain actions were being taken. > I am separating this task out into a separate issue, so that it can be worked > on independently of DERBY-3310. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3494) Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode
[ https://issues.apache.org/jira/browse/DERBY-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581204#action_12581204 ] Kathey Marsden commented on DERBY-3494: --- Thanks Mamta, I will plan to commit Monday unless anyone else has more comments. I noticed an indentation issue in the patch for NormalizeResultSetNode. I'll fix that up before I check in. Then I will work on incorporating copyLengthsAndTypesToSource into init. Kathey > Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode > > > Key: DERBY-3494 > URL: https://issues.apache.org/jira/browse/DERBY-3494 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Priority: Minor > Attachments: d3494_npe_writeup.html, d3494_npe_writeup.html, > decompile.out, derby-3494_remove_genNormalizeResultSetNode_diff.txt, npe.sql > > > In DERBY-3310 Dan suggested ... > Setting up a NormalizeResultSetNode is spread over three locations, the class > itself (very little, it's almost acting like a C struct), > the genNormalizeResultSetNode method and then copyLengthsAndTypesToSource. A > good O-O implementation would have > the logic to create a NormalizeResultSetNode self-contained in > NormalizeResultSetNode. > Since the ResultColumnList of the original ResultSetNode correctly describes > the desired outcome, it's not clear to > me why NormalizeResultSetNode can't just refer to the same list and use it > for its processing. They may be some chance > that this would cause recursion at some point, where a NormalizeResultSetNode > would think it needed to be wrapped > in a NormalizeResultSetNode since the types of its columns and expression > don't match (i.e. when it is handled as a regular ResultSetNode). > I think moving the setup of a NormalizeResultSetNode into the class itself, > so that its inputs are just the ResultSetNode to wrap > would help clear up the code, especially if comments were added indicating > why certain actions were being taken. > I am separating this task out into a separate issue, so that it can be worked > on independently of DERBY-3310. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
bug in soft upgrade mode?
In 10.3 I can do this: ij> create table t0 (i int not null, v varchar(1) not null, constraint uq unique(v,i)); 0 rows inserted/updated/deleted ij> alter table t0 alter v set data type varchar(2); 0 rows inserted/updated/deleted ij> In 10.4 soft upgrade mode I cannot: ij> create table t0 (i int not null, v varchar(1) not null, constraint uq unique(v,i)); 0 rows inserted/updated/deleted ij> alter table t0 alter v set data type varchar(2); ERROR 42Z20: Column 'V' cannot be made nullable. It is part of a primary key or unique constraint, which cannot have any nullable columns. ij> I think this is a bug with soft upgrade mode but am not sure. I think setting the type should not change the nullability of the column. Could someone confirm? Thanks Kathey
Regression Test Report - tinderbox_trunk16 639851 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 639851/2008-03-21 22:22:43 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 0274274 087.20% derbyall F:1,E:01045710456 0 1170.48% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-639851.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/639851_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/639851.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Resolved: (DERBY-3373) SQL "distinct" and "order by" needed together
[ https://issues.apache.org/jira/browse/DERBY-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton resolved DERBY-3373. Resolution: Fixed Fix Version/s: 10.5.0.0 Committed the patch to the 10.3 branch as revision 639935. > SQL "distinct" and "order by" needed together > - > > Key: DERBY-3373 > URL: https://issues.apache.org/jira/browse/DERBY-3373 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.2.1 > Environment: Solaris Dev Express, Java 5 >Reporter: Thomas Vatter >Assignee: Bryan Pendleton >Priority: Blocker > Fix For: 10.3.2.2, 10.4.0.0, 10.5.0.0 > > Attachments: allowExpressions.diff, mergeWith2351.diff > > > I am pasting here the communication from the mailinglist. I am having a > blocking and large problem with it because I have to make a release that > needs the specified SQL query. > tom_ wrote: > > The errormessage is > > > > The ORDER BY clause may not specify an expression, since the query > > specifies > > DISTINCT > > [Error Code: 2] > > [SQL State: 4287A] > > > > The statement is > > > > select distinct > > t1.t1_id, t2.t2value1, t2.t2value2, t2.t2value3 > > from > > t1, t2, t3 > > where > > ... > > order by lower(t2.t2value2) , lower(t2.t2value1) , lower(t2.t2value3) > > > > > > > > > > Dyre.Tjeldvoll wrote: > > > >> tom_ <[EMAIL PROTECTED]> writes: > >> > >> > >>> I am using "disctinct" because of some self-joins and also needed to add > >>> an > >>> "order by" clause. An error is shown. Is it not possible to use distinct > >>> and > >>> order by together? > >>> > >> I think it is allowed. Executing > >> > >> select distinct * from sys.systables order by tablename; > >> > >> in ij works just fine. Could you show the error message you get, and > >> perhaps what the table looks like? > >> > >> -- > >> dt > >> > >> > >> > « [hide part of quote] > Hi Tom - > I see what you mean using the demo DB toursDB: > ij> select * from airlines order by lower(airline_full); > A&|AIRLINE_FULL|BASIC_RATE|DISTANCE_DISCOUNT > |BUSINESS_LEVEL_FACTOR > |FIRSTCLASS_LEVEL_FACT&|ECONOMY_SE&|BUSINESS_S&|FIRSTCLASS& > --- > > AA|Amazonian Airways |0.18 |0.03 > |0.5 |1.5 |20 |10 |5 > US|Union Standard Airlines |0.19 |0.05 > |0.4 |1.6 |20 |10 |5 > 2 rows selected > ij> select distinct * from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> select distinct airline_full from airlines order by lower(airline_full); > ERROR 4287A: The ORDER BY clause may not specify an expression, since > the query specifies DISTINCT. > ij> > I didn't find a JIRA enhancement to remove this restriction. I suggest > you file an Enhancement request to remove the restriction reported by > ERROR 4287A. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
[ https://issues.apache.org/jira/browse/DERBY-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3551: --- Attachment: Derby3551_3.stat Derby3551_3.diff > Since I guess unlogged operations will be blocked when the database is > frozen, > I think it will be safe to delay the check until starting the master. correct, That is why I thought that a combination of the steps, the user should follow and a check to see if the freeze has frozen any already started unlogged operation, should suffice. > I think the proposed patch looks good. Do you plan to add some test cases? I intend to add tests in http://issues.apache.org/jira/browse/Derby-3553. I was hoping to move to installation of jars and look at what will be required there and then move to writing tests for unlogged operations. > * LogToFile#replicationLogUnlogged: This method returns whether db is in > master > mode or not, and I think inReplicationMasterMode or something would be a > better name. > (The way the javadoc is written, it may lead you to think that you should > call this method to > activate logging.) Changed the method name to inReplicationMasterMode(). I also changed the javadoc to the following * Used to determine if the replication master mode has been started, * and the logging for unlogged operations needs to be enabled. > * messages.xml: I would say 'cannot be started' , not 'booted' since the > operation is called > startMaster.' Changed 'booted' to 'started'. > Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > -- > > Key: DERBY-3551 > URL: https://issues.apache.org/jira/browse/DERBY-3551 > Project: Derby > Issue Type: Sub-task > Components: Replication >Affects Versions: 10.4.0.0, 10.5.0.0 >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: Derby3551_1.diff, Derby3551_1.stat, Derby3551_2.diff, > Derby3551_2.stat, Derby3551_3.diff, Derby3551_3.stat, runscript_import.sql > > > Jorgen says- > I suggest that the replication step in which the master database is frozen is > replaced by a new system procedure to solve index and import: > Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE() > New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() > The new system procedure should: > 1) Freeze the database > 2) Check if there are any ongoing transactions with unlogged operations. If > so - unfreeze and abort. Otherwise: > 3) Enable logging of unlogged operations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
