Re: Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net

[Rory O'Donnell]

Thanks for the update Rick!

Rgds,Rory

On 19/04/2016 04:29, Rick Hillegas wrote:

On 4/15/16 1:24 AM, Rory O'Donnell wrote:


Hi Rick,

Early Access b113  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.


Early Access b113  (#4664) for JDK 9 
with Project Jigsaw is available on java.net.


  * The important change in this build is that root modules when
compiling code in the unnamed module, or when running and the
main class is loaded from the class path, do not include the EE
modules. More on this in JEP 261.
  * The other change in this build is that the -Xpatch option is now
aligned with what we have documented in JEP 261, support for the
old form has been removed.

We are very interested in hearing your experiences in testing any 
Early Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered 
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me 
or via the mailing lists [1], [2].


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland

Hi Rory,

I have taken both JDK's for a spin. With both JDKs, a JDK9-ready 
version of Derby builds and tests cleanly as discussed in the trailing 
comments here: https://issues.apache.org/jira/browse/DERBY-6856.


Note that this version of Derby does not exercise any new features 
(including jigsaw) which are introduced by these JDKs.


Thanks,
-Rick


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

RE: Is there any debug logging available when a database is being recovered

[Bergquist, Brett]

It took longer (and never finished) to process the recovery logs file that it 
did to restore the database from the previous night from backup (that took 6 
hours to "untar")   At about 14 hours, the recovery log files were not finished 
processing so we had to give up and restore from backup.   That seems quite an 
inordinate amount of time to process the recovery log files.Note that this 
was not an underpowered machine either.   It was an Oracle M5000 with 32 
processors, 128G of memory, and Fibre Channel attached storage.

I would like to start looking at this, so if anyone has any ideas where to 
begin, shout them out.

-Original Message-
From: Bryan Pendleton [mailto:bpendleton.de...@gmail.com]
Sent: Wednesday, April 20, 2016 5:53 AM
To: derby-dev@db.apache.org
Subject: Re: Is there any debug logging available when a database is being 
recovered

> So what would be useful would be something like:
>
> Performing database recovery
> Starting analysis pass
> 215 transactions detected to be processed Starting redo pass 
> anything that could give some feedback Starting undo pass anything
> that could give some feedback
>

I'm afraid all I can add is: yes, I completely agree, that would be extremely 
useful.

bryan



Canoga Perkins
20600 Prairie Street
Chatsworth, CA 91311
(818) 718-6300

This e-mail and any attached document(s) is confidential and is intended only 
for the review of the party to whom it is addressed. If you have received this 
transmission in error, please notify the sender immediately and discard the 
original message and any attachment(s).

[jira] [Commented] (DERBY-6884) SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE bytes of blob data

[Bryan Pendleton (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15249904#comment-15249904
 ] 

Bryan Pendleton commented on DERBY-6884:


With the patch applied, I ran the tools test suite, and there were no failures.

This suggests that a simple path forward might be:
1) Convert the repro into a new test case in ImportExportLobTest.java
2) Commit the new test case, and the trivial diff

I do worry that there may be other similar problems lurking though, so I
intend to (at least) produce a variant of the test case which uses a set of CLOB
columns rather than a set of BLOB columns, to check to see if there is a CLOB
variant of this job lurking.


> SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE 
> bytes of blob data
> 
>
> Key: DERBY-6884
> URL: https://issues.apache.org/jira/browse/DERBY-6884
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Edward Howe
> Attachments: DerbyIssue.java, trivial.diff
>
>
> Using SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE to export a table containing a blob 
> column, SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE  will fail with a 
> NumberFormatException if the offset for a blob record is > Integer.MAX_VALUE. 
>  This is because ImportReadData.initExternalLobFile() is parsing the offset 
> as an Integer.
> The stack trace and a program to reproduce are below.
> java.lang.NumberFormatException: For input string: "2147483770"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:583) ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_45]
>   at 
> org.apache.derby.impl.load.ImportReadData.initExternalLobFile(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.load.ImportReadData.getBlobColumnFromExtFile(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.ImportAbstract.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.Import.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.iapi.types.SQLBlob.setValueFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   ... 36 common frames omitted
> ==
> package blob;
> import java.io.BufferedInputStream;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.IOException;
> import java.sql.*;
> public final class DerbyIssue {
> // derby url
> public static final String DBURL = "jdbc:derby:testdb;create=true";
> // any random binary file such as a large image or document
> public static final String BLOB_DATA_FILE = "...";
> public static final String EXPORT_TABLE_FILE = "table-data";
> public static final String EXPORT_BLOB_FILE = "blob-data";
> public static void main(String... args) throws Exception {
> final DerbyIssue test = new DerbyIssue();
> test.run();
> }
> public void run() throws Exception {
> 
> 

[jira] [Commented] (DERBY-6882) Add functionality to ALTER TABLE: switch from GENERATED ALWAYS to GENERATED BY DEFAULT

[Aleksei Kovura (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15249709#comment-15249709
 ] 

Aleksei Kovura commented on DERBY-6882:
---

Hi Rick,
I didn't find any other workaround, so please port it. Thanks!

> Add functionality to ALTER TABLE: switch from GENERATED ALWAYS to GENERATED 
> BY DEFAULT
> --
>
> Key: DERBY-6882
> URL: https://issues.apache.org/jira/browse/DERBY-6882
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.12.1.1
>Reporter: Aleksei Kovura
>Assignee: Rick Hillegas
>  Labels: features
> Attachments: derby-6882-01-aa-initialCode.diff, 
> derby-6882-01-bb-withTests.diff
>
>
> I'm trying to import data from another Derby database with foreignViews tool 
> because system tables got corrupted somehow (see 
> https://issues.apache.org/jira/browse/DERBY-6876). Tables contain generated 
> ID columns (created as "GENERATED ALWAYS"). Importing data and allowing Derby 
> to generate new IDs in generated columns will break relationships between 
> tables (old tables have counter gaps there due to deletes - IDs won't match).
> For a clean import without breaking DDL information in DB version control I 
> would like to be able to switch between generated types as follows:
>  
> ALTER TABLE table1 ALTER COLUMN col1 SET GENERATED BY DEFAULT [ AS IDENTITY]
> ALTER TABLE table1 ALTER COLUMN col1 SET GENERATED ALWAYS [ AS IDENTITY]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Is there any debug logging available when a database is being recovered

[Bryan Pendleton]

So what would be useful would be something like:

Performing database recovery
Starting analysis pass
215 transactions detected to be processed
Starting redo pass
…. anything that could give some feedback
Starting undo pass
….anything that could give some feedback



I'm afraid all I can add is: yes, I completely agree, that
would be extremely useful.

bryan