Re: Build failed in Jenkins: Derby-trunk #2428

[Rick Hillegas]

On 1/28/16 6:55 AM, Knut Anders Hatlen wrote:

Apache Jenkins Server  writes:


[trunk] $ /home/jenkins/tools/ant/latest/bin/ant clobber all buildjars
Buildfile:

clean:

cleangenerated:

cleanstate:

cleanreleasefiles:

clobber:

checkCompilerLevel:

checkVMLevel:

prebuild:
 [mkdir] Created 
dir:

compile:
 [javac] Compiling 2 source files 
to

build:

setCompilerProperties:

init:

junit_check:

BUILD FAILED
:66: The 
following error occurred while executing this line:
:177: junit property is 
set to  but 
there is no junit.jar there.

Looks like automatic download of junit.jar is broken. I've filed
https://issues.apache.org/jira/browse/DERBY-6860 to track it.

For now, I've reconfigured the build job to run the install_junit target
manually to download junit.jar.


Thanks for tracking this down, Knut.

Cheers,
-Rick

[jira] [Commented] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7

[Rick Hillegas (JIRA)]

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

Rick Hillegas commented on DERBY-6857:
--

This means that DRDAConstants and friends will NOT appear in the Derby jar 
files. So it should cause your Windows builds to once again agree with the 
checked-in rosters of jar-file contents. I can imagine that there might be 
sealing problems if one of these files of constants leaked into multiple jar 
files--which I think is what you are seeing.

I will need your help to verify that the build works smoothly for you on 
Windows after I check in the improvement to classlister. Thanks!

> Deprecate support for building Derby under JDKs 6 and 7
> ---
>
> Key: DERBY-6857
> URL: https://issues.apache.org/jira/browse/DERBY-6857
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>Reporter: Rick Hillegas
> Attachments: ClassReferenceReader.java, Windows-sane-TypeId.class, 
> classReferenceComparison.txt, derby-6857-01-aa-remove6and7.diff, 
> derby-6857-02-aa-cleanupOldJdks.diff, derby-6857-03-aa-minimumVersion.diff, 
> jardriftcheck.diff, mac-derby-jar-verbose.txt, mac-sane-TypeId.class, 
> windows-derby-jar-verbose.txt
>
>
> The community voted to stop supporting Java 6 and 7 as of release 10.13. See 
> the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no 
> longer need to support building Derby with those JDKs. This issue tracks 
> changes needed to remove that support and simplify the build.



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

[Java DB - testing] Error nightly trunk (rev 1727230)

[ingemar . aberg]

Java DB testing and reporting infrastructure.

Error nightly trunk (rev 1727230)

There were execution errors and/or timeouts.
There were at least 60 failures.

[jira] [Commented] (DERBY-6858) Apache Derby simple update statement performance becomes 1500% worse when adding one byte to a column

[somebody (JIRA)]

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

somebody commented on DERBY-6858:
-

The deferrable constraint is needed by my program and regardless, I would think 
you would want this issue fixed as most modern databases support deferrable 
constraints.  I would hope you would want to optimize deferrable constrains 
otherwise they have no use since in this simple small database it causes such a 
huge performance loss and thus makes them almost completely useless.

Again I do need this feature for my app so disabling it is not an option.  
However, if it helps you debug the issue and you think there is value in 
running it against older versions of derby then you can simply modify the file 
I gave you and before doing the update on ChildUpdate, insert another record 
into ParentUpdate with the same values as was there before, except just change 
'Parent 1' to 'Parent 2' for the new record, then do the update, then delete 
ParentUpdate with name 'Parent 1'.  I don't have time to update the app now, 
but this is a simple change you can make so you aren't held back in your 
debugging and fixing.

I don't know if doing the above will have the same performance loss, but that 
is part of the debugging.  If you try my above suggestion and you don't see a 
performance loss, then you know it's likely the deferred constrains that needs 
optimizing.  If you do see the performance decrease then that will also yield 
information.

I suggest you make the above changes yourself as I don't have time now to make 
the changes, but I will help in the future with what I can as usual.

> Apache Derby simple update statement performance becomes 1500% worse when 
> adding one byte to a column
> -
>
> Key: DERBY-6858
> URL: https://issues.apache.org/jira/browse/DERBY-6858
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.11.1.1, 10.12.1.1
> Environment: windows 7 64 bit
>Reporter: somebody
>Priority: Blocker
> Attachments: repro.java, repro.java
>
>
> I have 2 tables as follows:
> ParentUpdate
> name varchar(255)
> value int not null
> primary key: name
> ChildUpdate
> parentName varchar(255)
> name varchar(255)
> value int
> data varchar(1000)
> primary key: name foreign key: parentName to ParentUpdate.name
> When I run the statement "update ChildUpdate set parentName = 'Parent 2' 
> where parentName = 'Parent 1'" with 2500 records in the ChildUpdate table and 
> 1 record in the ParentUpdate table with only a single byte difference in data 
> size in the ChildUpdate table, the performance decreases by 15 times.
> When the ChildUpdate data column has exactly 14 bytes of the same character 
> the runtime of the above query is about 500 milliseconds. When I add one more 
> byte to the data column of ChildUpdate the performance all of a sudden 
> becomes about 7500 milliseconds.
> If i then decrease the data size back to 14 from 15 it's fast again. When i 
> put it back to 15 it's slow again. This is reproducible every time.
> Can you please help me figure out how to get the same fast performance 
> without such seemingly random behaviour.
> The query plans are below for both cases.
> projection = true
> constructor time (milliseconds) = 0
> open time (milliseconds) = 0
> next time (milliseconds) = 16
> close time (milliseconds) = 16
> restriction time (milliseconds) = 0
> projection time (milliseconds) = 0
> optimizer estimated row count: 51.50
> optimizer estimated cost: 796.12
> Source result set:
> Table Scan ResultSet for CHILDUPDATE at read committed isolation 
> level using exclusive row locking chosen by the optimizer
> Number of opens = 1
> Rows seen = 2500
> Rows filtered = 0
> Fetch Size = 1
> constructor time (milliseconds) = 0
> open time (milliseconds) = 15
> next time (milliseconds) = 16
> close time (milliseconds) = 16
> next time in milliseconds/row = 0
> scan information:
> Bit set of columns fetched={0, 1}
> Number of columns fetched=2
> Number of pages visited=41
> Number of rows qualified=2500
> Number of rows visited=2500
> Scan type=heap
> start position:
> null
> stop position:
> null
> qualifiers:
> Column[0][0] Id: 0
> Operator: =
> Ordered nulls: false
>  

[jira] [Commented] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7

[Bryan Pendleton (JIRA)]

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

Bryan Pendleton commented on DERBY-6857:


I ran a fairly random set of tests on my latest build, and nothing showed up
that contained any hint of a class-packaging problem, so your patch
seems like good news to me.

> Deprecate support for building Derby under JDKs 6 and 7
> ---
>
> Key: DERBY-6857
> URL: https://issues.apache.org/jira/browse/DERBY-6857
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>Reporter: Rick Hillegas
> Attachments: ClassReferenceReader.java, Windows-sane-TypeId.class, 
> classReferenceComparison.txt, derby-6857-01-aa-remove6and7.diff, 
> derby-6857-02-aa-cleanupOldJdks.diff, derby-6857-03-aa-minimumVersion.diff, 
> derby-6857-04-aa-pruneConstantClasses.diff, jardriftcheck.diff, 
> mac-derby-jar-verbose.txt, mac-sane-TypeId.class, 
> windows-derby-jar-verbose.txt
>
>
> The community voted to stop supporting Java 6 and 7 as of release 10.13. See 
> the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no 
> longer need to support building Derby with those JDKs. This issue tracks 
> changes needed to remove that support and simplify the build.



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

Build failed in Jenkins: Derby-trunk #2429

[Apache Jenkins Server]

See 

--
[...truncated 1027 lines...]

sanitynameinsane:

setsanityname:

getsvnversion:
 [echo] Revision number set to 1727369.

initjars:

checkVMLevel:

derbyjar:
 [echo] Beginning derby.jar sane build
 [echo]  creating derby.jar class list 
 [echo]  creating new DBMS.properties file

infowriter:
[propertyfile] Updating property file: 


meta-inf-common:
 [copy] Copying 2 files to 


declare-autoloadable-driver:

make-core-derbyjar-manifest:

make-locale-classpath-manifest:
  [jar] Building jar: 


derbytoolsjar:
 [echo] Beginning derbytools.jar sane build
 [echo]  creating tools.list 
 [echo]  creating new tools.properties file 

infowriter:
[propertyfile] Updating property file: 


meta-inf-common:
 [copy] Copying 2 files to 


make-locale-classpath-manifest:
   [delete] Deleting: 

  [jar] Building jar: 


derbynetjar:
 [echo] Beginning derbynet.jar sane build
 [echo]  creating net.list
 [echo]  creating new net.properties file 

infowriter:
[propertyfile] Updating property file: 


meta-inf-common:
 [copy] Copying 2 files to 

   [delete] Deleting: 

  [jar] Building jar: 


derbyclientjar:
 [echo] Beginning derbyclient.jar sane build
 [copy] Copying 1 file to 


derbyclientjar.1.8:
 [echo]  creating new dnc.properties file 

infowriter:
[propertyfile] Updating property file: 


meta-inf-common:
 [copy] Copying 2 files to 


make-core-derbyjar-manifest:

make-locale-classpath-manifest:

declare-autoloadable-driver:
   [delete] Deleting: 

  [jar] Building jar: 


derbyoptionaltoolsjar:
 [echo] Beginning derbyoptionaltools.jar sane build
 [echo]  creating new tools.properties file 

infowriter:
[propertyfile] Creating new property file: 


meta-inf-common:
 [copy] Copying 2 files to 


make-locale-classpath-manifest:
   [delete] Deleting: 

  [jar] Building jar: 


derbyrunjar:
 [echo] Beginning derbyrun.jar build

meta-inf-common:
 [copy] Copying 2 files to 

  [jar] Updating jar: 


derbywar:
 [echo] Beginning derby.war  build
   [delete] Deleting: 

  [zip] Building zip: 


derbylocalejars:

meta-inf-common:
 [copy] Copying 2 files to 


localejar:
 [echo] Building derbyLocale_cs.jar

localeinfowriter:
[propertyfile] Updating property file: 

  [jar] Building jar: 


localejar:
 [echo] Building derbyLocale_de_DE.jar

localeinfowriter:
[propertyfile] Updating property file: 

  [jar] Building jar: 


localejar:
 

[jira] [Created] (DERBY-6860) Automatic download of junit.jar broken

[Knut Anders Hatlen (JIRA)]

Knut Anders Hatlen created DERBY-6860:
-

 Summary: Automatic download of junit.jar broken
 Key: DERBY-6860
 URL: https://issues.apache.org/jira/browse/DERBY-6860
 Project: Derby
  Issue Type: Bug
  Components: Build tools
Affects Versions: 10.13.0.0
Reporter: Knut Anders Hatlen


Automatic download of junit.jar seems to be broken. If you don't already have a 
copy in tools/java, "ant all" fails like this:

{noformat}
junit_check:

BUILD FAILED
/code/derby/trunk/build.xml:66: The following error occurred while executing 
this line:
/code/derby/trunk/build.xml:177: junit property is set to 
/code/derby/trunk/tools/java/junit.jar, but there is no junit.jar there.
{noformat}

The problem seems to be that junit_check refuses to continue if the junit 
property is set, but does not point to an existing file. This property is set 
when the setCompilerProperties target, which runs before junit_check, loads 
tools/ant/properties/extrapath.properties, as extrapath.properties contains the 
following line:

{noformat}
junit=${javatools.dir}/junit.jar
{noformat}

Since the install_junit target depends on the check_junit target, this prevents 
the build script from downloading junit.jar automatically.

Workaround: run "ant install_junit" before "ant all"



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

[jira] [Updated] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7

[Rick Hillegas (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Hillegas updated DERBY-6857:
-
Attachment: derby-6857-04-aa-pruneConstantClasses.diff

Attaching derby-6857-04-aa-pruneConstantClasses.diff. This patch removes 
DRDAConstants, SanityState, and ReleaseProperties from the list of files which 
the classlister program considers for inclusion in the Derby jar files. I will 
run regression tests just to be safe.

I copied the Windows compiled version of TypeId.class (supplied by Bryan) into 
my classes directory and verified the following:

1) Without this patch, the jar file checker complains that an extra class 
(DRDAConstants) has turned up in derby.jar.

2) With this patch, the jar file checker does not complain.

Bryan, could you verify whether this patch fixes the problem which you are 
seeing on Windows?


Touches the following file:

M   java/build/org/apache/derbyBuild/classlister.java


> Deprecate support for building Derby under JDKs 6 and 7
> ---
>
> Key: DERBY-6857
> URL: https://issues.apache.org/jira/browse/DERBY-6857
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>Reporter: Rick Hillegas
> Attachments: ClassReferenceReader.java, Windows-sane-TypeId.class, 
> classReferenceComparison.txt, derby-6857-01-aa-remove6and7.diff, 
> derby-6857-02-aa-cleanupOldJdks.diff, derby-6857-03-aa-minimumVersion.diff, 
> derby-6857-04-aa-pruneConstantClasses.diff, jardriftcheck.diff, 
> mac-derby-jar-verbose.txt, mac-sane-TypeId.class, 
> windows-derby-jar-verbose.txt
>
>
> The community voted to stop supporting Java 6 and 7 as of release 10.13. See 
> the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no 
> longer need to support building Derby with those JDKs. This issue tracks 
> changes needed to remove that support and simplify the build.



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

[jira] [Commented] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7

[Bryan Pendleton (JIRA)]

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

Bryan Pendleton commented on DERBY-6857:


Yes, with the pruneConstantClasses diff applied, I no longer see 
the jardriftcheck errors when building jars on my Windows system. Cool!

I'll try running some tests (I don't have the fastest system, sigh), and let 
you know
if any runtime errors appear to arise.

But in the meantime, your patch looks good to me.

> Deprecate support for building Derby under JDKs 6 and 7
> ---
>
> Key: DERBY-6857
> URL: https://issues.apache.org/jira/browse/DERBY-6857
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.13.0.0
>Reporter: Rick Hillegas
> Attachments: ClassReferenceReader.java, Windows-sane-TypeId.class, 
> classReferenceComparison.txt, derby-6857-01-aa-remove6and7.diff, 
> derby-6857-02-aa-cleanupOldJdks.diff, derby-6857-03-aa-minimumVersion.diff, 
> derby-6857-04-aa-pruneConstantClasses.diff, jardriftcheck.diff, 
> mac-derby-jar-verbose.txt, mac-sane-TypeId.class, 
> windows-derby-jar-verbose.txt
>
>
> The community voted to stop supporting Java 6 and 7 as of release 10.13. See 
> the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no 
> longer need to support building Derby with those JDKs. This issue tracks 
> changes needed to remove that support and simplify the build.



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

Re: Build failed in Jenkins: Derby-trunk #2428

[Knut Anders Hatlen]

Apache Jenkins Server   writes:

> [trunk] $ /home/jenkins/tools/ant/latest/bin/ant clobber all buildjars
> Buildfile: 
>
> clean:
>
> cleangenerated:
>
> cleanstate:
>
> cleanreleasefiles:
>
> clobber:
>
> checkCompilerLevel:
>
> checkVMLevel:
>
> prebuild:
> [mkdir] Created dir: 
> 
>
> compile:
> [javac] Compiling 2 source files to 
> 
>
> build:
>
> setCompilerProperties:
>
> init:
>
> junit_check:
>
> BUILD FAILED
> :66: The 
> following error occurred while executing this line:
> :177: junit 
> property is set to 
>  
> but there is no junit.jar there.

Looks like automatic download of junit.jar is broken. I've filed
https://issues.apache.org/jira/browse/DERBY-6860 to track it.

For now, I've reconfigured the build job to run the install_junit target
manually to download junit.jar.

-- 
Knut Anders