[jira] Commented: (DERBY-3322) Server guide refers to phantom property in template policy file for the Network Server

[John H. Embretsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577335#action_12577335
 ] 

John H. Embretsen commented on DERBY-3322:
--

I can't see the changes made by DERBY-3442 at 
http://db.apache.org/derby/docs/dev/ref/rrefsqlj37836.html either, committed 
March 03. Something happened to the copying process between ~mid-February and 
then?

> Server guide refers to phantom property in template policy file for the 
> Network Server
> --
>
> Key: DERBY-3322
> URL: https://issues.apache.org/jira/browse/DERBY-3322
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 10.3.1.4, 10.3.2.1
> Environment: N/A
>Reporter: John H. Embretsen
>Assignee: John H. Embretsen
>Priority: Trivial
> Fix For: 10.4.0.0
>
> Attachments: d3322v01.diff, tadminnetservcustom.html
>
>
> The Server and Administration guide contains a section about customizing the 
> Network Server's security policy, based on the template policy:
> http://db.apache.org/derby/docs/dev/adminguide/tadminnetservcustom.html
> This section mentions that the variable ${derby.security.host} should be 
> replaced with a suitable value.
>  
> However, the template policy, at /demo/templates/server.policy (released 
> binaries) or java/drda/org/apache/derby/drda/template.policy (SVN codeline), 
> does not refer to any variable or property called ${derby.security.host}. 
> Instead, the policy file specifies the wildcard address, with appropriate 
> comments:
> 
> // Accept connections from any host. Derby is listening to the host
> // interface specified via the -h option to "NetworkServerControl
> // start" on the command line, via the address parameter to the
> // org.apache.derby.drda.NetworkServerControl constructor in the API
> // or via the property derby.drda.host; the default is localhost.
> // You may want to restrict allowed hosts, e.g. to hosts in a specific
> // subdomain, e.g. "*.acme.com".
>   permission java.net.SocketPermission "*", "accept";
> 
> See also 
> http://www.nabble.com/Customizing-the-Network-Server%27s-security-policy-%28docs-vs.-reality%29-td14841290.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-3447) Shutdown on a database without stopping replication hangs

[JIRA]

[ 
https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577345#action_12577345
 ] 

Øystein Grøvlen commented on DERBY-3447:


Hi, I tried the patch, but I still get I hang when I quit an ij that is running 
a master.
(Since MasterController has moved, I modified the path in the diff file before 
applying the patch.)
(I am runnig with classes.)

> Shutdown on a database without stopping replication hangs
> -
>
> Key: DERBY-3447
> URL: https://issues.apache.org/jira/browse/DERBY-3447
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
>Reporter: V.Narayanan
>Assignee: V.Narayanan
> Attachments: Derby3447_v1.diff, Derby3447_v1.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Junit hang

[Knut Anders Hatlen]

Rick Hillegas <[EMAIL PROTECTED]> writes:

> Thanks, Knut. Increasing the max PermGen size got the tests past the
> out-of-memory-error. They then hung on test case 8515 out of 8520, in
> org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1.
>  I
> interrupted the tests with "kill -quit" as you recommended. I'm
> attaching the console output.

Hi Rick,

>From looking at the output, I would guess that one of the replication
tests misses something in the clean-up, and that makes subsequent
replication tests fail or hang.

I think Øystein disabled those tests in revision 635575. Do you still
see the hang after updating your source tree?

By the way, is it normal that a single process has seven threads named
derby.AntiGC? Does that mean that there are seven instances of the
embedded driver in the same JVM?

-- 
Knut Anders

Re: Preparing to cut the 10.4 branch

[Dyre . Tjeldvoll]

Daniel John Debrunner <[EMAIL PROTECTED]> writes:

> Rick Hillegas wrote:
>
>> When I run sysinfo against the branch, it reports that the version
>> id is "10.4.0.1 alpha - (635685)". It think that you need to modify
>> the 3rd digit in the release id. I believe that is the secret
>> handshake which turns an alpha into a beta.
>
> The "secret handshake" is documented here:
>
>   http://db.apache.org/derby/papers/versionupgrade.html

I'm sorry, but this is utterly confusing to me.
 
tools/ant/properties/release.properties contains a property called 
'beta' that can either be 'true' or 'false'

The wiki page (http://wiki.apache.org/db-derby/DerbySnapshotOrRelease)
talks about the 'beta flag'.

You are saying that the 'beta flag' does not refer to the previously
mentioned property, but to whether or not the 3rd digit of the version
number (the fixpack number) is 0 or not?

So when, if ever, do you modify the beta property?

On the Wiki page the process of bumping the fixpack number appears to be
described in the section called 'Check-ins just before generating
release artifacts". 

But I might as well do it now, is that what you're saying?


-- 
dt

[jira] Commented: (DERBY-3447) Shutdown on a database without stopping replication hangs

[V.Narayanan (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577348#action_12577348
 ] 

V.Narayanan commented on DERBY-3447:


>Hi, I tried the patch, but I still get I hang when I quit an ij that is 
>running a master.

You just did a quit; and it hanged? Surprising the repro worked for me. I will 
check this.

>(Since MasterController has moved, I modified the path in the diff file before 
>applying the patch.)

Just modified the file names in the diff?

>(I am runnig with classes.)

Would this be different from running with the jars?

> Shutdown on a database without stopping replication hangs
> -
>
> Key: DERBY-3447
> URL: https://issues.apache.org/jira/browse/DERBY-3447
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
>Reporter: V.Narayanan
>Assignee: V.Narayanan
> Attachments: Derby3447_v1.diff, Derby3447_v1.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Preparing to cut the 10.4 branch

[Dyre . Tjeldvoll]

[EMAIL PROTECTED] writes:

> Daniel John Debrunner <[EMAIL PROTECTED]> writes:
>
>> Rick Hillegas wrote:
>>
>>> When I run sysinfo against the branch, it reports that the version
>>> id is "10.4.0.1 alpha - (635685)". It think that you need to modify
>>> the 3rd digit in the release id. I believe that is the secret
>>> handshake which turns an alpha into a beta.
>>
>> The "secret handshake" is documented here:
>>
>>   http://db.apache.org/derby/papers/versionupgrade.html
>
> I'm sorry, but this is utterly confusing to me.
>  
> tools/ant/properties/release.properties contains a property called 
> 'beta' that can either be 'true' or 'false'
>
> The wiki page (http://wiki.apache.org/db-derby/DerbySnapshotOrRelease)
> talks about the 'beta flag'.
>
> You are saying that the 'beta flag' does not refer to the previously
> mentioned property, but to whether or not the 3rd digit of the version
> number (the fixpack number) is 0 or not?
>
> So when, if ever, do you modify the beta property?
>
> On the Wiki page the process of bumping the fixpack number appears to be
> described in the section called 'Check-ins just before generating
> release artifacts". 
>
> But I might as well do it now, is that what you're saying?

I did some experimenting, and here are the results:
Alt A: 
With maint=001 and beta=true
10.4.0.1 alpha - (635861)

Alt B:
With maint=001 and beta=false
10.4.0.1 alpha - (635861M)

Alt C:
With maint=101 and beta=true
10.4.1.1 beta - (635861M)

Alt D:
With maint=101 and beta=false
10.4.1.1 - (635861M)

So I thought alt. A was correct for the period from when the branch is
cut up to the point when the first RC is spun (targetted for
2008-04-04), alt. C for the RC and alt. D for the final release.

But based on the comments I take it that I should go immediately to alt.
C, and that alt. D should be used for the RC. If someone confirms this
I can check in the change to release.properties and update the Wiki.

Thanks,

-- 
dt

Re: Not able to get in-place compression to release space to file system

[Øystein Grøvlen]

Øystein Grøvlen wrote:


I have been experimenting a bit with in-place compression on a large
table, but I have not been successful in getting it to give back space
to the file system.  I have table that I have done a lot of bulk
changes to over time.  It is now much smaller than it was at its peak
size, but I am not able to reduce the size of the corresponding files
by in-place compression.  My last attempt:


I have now deleted all records in the table, but inplace compress does 
still not release any pages:


ij> select conglomeratename, isindex, numallocatedpages, numfreepages, 
pagesize, estimspacesaving from new 
org.apache.derby.diag.SpaceTable('T') t order by conglomeratename;
CONGLOMERATENAME 

|ISIND&|NUMALLOCATEDPAGES   |NUMFREEPAGES|PAGESIZE 
|ESTIMSPACESAVING

--
T 
|0 |1 
 |419741  |4096   |1719259136
X_I 
|1 |131 
 |20105   |4096   |82350080


2 rows selected


--
Øystein

[jira] Updated: (DERBY-3352) truncateTable crashed, Caused by: java.lang.NullPointerException

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-3352:
--

Derby Info: [Regression]

The NullPointerException seems to have been introduced in this commit:


r528033 | mikem | 2007-04-12 18:58:30 +0200 (Thu, 12 Apr 2007) | 6 lines

DERBY-2537, 1st incremental checking for this issue.  This changes builds
the framework for storing/retrieving the collation metadata in store and for
passing that info down from language into store.  Some paths still have
default collation hard coded and have been marked TODO-COLLATION.




> truncateTable crashed, Caused by: java.lang.NullPointerException
> 
>
> Key: DERBY-3352
> URL: https://issues.apache.org/jira/browse/DERBY-3352
> Project: Derby
>  Issue Type: Bug
>  Components: Services
>Affects Versions: 10.3.1.4, 10.3.2.1
> Environment: Windows XP.SP2 , Eclipse 3.2.2 , JDK 1.5_05 
>Reporter: QingpingXu
>Priority: Critical
>
> Since derby 10.3.2.1, when truncate a table which has index , a 
> java.lang.NullPointerException is throwed;but the same src runs successfully 
> with derby 10.2.2.0。
> here's the example source code and stack trace:
> Src:
> public static void main(String[] args)
>   {
>   
>   try
>   {
>   Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
>   
>   Connection conn = 
> DriverManager.getConnection("jdbc:derby:test;create=true");
>   
>   Statement stat = conn.createStatement();
>   stat.executeUpdate("create table m (uri varchar(256),f 
> int)");
>   stat.executeUpdate("create index aa on m (uri)");
>   stat.executeUpdate("truncate table m");
>   
>   System.out.println("Truncate table m successfully！");
>   }
>   catch (Exception ex)
>   {
>   ex.printStackTrace();
>   }
>   }
> Error:
> java.sql.SQLException: Java Exception:":java.lang.NullPointerException"。
>   at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
>   at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88)
>   at org.apache.derby.impl.jdbc.Util.javaException(Util.java:245)
>   at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
>   at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
>   at 
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1574)
>   at 
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
>   at 
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1315)
>   at 
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:618)
>   at 
> org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:176)
>   at update.UpdateURI.main(UpdateURI.java:34)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.derby.impl.sql.execute.AlterTableConstantAction.truncateTable(AlterTableConstantAction.java:1462)
>   at 
> org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(AlterTableConstantAction.java:531)
>   at 
> org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:64)
>   at 
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:370)
>   at 
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1225)
>   ... 3 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3447) Shutdown on a database without stopping replication hangs

[JIRA]

[ 
https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577393#action_12577393
 ] 

Øystein Grøvlen commented on DERBY-3447:


It works for me if I turn off authentication and SQL authorization.


> Shutdown on a database without stopping replication hangs
> -
>
> Key: DERBY-3447
> URL: https://issues.apache.org/jira/browse/DERBY-3447
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
>Reporter: V.Narayanan
>Assignee: V.Narayanan
> Attachments: Derby3447_v1.diff, Derby3447_v1.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Preparing to cut the 10.4 branch

[Knut Anders Hatlen]

[EMAIL PROTECTED] writes:

> I did some experimenting, and here are the results:
> Alt A: 
> With maint=001 and beta=true
> 10.4.0.1 alpha - (635861)
>
> Alt B:
> With maint=001 and beta=false
> 10.4.0.1 alpha - (635861M)
>
> Alt C:
> With maint=101 and beta=true
> 10.4.1.1 beta - (635861M)
>
> Alt D:
> With maint=101 and beta=false
> 10.4.1.1 - (635861M)
>
> So I thought alt. A was correct for the period from when the branch is
> cut up to the point when the first RC is spun (targetted for
> 2008-04-04), alt. C for the RC and alt. D for the final release.

The release candidate should not have the beta flag. As long as it has
the beta flag it can't be released and therefore cannot be a candidate
for release... :)

> But based on the comments I take it that I should go immediately to alt.
> C, and that alt. D should be used for the RC. If someone confirms this
> I can check in the change to release.properties and update the Wiki.

Sounds reasonable to me. Although I had expected the last digit to be 0,
not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember).

-- 
Knut Anders

[jira] Commented: (DERBY-3447) Shutdown on a database without stopping replication hangs

[V.Narayanan (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577389#action_12577389
 ] 

V.Narayanan commented on DERBY-3447:


I am not able to reproduce this problem on both embedded and network/client

Network Client

[EMAIL PROTECTED]:~/work/workspaces/Derby3447_1/master$ java 
org.apache.derby.tools.ij
ij version 10.5
ij> connect 'jdbc:derby://localhost:1527/replicationdb';
ij> connect 
'jdbc:derby://localhost:1527/replicationdb;startMaster=true;slaveHost=localhost;slavePort=8001';
ij(CONNECTION1)> quit;
[EMAIL PROTECTED]:~/work/workspaces/Derby3447_1/master$

Embedded

[EMAIL PROTECTED]:~/work/workspaces/Derby3447_1/master$ java 
org.apache.derby.tools.ij
ij version 10.5
ij> connect 'jdbc:derby:masterDB;user=oystein;password=pass;create=true';
ij> call SYSCS_UTIL.SYSCS_FREEZE_DATABASE(); 
0 rows inserted/updated/deleted
ij> connect 
'jdbc:derby:masterDB;user=oystein;password=pass;startMaster=true;slaveHost=localhost;slavePort=8001';
ij(CONNECTION1)> quit;
[EMAIL PROTECTED]:~/work/workspaces/Derby3447_1/master$ 

Can you pls re-run and confirm on the current workspace to see if this problem 
is occurring?

> Shutdown on a database without stopping replication hangs
> -
>
> Key: DERBY-3447
> URL: https://issues.apache.org/jira/browse/DERBY-3447
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
>Reporter: V.Narayanan
>Assignee: V.Narayanan
> Attachments: Derby3447_v1.diff, Derby3447_v1.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Preparing to cut the 10.4 branch

[Dyre . Tjeldvoll]

Knut Anders Hatlen <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] writes:
>
>> I did some experimenting, and here are the results:
>> Alt A: 
>> With maint=001 and beta=true
>> 10.4.0.1 alpha - (635861)
>>
>> Alt B:
>> With maint=001 and beta=false
>> 10.4.0.1 alpha - (635861M)
>>
>> Alt C:
>> With maint=101 and beta=true
>> 10.4.1.1 beta - (635861M)
>>
>> Alt D:
>> With maint=101 and beta=false
>> 10.4.1.1 - (635861M)
>>
>> So I thought alt. A was correct for the period from when the branch is
>> cut up to the point when the first RC is spun (targetted for
>> 2008-04-04), alt. C for the RC and alt. D for the final release.
>
> The release candidate should not have the beta flag. As long as it has
> the beta flag it can't be released and therefore cannot be a candidate
> for release... :)
>
>> But based on the comments I take it that I should go immediately to alt.
>> C, and that alt. D should be used for the RC. If someone confirms this
>> I can check in the change to release.properties and update the Wiki.
>
> Sounds reasonable to me. Although I had expected the last digit to be 0,
> not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember).

I don't know why it shouldn't be 0. But following the old instructions
on the Wiki (either by running maintversion2props directly, or by doing
ant bumplastdigit in tools/relase, which seems to be doing the same
thing) I ended up with the last digit being 1...

If it should in fact, be 0, then I have to ask that someone tells me
exaclty what to do, step by step, so that I can re-write the Wiki from
scratch...

-- 
dt

[jira] Updated: (DERBY-3382) Replication: Slave must inform master if DBs are out of sync.

[JIRA]

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

Jørgen Løland updated DERBY-3382:
-

Attachment: derby-3382-test-1a.diff
derby-3382-test-1a.stat

The attached patch contains a regression test for this issue.

> Replication: Slave must inform master if DBs are out of sync.
> -
>
> Key: DERBY-3382
> URL: https://issues.apache.org/jira/browse/DERBY-3382
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
>Reporter: Øystein Grøvlen
>Assignee: Jørgen Løland
> Fix For: 10.4.0.0
>
> Attachments: derby-3382-1a.diff, derby-3382-1a.stat, 
> derby-3382-1b.diff, derby-3382-1b.stat, derby-3382-test-1a.diff, 
> derby-3382-test-1a.stat
>
>
> If I copy the database to the slave before booting the master, slave will be 
> out of sync with the master since new log records are created during booting. 
>  The slave will then stop replication, but the master will not be notified.
> If I then try to stop or failover the master the master will hang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Preparing to cut the 10.4 branch

[Knut Anders Hatlen]

[EMAIL PROTECTED] writes:

> Knut Anders Hatlen <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] writes:
>>
>>> I did some experimenting, and here are the results:
>>> Alt A: 
>>> With maint=001 and beta=true
>>> 10.4.0.1 alpha - (635861)
>>>
>>> Alt B:
>>> With maint=001 and beta=false
>>> 10.4.0.1 alpha - (635861M)
>>>
>>> Alt C:
>>> With maint=101 and beta=true
>>> 10.4.1.1 beta - (635861M)
>>>
>>> Alt D:
>>> With maint=101 and beta=false
>>> 10.4.1.1 - (635861M)
>>>
>>> So I thought alt. A was correct for the period from when the branch is
>>> cut up to the point when the first RC is spun (targetted for
>>> 2008-04-04), alt. C for the RC and alt. D for the final release.
>>
>> The release candidate should not have the beta flag. As long as it has
>> the beta flag it can't be released and therefore cannot be a candidate
>> for release... :)
>>
>>> But based on the comments I take it that I should go immediately to alt.
>>> C, and that alt. D should be used for the RC. If someone confirms this
>>> I can check in the change to release.properties and update the Wiki.
>>
>> Sounds reasonable to me. Although I had expected the last digit to be 0,
>> not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember).
>
> I don't know why it shouldn't be 0. But following the old instructions
> on the Wiki (either by running maintversion2props directly, or by doing
> ant bumplastdigit in tools/relase, which seems to be doing the same
> thing) I ended up with the last digit being 1...
>
> If it should in fact, be 0, then I have to ask that someone tells me
> exaclty what to do, step by step, so that I can re-write the Wiki from
> scratch...

I haven't followed the steps on the wiki myself, but by reading it, it
seems like this is what should happen with the version numbers:

  1. After creating the branch, "ant bumplastdigit" (step 5 under
 "Prepare the community for a new release") will change the version
 from 10.4.0.0 to 10.4.0.1. This sounds OK as it will help us
 distinguish between 10.4 on the trunk and 10.4 on the branch.

  2. Before creating the first release candidate, update both the third
 and the fourth digit of the version number by updating the maint
 property in tools/ant/properties/release.properties, and set the
 beta property in the same file to false. After this step, the
 version number shuld be 10.4.1.0.

  3. Before creating subsequent release candidates, update the fourth
 digit (either by manually updating release.properties or by running
 "ant bumplastdigit"). After this step, the version number should be
 10.4.1.1, 10.4.1.2, ...

The wiki page does not distinguish between (2) and (3), it only says
this under "Check-ins just before generating release artifacts":

> Bump the version number, adjust the beta flag and check in the new
> version.
>
>  The third and fourth parts of the version are combined into a
>  single property, maint, where maint = (third digit * 100) +
>  fourth digit. Also, if this is a major/minor (feature) release,
>  you should remove the beta flag at this time. You should update
>  tools/ant/properties/release.properties by hand and then run:

So according to this paragraph, you should edit release.property by
hand, and then you can set maint to whichever number you'd like before
you run maintversion2props.

-- 
Knut Anders

Re: Preparing to cut the 10.4 branch

[Rick Hillegas]

[EMAIL PROTECTED] wrote:

Knut Anders Hatlen <[EMAIL PROTECTED]> writes:

  

[EMAIL PROTECTED] writes:



I did some experimenting, and here are the results:
Alt A: 
With maint=001 and beta=true

10.4.0.1 alpha - (635861)

Alt B:
With maint=001 and beta=false
10.4.0.1 alpha - (635861M)

Alt C:
With maint=101 and beta=true
10.4.1.1 beta - (635861M)

Alt D:
With maint=101 and beta=false
10.4.1.1 - (635861M)

So I thought alt. A was correct for the period from when the branch is
cut up to the point when the first RC is spun (targetted for
2008-04-04), alt. C for the RC and alt. D for the final release.
  

The release candidate should not have the beta flag. As long as it has
the beta flag it can't be released and therefore cannot be a candidate
for release... :)



But based on the comments I take it that I should go immediately to alt.
C, and that alt. D should be used for the RC. If someone confirms this
I can check in the change to release.properties and update the Wiki.
  

Sounds reasonable to me. Although I had expected the last digit to be 0,
not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember).



I don't know why it shouldn't be 0. But following the old instructions
on the Wiki (either by running maintversion2props directly, or by doing
ant bumplastdigit in tools/relase, which seems to be doing the same
thing) I ended up with the last digit being 1...

If it should in fact, be 0, then I have to ask that someone tells me
exaclty what to do, step by step, so that I can re-write the Wiki from
scratch...

  

Hi Dyre,

This part of our release process seems to trip up every new release 
manager and the instructions could use some improvement. My 
understanding of bumplastdigit is this: you run it after you generate a 
candidate and it sets up the release id for the next candidate. In any 
event, with or without bumping the last digit, option (C) produces a 
release id that looks good to me.


Thanks,
-Rick

[jira] Closed: (DERBY-3318) Missing clean-up after failed startMaster

[JIRA]

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

Jørgen Løland closed DERBY-3318.



> Missing clean-up after failed startMaster
> -
>
> Key: DERBY-3318
> URL: https://issues.apache.org/jira/browse/DERBY-3318
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
> Environment: Trunk on Solaris
>Reporter: Øystein Grøvlen
>
> It seems like some clean-up is missing if startMaster fails.  This
> happened when I tried to connect to a non-existing slave:
> > > java org.apache.derby.tools.ij
> ij version 10.4
> ij>  connect 'jdbc:derby:test;create=true';
> ij> connect 'jdbc:derby:test;startMaster=true;slaveHost=localhost';
> ERROR XRE04: Could not establish a connection to the peer of the replicated 
> database 'null'.
> ij> quit;
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.derby.impl.services.replication.master.MasterController.flushedTo(MasterController.java:278)
> at 
> org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:3953)
> at 
> org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:1762)
> at 
> org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1653)
> at 
> org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1469)
> at org.apache.derby.impl.store.raw.RawStore.stop(RawStore.java:363)
> at 
> org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:405)
> at 
> org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:349)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:235)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:201)
> at 
> org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:205)
> at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
> at java.sql.DriverManager.getConnection(DriverManager.java:582)
> at java.sql.DriverManager.getConnection(DriverManager.java:207)
> at 
> org.apache.derby.impl.tools.ij.utilMain.cleanupGo(utilMain.java:416)
> at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:249)
> at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)
> at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
> at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)
> at org.apache.derby.tools.ij.main(ij.java:59)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3318) Missing clean-up after failed startMaster

[JIRA]

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

Jørgen Løland resolved DERBY-3318.
--

Resolution: Duplicate
  Assignee: (was: Jørgen Løland)

> Missing clean-up after failed startMaster
> -
>
> Key: DERBY-3318
> URL: https://issues.apache.org/jira/browse/DERBY-3318
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
> Environment: Trunk on Solaris
>Reporter: Øystein Grøvlen
>
> It seems like some clean-up is missing if startMaster fails.  This
> happened when I tried to connect to a non-existing slave:
> > > java org.apache.derby.tools.ij
> ij version 10.4
> ij>  connect 'jdbc:derby:test;create=true';
> ij> connect 'jdbc:derby:test;startMaster=true;slaveHost=localhost';
> ERROR XRE04: Could not establish a connection to the peer of the replicated 
> database 'null'.
> ij> quit;
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.derby.impl.services.replication.master.MasterController.flushedTo(MasterController.java:278)
> at 
> org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:3953)
> at 
> org.apache.derby.impl.store.raw.log.LogToFile.flush(LogToFile.java:1762)
> at 
> org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1653)
> at 
> org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1469)
> at org.apache.derby.impl.store.raw.RawStore.stop(RawStore.java:363)
> at 
> org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:405)
> at 
> org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:349)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:235)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:201)
> at 
> org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:205)
> at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)
> at java.sql.DriverManager.getConnection(DriverManager.java:582)
> at java.sql.DriverManager.getConnection(DriverManager.java:207)
> at 
> org.apache.derby.impl.tools.ij.utilMain.cleanupGo(utilMain.java:416)
> at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:249)
> at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)
> at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
> at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)
> at org.apache.derby.tools.ij.main(ij.java:59)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-2911:
--

Attachment: d2911-12.diff

Attaching d2911-12.diff which addresses Øystein's comments 3a, 4a (indirectly, 
since that code was removed), 4b and 4f. It makes 
ReplacementPolicy.insertEntry() void since the return value is not used, it 
simplifies the handling of small caches in ClockPolicy.rotateClock(), and it 
factors out common code in ClockPolicy.rotateClock() and 
ClockPolicy.shrinkMe(). This patch is not supposed to change the behaviour in 
any way.

suites.All ran cleanly. I have also started derbyall and I will report back if 
it fails.

> Implement a buffer manager using java.util.concurrent classes
> -
>
> Key: DERBY-2911
> URL: https://issues.apache.org/jira/browse/DERBY-2911
> Project: Derby
>  Issue Type: Improvement
>  Components: Performance, Services
>Affects Versions: 10.4.0.0
>Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>Priority: Minor
> Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, 
> d2911-10.diff, d2911-10.stat, d2911-11.diff, d2911-12.diff, d2911-2.diff, 
> d2911-3.diff, d2911-4.diff, d2911-5.diff, d2911-6.diff, d2911-6.stat, 
> d2911-7.diff, d2911-7a.diff, d2911-9.diff, d2911-9.stat, d2911-enable.diff, 
> d2911-entry-javadoc.diff, d2911-unused.diff, d2911-unused.stat, 
> d2911perf.java, derby-2911-8.diff, derby-2911-8.stat, perftest.diff, 
> perftest.pdf, perftest.stat, perftest2.diff, perftest6.pdf, poisson_patch8.tar
>
>
> There are indications that the buffer manager is a bottleneck for some types 
> of multi-user load. For instance, Anders Morken wrote this in a comment on 
> DERBY-1704: "With a separate table and index for each thread (to remove latch 
> contention and lock waits from the equation) we (...) found that 
> org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 
> times more contention than the synchronization in LockSet.lockObject() and 
> LockSet.unlock(). That might be an indicator of where to apply the next push".
> It would be interesting to see the scalability and performance of a buffer 
> manager which exploits the concurrency utilities added in Java SE 5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3437) Give all replication threads meaningfull names

[JIRA]

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

Jørgen Løland closed DERBY-3437.



> Give all replication threads meaningfull names
> --
>
> Key: DERBY-3437
> URL: https://issues.apache.org/jira/browse/DERBY-3437
> Project: Derby
>  Issue Type: Improvement
>  Components: Newcomer, Replication
>Affects Versions: 10.4.0.0
>Reporter: Jørgen Løland
>Assignee: Serge Tsv
>Priority: Minor
> Fix For: 10.4.0.0
>
> Attachments: DERBY-3437-1.diff, DERBY-3437-1.stat, DERBY-3437.diff
>
>
> Some threads are created for replication purposes:
> * The log shipper thread on the master 
> (o.a.d.i.services.master.MasterController)
> * The database boot thread on the slave (o.a.d.i.db.SlaveDatabase)
> * The log receiver thread on the slave 
> (o.a.d.i.services.slave.SlaveController)
> These threads should be given names to simplify debugging.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3437) Give all replication threads meaningfull names

[JIRA]

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

Jørgen Løland resolved DERBY-3437.
--

   Resolution: Fixed
Fix Version/s: 10.4.0.0

Thanks for the patch, Serge. I have confirmed that the threads in question now 
have meaningful names.

> Give all replication threads meaningfull names
> --
>
> Key: DERBY-3437
> URL: https://issues.apache.org/jira/browse/DERBY-3437
> Project: Derby
>  Issue Type: Improvement
>  Components: Newcomer, Replication
>Affects Versions: 10.4.0.0
>Reporter: Jørgen Løland
>Assignee: Serge Tsv
>Priority: Minor
> Fix For: 10.4.0.0
>
> Attachments: DERBY-3437-1.diff, DERBY-3437-1.stat, DERBY-3437.diff
>
>
> Some threads are created for replication purposes:
> * The log shipper thread on the master 
> (o.a.d.i.services.master.MasterController)
> * The database boot thread on the slave (o.a.d.i.db.SlaveDatabase)
> * The log receiver thread on the slave 
> (o.a.d.i.services.slave.SlaveController)
> These threads should be given names to simplify debugging.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-2911:
--

Derby Info: [Patch Available]

> Implement a buffer manager using java.util.concurrent classes
> -
>
> Key: DERBY-2911
> URL: https://issues.apache.org/jira/browse/DERBY-2911
> Project: Derby
>  Issue Type: Improvement
>  Components: Performance, Services
>Affects Versions: 10.4.0.0
>Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>Priority: Minor
> Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, 
> d2911-10.diff, d2911-10.stat, d2911-11.diff, d2911-12.diff, d2911-2.diff, 
> d2911-3.diff, d2911-4.diff, d2911-5.diff, d2911-6.diff, d2911-6.stat, 
> d2911-7.diff, d2911-7a.diff, d2911-9.diff, d2911-9.stat, d2911-enable.diff, 
> d2911-entry-javadoc.diff, d2911-unused.diff, d2911-unused.stat, 
> d2911perf.java, derby-2911-8.diff, derby-2911-8.stat, perftest.diff, 
> perftest.pdf, perftest.stat, perftest2.diff, perftest6.pdf, poisson_patch8.tar
>
>
> There are indications that the buffer manager is a bottleneck for some types 
> of multi-user load. For instance, Anders Morken wrote this in a comment on 
> DERBY-1704: "With a separate table and index for each thread (to remove latch 
> contention and lock waits from the equation) we (...) found that 
> org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 
> times more contention than the synchronization in LockSet.lockObject() and 
> LockSet.unlock(). That might be an indicator of where to apply the next push".
> It would be interesting to see the scalability and performance of a buffer 
> manager which exploits the concurrency utilities added in Java SE 5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2954) Add commands to NetworkServerControl for interacting with the replication functionality

[JIRA]

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

Øystein Grøvlen updated DERBY-2954:
---

Derby Info:   (was: [Patch Available])

Reverted patch v5 since NetworkServerControlImpl will not support commands for 
replication. (revision 635920)

> Add commands to NetworkServerControl for interacting with the replication 
> functionality
> ---
>
> Key: DERBY-2954
> URL: https://issues.apache.org/jira/browse/DERBY-2954
> Project: Derby
>  Issue Type: Sub-task
>  Components: Miscellaneous
>Affects Versions: 10.4.0.0
>Reporter: V.Narayanan
>Assignee: V.Narayanan
> Attachments: NetworkServerControlCmds_v1.diff, 
> NetworkServerControlCmds_v1.stat, NetworkServerControlCmds_v2.diff, 
> NetworkServerControlCmds_v2.stat, NetworkServerControlCmds_v3.diff, 
> NetworkServerControlCmds_v3.stat, NetworkServerControlCmds_v4.diff, 
> NetworkServerControlCmds_v4.stat, NetworkServerControlCmds_v5.diff, 
> NetworkServerControlCmds_v5.stat, NetworkServerControlCmds_v6.diff, 
> NetworkServerControlCmds_v6.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Preparing to cut the 10.4 branch

[Dyre . Tjeldvoll]

Rick Hillegas <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
>> Knut Anders Hatlen <[EMAIL PROTECTED]> writes:
>>
>>   
>>> [EMAIL PROTECTED] writes:
>>>
>>> 
 I did some experimenting, and here are the results:
 Alt A: With maint=001 and beta=true
 10.4.0.1 alpha - (635861)

 Alt B:
 With maint=001 and beta=false
 10.4.0.1 alpha - (635861M)

 Alt C:
 With maint=101 and beta=true
 10.4.1.1 beta - (635861M)

 Alt D:
 With maint=101 and beta=false
 10.4.1.1 - (635861M)

> Hi Dyre,
>
> This part of our release process seems to trip up every new release
> manager and the instructions could use some improvement. My
> understanding of bumplastdigit is this: you run it after you generate
> a candidate and it sets up the release id for the next candidate. In
> any event, with or without bumping the last digit, option (C) produces
> a release id that looks good to me.

OK, so your vote goes to C':
With maint=100 and beta=true
10.4.1.0 beta - (635861M)
?

-- 
dt

Re: Preparing to cut the 10.4 branch

[Daniel John Debrunner]

[EMAIL PROTECTED] wrote:

Daniel John Debrunner <[EMAIL PROTECTED]> writes:


Rick Hillegas wrote:


When I run sysinfo against the branch, it reports that the version
id is "10.4.0.1 alpha - (635685)". It think that you need to modify
the 3rd digit in the release id. I believe that is the secret
handshake which turns an alpha into a beta.

The "secret handshake" is documented here:

  http://db.apache.org/derby/papers/versionupgrade.html


I'm sorry, but this is utterly confusing to me.
 
tools/ant/properties/release.properties contains a property called 
'beta' that can either be 'true' or 'false'


The wiki page (http://wiki.apache.org/db-derby/DerbySnapshotOrRelease)
talks about the 'beta flag'.

You are saying that the 'beta flag' does not refer to the previously
mentioned property, but to whether or not the 3rd digit of the version
number (the fixpack number) is 0 or not?


No, to quote the document:

"Fixpack (f) of 0 (zero) is a special value that indicates alpha quality 
software and causes version string to be appended with the word "alpha"."


Thus the third digit being 0 always marks the software as alpha, 
regardless of any setting of the beta flag, it overrides it.


Dan.

[RESULT] [VOTE] Kim Haase as a committer

[Rick Hillegas]

The polls have closed. By unanimous consent and 14 binding PMC votes,  
Kim is Derby's newest committer. Congratulations, Kim!


Here were the +1's (no other votes were cast):

Rick Hillegas (PMC)
Kathey Marsden (PMC)
Army Brown (PMC)
Lance Andersen
Bryan Pendleton (PMC)
Andrew McIntyre (PMC)
Mamta Satoor (PMC)
Myrna van Lunteren (PMC)
Narayanan
Jørgen Løland
Knut Anders Hatlen (PMC)
Ole Solberg
Henri van de Scheur
Dyre Tjeldvoll (PMC)
Thomas Nielsen
Vemund Ostgaard
Øystein Grøvlen
Mike Matrigali (PMC)
Bernt Johnsen (PMC)
Kristian Waagan (PMC)
Jean Anderson (PMC)
Manjula Kutty
Dan Debrunner (PMC)

[jira] Assigned: (DERBY-3508) Log receiver thread fails with NPE at failover when master has died

[JIRA]

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

Jørgen Løland reassigned DERBY-3508:


Assignee: Jørgen Løland

> Log receiver thread fails with NPE at failover when master has died
> ---
>
> Key: DERBY-3508
> URL: https://issues.apache.org/jira/browse/DERBY-3508
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
>Reporter: Øystein Grøvlen
>Assignee: Jørgen Løland
>Priority: Minor
>
> Both master and slave embedded in ij.
> I kill master and perform failover on slave. 
> The following is printed in ij:
> ij> connect 'jdbc:derby:slaveDB;user=oystein;password=pass;failover=true';
> Exception in thread "derby.slave.logger-slaveDB" 
> java.lang.NullPointerException
> at 
> org.apache.derby.impl.services.replication.slave.SlaveController.setupConnection(SlaveController.java:348)
>at 
> org.apache.derby.impl.services.replication.slave.SlaveController.handleDisconnect(SlaveController.java:375)
>   at 
> org.apache.derby.impl.services.replication.slave.SlaveController.access$600(SlaveController.java:62)
>  at 
> org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:504)
> Note that failover works, and all seems well, so this is not a major issue.
> derby.log is as follows:
>   BEGIN REPLICATION ERROR MESSAGE -
> Lost connection with the replication master of database 'slaveDB'.
> java.io.EOFException
>   at 
> java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2552)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
>   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>   at 
> org.apache.derby.impl.services.replication.net.SocketConnection.readMessage(SocketConnection.java:84)
>   at 
> org.apache.derby.impl.services.replication.net.ReplicationMessageReceive.readMessage(ReplicationMessageReceive.java:387)
>   at 
> org.apache.derby.impl.services.replication.slave.SlaveController$SlaveLogReceiverThread.run(SlaveController.java:477)
> -  END REPLICATION ERROR MESSAGE --
> Failover perfomed successfully for database 'slaveDB'.
> Database Class Loader started - derby.database.classpath=''

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Preparing to cut the 10.4 branch

[Rick Hillegas]

[EMAIL PROTECTED] wrote:

Rick Hillegas <[EMAIL PROTECTED]> writes:

  

[EMAIL PROTECTED] wrote:


Knut Anders Hatlen <[EMAIL PROTECTED]> writes:

  
  

[EMAIL PROTECTED] writes:




I did some experimenting, and here are the results:
Alt A: With maint=001 and beta=true
10.4.0.1 alpha - (635861)

Alt B:
With maint=001 and beta=false
10.4.0.1 alpha - (635861M)

Alt C:
With maint=101 and beta=true
10.4.1.1 beta - (635861M)

Alt D:
With maint=101 and beta=false
10.4.1.1 - (635861M)
  


  

Hi Dyre,

This part of our release process seems to trip up every new release
manager and the instructions could use some improvement. My
understanding of bumplastdigit is this: you run it after you generate
a candidate and it sets up the release id for the next candidate. In
any event, with or without bumping the last digit, option (C) produces
a release id that looks good to me.



OK, so your vote goes to C':
With maint=100 and beta=true
10.4.1.0 beta - (635861M)
?

  

Hi Dyre,

To me that looks like a good id for a beta candidate. +1.

Regards,
-Rick

Re: Preparing to cut the 10.4 branch

[Dyre . Tjeldvoll]

Knut Anders Hatlen <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] writes:
>
>> Knut Anders Hatlen <[EMAIL PROTECTED]> writes:
>>
>>> [EMAIL PROTECTED] writes:
>>>
 I did some experimenting, and here are the results:
 Alt A: 
 With maint=001 and beta=true
 10.4.0.1 alpha - (635861)

 Alt B:
 With maint=001 and beta=false
 10.4.0.1 alpha - (635861M)

 Alt C:
 With maint=101 and beta=true
 10.4.1.1 beta - (635861M)

 Alt D:
 With maint=101 and beta=false
 10.4.1.1 - (635861M)

> I haven't followed the steps on the wiki myself, but by reading it, it
> seems like this is what should happen with the version numbers:
>
>   1. After creating the branch, "ant bumplastdigit" (step 5 under
>  "Prepare the community for a new release") will change the version
>  from 10.4.0.0 to 10.4.0.1. This sounds OK as it will help us
>  distinguish between 10.4 on the trunk and 10.4 on the branch.

Keep in mind that I have edited that page several times in the last
couple of days, so you need to look at an older version to see what it
originally said... The original version did not mention the 'ant
bumplastdigit' target. I added that beacuse I thought it superseded the
old 'ant regex.masters' target which no longer exists... 

>   2. Before creating the first release candidate, update both the third
>  and the fourth digit of the version number by updating the maint
>  property in tools/ant/properties/release.properties, and set the
>  beta property in the same file to false. After this step, the
>  version number shuld be 10.4.1.0.

This is the same as the C' alternative proposed by Rick isn't it? Seems
like Rick favors going directly to your step 2.

>   3. Before creating subsequent release candidates, update the fourth
>  digit (either by manually updating release.properties or by running
>  "ant bumplastdigit"). After this step, the version number should be
>  10.4.1.1, 10.4.1.2, ...

Agreed.

> The wiki page does not distinguish between (2) and (3), it only says
> this under "Check-ins just before generating release artifacts":
>
>> Bump the version number, adjust the beta flag and check in the new
>> version.
>>
>>  The third and fourth parts of the version are combined into a
>>  single property, maint, where maint = (third digit * 100) +
>>  fourth digit. Also, if this is a major/minor (feature) release,
>>  you should remove the beta flag at this time. You should update
>>  tools/ant/properties/release.properties by hand and then run:
>
> So according to this paragraph, you should edit release.property by
> hand, and then you can set maint to whichever number you'd like before
> you run maintversion2props.

Agreed. But I don't see what the purpose of the maintversion2props
program is (other than implementing ant bumplastdigit). 
Seems to me you could achieve exactly the same thing by just editing
release.properties by hand...

I would like to change the Wiki so that each step of the release process
becomes a cookbook, that the RM can follow. Specifically, I would like
to remove implicit dependencies on steps described elsewhere, even if
that should lead to some duplication.

-- 
dt

[jira] Commented: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes

[Knut Anders Hatlen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577460#action_12577460
 ] 

Knut Anders Hatlen commented on DERBY-2911:
---

All tests passed.

> Implement a buffer manager using java.util.concurrent classes
> -
>
> Key: DERBY-2911
> URL: https://issues.apache.org/jira/browse/DERBY-2911
> Project: Derby
>  Issue Type: Improvement
>  Components: Performance, Services
>Affects Versions: 10.4.0.0
>Reporter: Knut Anders Hatlen
>Assignee: Knut Anders Hatlen
>Priority: Minor
> Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, 
> d2911-10.diff, d2911-10.stat, d2911-11.diff, d2911-12.diff, d2911-2.diff, 
> d2911-3.diff, d2911-4.diff, d2911-5.diff, d2911-6.diff, d2911-6.stat, 
> d2911-7.diff, d2911-7a.diff, d2911-9.diff, d2911-9.stat, d2911-enable.diff, 
> d2911-entry-javadoc.diff, d2911-unused.diff, d2911-unused.stat, 
> d2911perf.java, derby-2911-8.diff, derby-2911-8.stat, perftest.diff, 
> perftest.pdf, perftest.stat, perftest2.diff, perftest6.pdf, poisson_patch8.tar
>
>
> There are indications that the buffer manager is a bottleneck for some types 
> of multi-user load. For instance, Anders Morken wrote this in a comment on 
> DERBY-1704: "With a separate table and index for each thread (to remove latch 
> contention and lock waits from the equation) we (...) found that 
> org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 
> times more contention than the synchronization in LockSet.lockObject() and 
> LockSet.unlock(). That might be an indicator of where to apply the next push".
> It would be interesting to see the scalability and performance of a buffer 
> manager which exploits the concurrency utilities added in Java SE 5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Preparing to cut the 10.4 branch

[Daniel John Debrunner]

[EMAIL PROTECTED] wrote:


I would like to change the Wiki so that each step of the release process
becomes a cookbook, that the RM can follow.


or that could be implemented in an ant script ...

Dan.

Re: Preparing to cut the 10.4 branch

[Knut Anders Hatlen]

[EMAIL PROTECTED] writes:

>>   2. Before creating the first release candidate, update both the third
>>  and the fourth digit of the version number by updating the maint
>>  property in tools/ant/properties/release.properties, and set the
>>  beta property in the same file to false. After this step, the
>>  version number shuld be 10.4.1.0.
>
> This is the same as the C' alternative proposed by Rick isn't it? Seems
> like Rick favors going directly to your step 2.

No, the C' alternative didn't set the beta flag to false. I think it is
OK to leave the beta flag for now, but it should be set to false before
you create the first release candidate. I don't have any strong opinions
on whether you should bump the version from 10.4.0.1 to 10.4.1.0 now or
later.

-- 
Knut Anders

Re: Preparing to cut the 10.4 branch

[Dyre . Tjeldvoll]

[EMAIL PROTECTED] writes:


>>   2. Before creating the first release candidate, update both the third
>>  and the fourth digit of the version number by updating the maint
>>  property in tools/ant/properties/release.properties, and set the
>>  beta property in the same file to false. After this step, the
>>  version number shuld be 10.4.1.0.
>
> This is the same as the C' alternative proposed by Rick isn't it? Seems
> like Rick favors going directly to your step 2.

They are not really the same, since C' keeps the beta flag until the
first RC is spun (thanks to Knut for pointing that out).

-- 
dt

Re: Preparing to cut the 10.4 branch

[Dyre . Tjeldvoll]

Daniel John Debrunner <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
>
>> I would like to change the Wiki so that each step of the release process
>> becomes a cookbook, that the RM can follow.
>
> or that could be implemented in an ant script ...

A laudable goal to be sure... but I think I'll start with the Wiki page
:)

-- 
dt

[jira] Created: (DERBY-3521) Functionality for skipping testsuites on certain platforms fails for the new management testsuite on phoneME advanced

[JIRA]

Functionality for skipping testsuites on certain platforms fails for the new 
management testsuite on phoneME advanced 
--

 Key: DERBY-3521
 URL: https://issues.apache.org/jira/browse/DERBY-3521
 Project: Derby
  Issue Type: Test
  Components: Test
 Environment: phoneME advanced platform
Reporter: Vemund Østgaard
Assignee: Vemund Østgaard


It is not possible to run suites.All on phoneME advanced, junit will just exit 
with an InvocationTargetException when trying to invoke the suites.All.suite() 
method. Unwrapping the exception shows that the underlying reason is a 
NoClassDefFoundError from the invoke() call in 
AllPackages.addSuiteByReflection() when trying to load the new management 
testsuite.

Now, this suite is compiled into 1.5 classfiles, so the Class.forName() call 
before the invoke() is expected to fail with UnsupportedClassVersionError on 
Java ME and Java SE 1.4. It does fail as expected when running with jdk 1.4, 
but on phoneME advanced it does not, possibly a bug in phoneME advanced.

A fix/workaround in the testinfrastructure may be to catch 
InvocationTargetException from the try block below, unwrap it and see if it is 
an instance of LinkageError and if so skip the testsuite. This would make it 
possible to run the tests on phoneME advanced.

private static Test addSuiteByReflection(String className) throws Exception
   {
   try {
   Class clz = Class.forName(className);
  Method sm = clz.getMethod("suite", null);
return (Test) sm.invoke(null, null);
   } catch (LinkageError  e) {
   return new TestSuite("SKIPPED: " + className + " - " +
   e.getMessage());
   }
   } 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Preparing to cut the 10.4 branch

[fp]

When I run sysinfo against the trunk i get, Why ?
10.5.0.0 alpha - (635600)


Daniel John Debrunner-2 wrote:
> 
> Rick Hillegas wrote:
> 
>> When I run sysinfo against the branch, it reports that the version id is 
>> "10.4.0.1 alpha - (635685)". It think that you need to modify the 3rd 
>> digit in the release id. I believe that is the secret handshake which 
>> turns an alpha into a beta.
> 
> The "secret handshake" is documented here:
> 
>http://db.apache.org/derby/papers/versionupgrade.html
> 
> Dan.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Preparing-to-cut-the-10.4-branch-tp15928311p15976672.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.

Re: Preparing to cut the 10.4 branch

[Daniel John Debrunner]

fp wrote:

When I run sysinfo against the trunk i get, Why ?
10.5.0.0 alpha - (635600)


10.5 because with the creation of the 10.4 branch, trunk becomes the 
development line for the next release (10.5).


alpha because the third digit is zero and the trunk is leading edge 
development, see:

  http://db.apache.org/derby/dev/derby_source.html#Development+trunk

Dan.

[jira] Updated: (DERBY-3521) Functionality for skipping testsuites on certain platforms fails for the new management testsuite on phoneME advanced

[JIRA]

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

Vemund Østgaard updated DERBY-3521:
---

Attachment: 3521-fix-diff

Attaching simple fix, 3521-fix-diff, which unwraps the 
InvocationTargetException and cheks if it contains an instanceof LinkageError.



> Functionality for skipping testsuites on certain platforms fails for the new 
> management testsuite on phoneME advanced 
> --
>
> Key: DERBY-3521
> URL: https://issues.apache.org/jira/browse/DERBY-3521
> Project: Derby
>  Issue Type: Test
>  Components: Test
> Environment: phoneME advanced platform
>Reporter: Vemund Østgaard
>Assignee: Vemund Østgaard
> Attachments: 3521-fix-diff
>
>
> It is not possible to run suites.All on phoneME advanced, junit will just 
> exit with an InvocationTargetException when trying to invoke the 
> suites.All.suite() method. Unwrapping the exception shows that the underlying 
> reason is a NoClassDefFoundError from the invoke() call in 
> AllPackages.addSuiteByReflection() when trying to load the new management 
> testsuite.
> Now, this suite is compiled into 1.5 classfiles, so the Class.forName() call 
> before the invoke() is expected to fail with UnsupportedClassVersionError on 
> Java ME and Java SE 1.4. It does fail as expected when running with jdk 1.4, 
> but on phoneME advanced it does not, possibly a bug in phoneME advanced.
> A fix/workaround in the testinfrastructure may be to catch 
> InvocationTargetException from the try block below, unwrap it and see if it 
> is an instance of LinkageError and if so skip the testsuite. This would make 
> it possible to run the tests on phoneME advanced.
> private static Test addSuiteByReflection(String className) throws Exception
>{
>try {
>Class clz = Class.forName(className);
>   Method sm = clz.getMethod("suite", null);
> return (Test) sm.invoke(null, null);
>} catch (LinkageError  e) {
>return new TestSuite("SKIPPED: " + className + " - " +
>e.getMessage());
>}
>} 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3521) Functionality for skipping testsuites on certain platforms fails for the new management testsuite on phoneME advanced

[JIRA]

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

Vemund Østgaard updated DERBY-3521:
---

Derby Info: [Patch Available]

> Functionality for skipping testsuites on certain platforms fails for the new 
> management testsuite on phoneME advanced 
> --
>
> Key: DERBY-3521
> URL: https://issues.apache.org/jira/browse/DERBY-3521
> Project: Derby
>  Issue Type: Test
>  Components: Test
> Environment: phoneME advanced platform
>Reporter: Vemund Østgaard
>Assignee: Vemund Østgaard
> Attachments: 3521-fix-diff
>
>
> It is not possible to run suites.All on phoneME advanced, junit will just 
> exit with an InvocationTargetException when trying to invoke the 
> suites.All.suite() method. Unwrapping the exception shows that the underlying 
> reason is a NoClassDefFoundError from the invoke() call in 
> AllPackages.addSuiteByReflection() when trying to load the new management 
> testsuite.
> Now, this suite is compiled into 1.5 classfiles, so the Class.forName() call 
> before the invoke() is expected to fail with UnsupportedClassVersionError on 
> Java ME and Java SE 1.4. It does fail as expected when running with jdk 1.4, 
> but on phoneME advanced it does not, possibly a bug in phoneME advanced.
> A fix/workaround in the testinfrastructure may be to catch 
> InvocationTargetException from the try block below, unwrap it and see if it 
> is an instance of LinkageError and if so skip the testsuite. This would make 
> it possible to run the tests on phoneME advanced.
> private static Test addSuiteByReflection(String className) throws Exception
>{
>try {
>Class clz = Class.forName(className);
>   Method sm = clz.getMethod("suite", null);
> return (Test) sm.invoke(null, null);
>} catch (LinkageError  e) {
>return new TestSuite("SKIPPED: " + className + " - " +
>e.getMessage());
>}
>} 

-- 
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

[jira]

Issue Subscription
Filter: Derby: JIRA issues with patch available (14 issues)
Subscriber: derby-dev


Key Summary
DERBY-3521  Functionality for skipping testsuites on certain platforms fails 
for the new management testsuite on phoneME advanced 
https://issues.apache.org/jira/browse/DERBY-3521
DERBY-2911  Implement a buffer manager using java.util.concurrent classes
https://issues.apache.org/jira/browse/DERBY-2911
DERBY-3447  Shutdown on a database without stopping replication hangs
https://issues.apache.org/jira/browse/DERBY-3447
DERBY-3491  Change SystemPermission to be a two arguement permission with a 
name (object the permission is on) and an action.
https://issues.apache.org/jira/browse/DERBY-3491
DERBY-3448  Allow the MailJdbc system test to run under junit.
https://issues.apache.org/jira/browse/DERBY-3448
DERBY-3520  convert views.sql to junit
https://issues.apache.org/jira/browse/DERBY-3520
DERBY-3169  Add documentation for replication
https://issues.apache.org/jira/browse/DERBY-3169
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-3379  "No Current connection" on PooledConnection.getConnection() if 
pooled connection is reused during connectionClosed processing
https://issues.apache.org/jira/browse/DERBY-3379
DERBY-2953  Dump the information about rollbacks of the global transaction 
(introduced in DERBY-2220 and DERBY-2432) to derby.log
https://issues.apache.org/jira/browse/DERBY-2953
DERBY-3227  Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227

[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported

[JIRA]

[ 
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577486#action_12577486
 ] 

Vemund Østgaard commented on DERBY-3320:


My understanding is along the lines of what Knut writes, that the set of 
locales supported by Collator and Locale in theory can be different.

If collation=TERRITORY_BASED the selected locale should be one of those 
returned by Collator.getAvailableLocales().

See also my comment on Jan. 25. 08.

> 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_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 can return localized instances. The returned array represents the union 
> of locales supported by the Java runtime and by installed CollatorProvider 
> implementations. It must contain at least a Locale instance equal to 
> Locale.US.
> Returns:
> An array of locales for which localized Collator instances are 
> available.
> This led me to thinking about how Derby should behave if created/booted with 
> collation=TERRITORY_BASED and territory=. I'm not 
> sure what the consequences could be if the database is first created on a 
> platform that supports whatever locale is set and later booted with one that 
> doesn't, or created on a platform missing support and later booted with one 
> that has. In any case I think it may confuse a user needlessly to see the 
> database boot successfully with his collation setting and later behave in a 
> way he does not expect.
> Opinions voiced on the derby-dev list are that both database creation and 
> boot should fail if collation=TERRITORY_BASED and the selected locale is not 
> supported.
> If a change like this is implemented, the collationtests should be changed to 
> verify correct behavior also if they are executed in an environment were some 
> of the tested locales are not supported.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported

[Mamta A. Satoor (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577500#action_12577500
 ] 

Mamta A. Satoor commented on DERBY-3320:


Thanks, Vemund and Knut. I was under the impression that if a locale is 
avaialble through Locale.getAvailableLocales(), then all the locale related 
functionality (including Collation) is automatically available. But it appears 
that it is not correct. Based on this, I will go ahead and code to look for 
Collator.getAvailableLocales rather than Locale.getAvailableLocales(). Is there 
a need to look at Locale.getAvailableLocales() also or is 
Collator.getAvailableLocales() sufficient?

> 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_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 can return localized instances. The returned array represents the union 
> of locales supported by the Java runtime and by installed CollatorProvider 
> implementations. It must contain at least a Locale instance equal to 
> Locale.US.
> Returns:
> An array of locales for which localized Collator instances are 
> available.
> This led me to thinking about how Derby should behave if created/booted with 
> collation=TERRITORY_BASED and territory=. I'm not 
> sure what the consequences could be if the database is first created on a 
> platform that supports whatever locale is set and later booted with one that 
> doesn't, or created on a platform missing support and later booted with one 
> that has. In any case I think it may confuse a user needlessly to see the 
> database boot successfully with his collation setting and later behave in a 
> way he does not expect.
> Opinions voiced on the derby-dev list are that both database creation and 
> boot should fail if collation=TERRITORY_BASED and the selected locale is not 
> supported.
> If a change like this is implemented, the collationtests should be changed to 
> verify correct behavior also if they are executed in an environment were some 
> of the tested locales are not supported.

-- 
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-3352) truncateTable crashed, Caused by: java.lang.NullPointerException

[Mike Matrigali]

I didn't think truncate table was supported so didn't look at that code,
I can delete the dead code, and if anyone wants it, it is always in
svn.  I didn't see any tests for the code, and the supporte version
throws a not supported exception.

Knut Anders Hatlen (JIRA) wrote:

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

Knut Anders Hatlen updated DERBY-3352:
--

Derby Info: [Regression]

The NullPointerException seems to have been introduced in this commit:


r528033 | mikem | 2007-04-12 18:58:30 +0200 (Thu, 12 Apr 2007) | 6 lines

DERBY-2537, 1st incremental checking for this issue.  This changes builds
the framework for storing/retrieving the collation metadata in store and for
passing that info down from language into store.  Some paths still have
default collation hard coded and have been marked TODO-COLLATION.





truncateTable crashed, Caused by: java.lang.NullPointerException


Key: DERBY-3352
URL: https://issues.apache.org/jira/browse/DERBY-3352
Project: Derby
 Issue Type: Bug
 Components: Services
   Affects Versions: 10.3.1.4, 10.3.2.1
Environment: Windows XP.SP2 , Eclipse 3.2.2 , JDK 1.5_05 
   Reporter: QingpingXu

   Priority: Critical

Since derby 10.3.2.1, when truncate a table which has index , a 
java.lang.NullPointerException is throwed;but the same src runs successfully 
with derby 10.2.2.0。
here's the example source code and stack trace:
Src:
public static void main(String[] args)
{

try
{
Class.forName("org.apache.derby.jdbc.EmbeddedDriver");

Connection conn = 
DriverManager.getConnection("jdbc:derby:test;create=true");

Statement stat = conn.createStatement();
stat.executeUpdate("create table m (uri varchar(256),f 
int)");
stat.executeUpdate("create index aa on m (uri)");
stat.executeUpdate("truncate table m");

System.out.println("Truncate table m successfully！");
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
Error:
java.sql.SQLException: Java Exception:":java.lang.NullPointerException"。
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:245)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
at 
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1574)
at 
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1315)
at 
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:618)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:176)
at update.UpdateURI.main(UpdateURI.java:34)
Caused by: java.lang.NullPointerException
at 
org.apache.derby.impl.sql.execute.AlterTableConstantAction.truncateTable(AlterTableConstantAction.java:1462)
at 
org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(AlterTableConstantAction.java:531)
at 
org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:64)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:370)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1225)
... 3 more

[jira] Created: (DERBY-3522) java.lang.ArrayStoreException thrown when running lang/autoincrement.sql on 10.1 branch.

[A B (JIRA)]

java.lang.ArrayStoreException thrown when running lang/autoincrement.sql on 
10.1 branch.


 Key: DERBY-3522
 URL: https://issues.apache.org/jira/browse/DERBY-3522
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure, SQL
Affects Versions: 10.1.3.2
Reporter: A B
Priority: Minor


When running derbyall on a 10.1 codeline at svn # 634899 with ibm15, I saw the 
following failure in lang/autoincrement.sql:

ij> -- multi-values insert, return value of the function should not change, 
same as DB2
values IDENTITY_VAL_LOCAL();
1  
---
2  
ij> select * from t1;
C1 |C2 
---
1  |8  
2  |1  
3  |8  
4  |9  
ij> insert into t1(c2) select c1 from t1;
java.lang.ArrayStoreException
at 
org.apache.derby.impl.sql.execute.BaseActivation.setCurrentRow(Unknown Source)
at 
org.apache.derby.impl.sql.execute.NoPutResultSetImpl.setCurrentRow(Unknown 
Source)
at 
org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown 
Source)
at org.apache.derby.impl.sql.execute.InsertResultSet.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.execute(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
at org.apache.derby.tools.ij.main(Unknown Source)

I ran the test several times by hand with ibm15 and was unable to reproduce the 
error (neither with sane nor insane jars).  I also ran with ibm142 but could 
not reproduce it there, either.  So it appears to have been a fluke of some 
sort--but since it did occur once, I'm filing this Jira for tracking...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Question about collatedSuite()

[Kathey Marsden]

I noticed in CollationTest.collatedSuite()  we run DatabaseMetaDataTest, 
BatchUpdateTest,
GroupByExpressionTest, and UpdateableResultSetTest for each of four 
locales.  I wonder if
that really adds a lot of coverage or if it would be sufficient to run 
them with just one of the

locales.  Thoughts?  It adds a fair amount of time to lang._Suite.

Kathey

Re: Junit hang

[Rick Hillegas]

Thanks, Knut. I sync'd with the mainline and the problem has gone away. 
My tests now run cleanly. Thanks to everyone who replied on this thread. 
I received a lot of valuable advice.


Regards,
-Rick

Knut Anders Hatlen wrote:

Rick Hillegas <[EMAIL PROTECTED]> writes:

  

Thanks, Knut. Increasing the max PermGen size got the tests past the
out-of-memory-error. They then hung on test case 8515 out of 8520, in
org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_StateTest_part1.
 I
interrupted the tests with "kill -quit" as you recommended. I'm
attaching the console output.



Hi Rick,

From looking at the output, I would guess that one of the replication
tests misses something in the clean-up, and that makes subsequent
replication tests fail or hang.

I think Øystein disabled those tests in revision 635575. Do you still
see the hang after updating your source tree?

By the way, is it normal that a single process has seven threads named
derby.AntiGC? Does that mean that there are seven instances of the
embedded driver in the same JVM?

  

[jira] Created: (DERBY-3524) NullPointerException in Xact.openContainer() when running suites.All on 10.3.

[A B (JIRA)]

NullPointerException in Xact.openContainer() when running suites.All on 10.3.
-

 Key: DERBY-3524
 URL: https://issues.apache.org/jira/browse/DERBY-3524
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure, Store
Affects Versions: 10.3.2.2
Reporter: A B
Priority: Minor


When running suites.All on a 10.3 codeline at svn # 634534 with ibm15, I saw a 
total of *45* failures, all caused by NullPointerExceptions that occurred as 
part of a call to Xact.openContainer().  An example of one of the stack traces 
is:

java.lang.NullPointerException
 at 
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown 
Source)
 at 
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown 
Source)
 at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source)
 at 
org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(Unknown 
Source)
 at org.apache.derby.impl.store.access.heap.Heap.open(Unknown Source)
 at org.apache.derby.impl.store.access.heap.HeapPostCommit.performWork(Unknown 
Source)
 at org.apache.derby.impl.store.raw.xact.Xact.postTermination(Unknown Source)
 at org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Unknown Source)
 at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
 at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
 at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown Source)

The 45 failures are spread across the following JUnit tests: 
upgradeTests.changes10_3, BlobStoredProcedureTest, ClobStoredProcedureTest, and 
DatabaseMetaDataTest.  The call stack leading up to Xact.openContainer() is not 
always the same for the different failures.

I ran each of the aforementioned JUnit tests on my local machine and they all 
ran without error, so I am unable to reproduce the problem.  But filing Jira 
for tracking...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts

[Anurag Shekhar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577511#action_12577511
 ] 

Anurag Shekhar commented on DERBY-3523:
---

There can be two ways to fix this problem

1. Change the message to remove unique constraint from the message.

Problem
During soft upgrade run unique constraint can't have null able columns. 
While using the data base throwing new message may give wrong information 
to the user claiming that he was using primary key when actually he was using 
unique constraint.


2. Introduce new message with a new state and use older state only during soft 
upgrade run.

Problem
There will be impact of existing application if they are relying on 
sql state to detect the cause of failure in creating primary key.

> sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are 
> associated with wrong message texts 
> --
>
> Key: DERBY-3523
> URL: https://issues.apache.org/jira/browse/DERBY-3523
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.4.0.0, 10.5.0.0
>Reporter: Anurag Shekhar
>Assignee: Anurag Shekhar
>
> There are three messages which after Derby-3330 checkin now giving wrong 
> information. These are
> 42831:'{0}' cannot be a column of a primary key or unique key because it can 
> contain null values.
> 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or 
> unique constraint, which cannot have any null able columns.
> X0Y63.S:The command on table '{0}' failed because null data was found in the 
> primary key or unique constraint/index column(s). All columns in a primary or 
> unique index key must not be null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3341) TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR.

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577512#action_12577512
 ] 

Rick Hillegas commented on DERBY-3341:
--

Committed derby-3341-01-da-coerceWithTests.diff at subversion revision 636004. 
The old-style regression tests ran cleanly for me last Friday except for a 
known instability in the stress multi tests. The junit tests hung, however, at 
the end in the replication tests. Those replication tests have been disabled 
and the junit tests now run cleanly for me.

> TABLE FUNCTION returning CHAR values does not return a correct value if the 
> Java ResultSet class returns a value less than the length of the defined CHAR.
> --
>
> Key: DERBY-3341
> URL: https://issues.apache.org/jira/browse/DERBY-3341
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Reporter: Daniel John Debrunner
> Fix For: 10.4.0.0
>
> Attachments: derby-3341-01-coerce.diff, 
> derby-3341-01-da-coerceWithTests.diff, derby-3341-02-aa-refGuide.diff, 
> derby_3341_test.txt, rrefcreatefunctionstatement.html
>
>
> Defining a column in the returned type as CHAR(10) requires that the returned 
> value be of length 10 characters.
> Defining a table function with a return type of:
>returns TABLE  column0 char( 10 ), column1 char( 10 ))
> seems to just return whatever the Java ResultSet implementation handed it.
> My guess this is true for all variable length types, no casting of the value 
> occurs when it is returned to the SQL domain.
> Java single value functions and procedure out parameters do perform any 
> required casting to ensure the value is of the declared type.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3341) TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR.

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577514#action_12577514
 ] 

Rick Hillegas commented on DERBY-3341:
--

Committed doc changes derby-3341-02-aa-refGuide.diff at subversion revision 
636007.

> TABLE FUNCTION returning CHAR values does not return a correct value if the 
> Java ResultSet class returns a value less than the length of the defined CHAR.
> --
>
> Key: DERBY-3341
> URL: https://issues.apache.org/jira/browse/DERBY-3341
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Reporter: Daniel John Debrunner
> Fix For: 10.4.0.0
>
> Attachments: derby-3341-01-coerce.diff, 
> derby-3341-01-da-coerceWithTests.diff, derby-3341-02-aa-refGuide.diff, 
> derby_3341_test.txt, rrefcreatefunctionstatement.html
>
>
> Defining a column in the returned type as CHAR(10) requires that the returned 
> value be of length 10 characters.
> Defining a table function with a return type of:
>returns TABLE  column0 char( 10 ), column1 char( 10 ))
> seems to just return whatever the Java ResultSet implementation handed it.
> My guess this is true for all variable length types, no casting of the value 
> occurs when it is returned to the SQL domain.
> Java single value functions and procedure out parameters do perform any 
> required casting to ensure the value is of the declared type.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Regression Test Report - Daily 635600 - Sun DBTG

[Henri . Vandescheur]

[Auto-generated mail]

*Daily* 635600/2008-03-10 18:01:41 MET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
0274274 081.63% derbyall
01045410454 0   1376.82% suitesAll
 linN+1
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sles
0274274 071.26% derbyall
01045410454 0   908.02% suitesAll
 sol
0274274 075.21% derbyall
01045410454 0   1629.17% suitesAll
 solN+1
0274274 098.58% derbyall
01045410454 0   175.80% suitesAll
 sparc
0274274 066.37% derbyall
01045410454 0   367.23% suitesAll
 vista
0274274 094.35% derbyall
093459345 067.95% suitesAll
 w2003
0274274 098.57% derbyall
F:4,E:71618891169 041.46% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-635600.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/635600_bySig.html 

*Jvm: 1.5*
 lin
0275275 080.53% derbyall
087348734 0   1018.25% suitesAll
 linN+1
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sles
0275275 071.48% derbyall
087348734 0   572.72% suitesAll
 sol
0275275 079.34% derbyall
087348734 0   849.19% suitesAll
 solN+1
0275275 089.38% derbyall
087348734 0   810.32% suitesAll
 sparc
0275275 067.60% derbyall
087348734 0   706.49% suitesAll
 vista
0275275 072.17% derbyall
076257625 0   409.69% suitesAll
 w2003
0275275 075.76% derbyall
076257625 0   265.52% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-635600.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/635600_bySig.html 

*Jvm: 1.4*
 lin
0272272 281.64% derbyall
085828582 0   904.59% suitesAll
 linN+1
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sles
0272272 273.37% derbyall
085828582 0   529.96% suitesAll
 sol
0272272 278.49% derbyall
085828582 0   698.45% suitesAll
 solN+1
0272272 290.14% derbyall
085828582 0   752.08% suitesAll
 sparc
0272272 267.68% derbyall
085828582 0   712.83% suitesAll
 vista
0272272 271.46% derbyall
074737473 0   398.30% suitesAll
 w2003
0272272 276.43% derbyall
074777477 0   255.38% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-635600.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/635600_bySig.html 

---

Changes in  http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/635600.txt 

( All results in http://dbtg.thresher.com/derby/test/ ) 

[jira] Created: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts

[Anurag Shekhar (JIRA)]

sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are 
associated with wrong message texts 
--

 Key: DERBY-3523
 URL: https://issues.apache.org/jira/browse/DERBY-3523
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar


There are three messages which after Derby-3330 checkin now giving wrong 
information. These are

42831:'{0}' cannot be a column of a primary key or unique key because it can 
contain null values.
42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or 
unique constraint, which cannot have any null able columns.
X0Y63.S:The command on table '{0}' failed because null data was found in the 
primary key or unique constraint/index column(s). All columns in a primary or 
unique index key must not be null.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3341) TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR.

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577516#action_12577516
 ] 

Rick Hillegas commented on DERBY-3341:
--

Ported 636004 from trunk to 10.4 branch at subversion revision 636010.

> TABLE FUNCTION returning CHAR values does not return a correct value if the 
> Java ResultSet class returns a value less than the length of the defined CHAR.
> --
>
> Key: DERBY-3341
> URL: https://issues.apache.org/jira/browse/DERBY-3341
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Reporter: Daniel John Debrunner
> Fix For: 10.4.0.0
>
> Attachments: derby-3341-01-coerce.diff, 
> derby-3341-01-da-coerceWithTests.diff, derby-3341-02-aa-refGuide.diff, 
> derby_3341_test.txt, rrefcreatefunctionstatement.html
>
>
> Defining a column in the returned type as CHAR(10) requires that the returned 
> value be of length 10 characters.
> Defining a table function with a return type of:
>returns TABLE  column0 char( 10 ), column1 char( 10 ))
> seems to just return whatever the Java ResultSet implementation handed it.
> My guess this is true for all variable length types, no casting of the value 
> occurs when it is returned to the SQL domain.
> Java single value functions and procedure out parameters do perform any 
> required casting to ensure the value is of the declared type.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts

[Kathey Marsden (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577517#action_12577517
 ] 

Kathey Marsden commented on DERBY-3523:
---

I see examples in messages.xml, such as 8006 where we have more than one 
instance of a message with the same SQLState but different messages.   Is that 
a possibility.


> sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are 
> associated with wrong message texts 
> --
>
> Key: DERBY-3523
> URL: https://issues.apache.org/jira/browse/DERBY-3523
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.4.0.0, 10.5.0.0
>Reporter: Anurag Shekhar
>Assignee: Anurag Shekhar
>
> There are three messages which after Derby-3330 checkin now giving wrong 
> information. These are
> 42831:'{0}' cannot be a column of a primary key or unique key because it can 
> contain null values.
> 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or 
> unique constraint, which cannot have any null able columns.
> X0Y63.S:The command on table '{0}' failed because null data was found in the 
> primary key or unique constraint/index column(s). All columns in a primary or 
> unique index key must not be null.

-- 
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-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts

[Mike Matrigali]

Does SQL standard or Derby documentation actually document the specific 
number we return for any of these error conditions?  For Derby 
documentation I mean separate from the document which lists all errors, 
ie. does create index documentation say what error number you will get 
for a given error.


It does seem like the best case would be for the error message system to
somehow return a different error message for the same number if it is
in soft upgrade vs. hard upgrade.  Does the error message system support
such a thing?

Kathey Marsden (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577517#action_12577517 ] 


Kathey Marsden commented on DERBY-3523:
---

I see examples in messages.xml, such as 8006 where we have more than one 
instance of a message with the same SQLState but different messages.   Is that 
a possibility.


sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts 
--


Key: DERBY-3523
URL: https://issues.apache.org/jira/browse/DERBY-3523
Project: Derby
 Issue Type: Bug
   Affects Versions: 10.4.0.0, 10.5.0.0
   Reporter: Anurag Shekhar
   Assignee: Anurag Shekhar

There are three messages which after Derby-3330 checkin now giving wrong 
information. These are
42831:'{0}' cannot be a column of a primary key or unique key because it can 
contain null values.
42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or 
unique constraint, which cannot have any null able columns.
X0Y63.S:The command on table '{0}' failed because null data was found in the 
primary key or unique constraint/index column(s). All columns in a primary or 
unique index key must not be null.

[jira] Commented: (DERBY-3341) TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR.

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577538#action_12577538
 ] 

Rick Hillegas commented on DERBY-3341:
--

Ported 636007 from docs trunk to 10.4 docs branch at revision 636041.

> TABLE FUNCTION returning CHAR values does not return a correct value if the 
> Java ResultSet class returns a value less than the length of the defined CHAR.
> --
>
> Key: DERBY-3341
> URL: https://issues.apache.org/jira/browse/DERBY-3341
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Reporter: Daniel John Debrunner
> Fix For: 10.4.0.0
>
> Attachments: derby-3341-01-coerce.diff, 
> derby-3341-01-da-coerceWithTests.diff, derby-3341-02-aa-refGuide.diff, 
> derby_3341_test.txt, rrefcreatefunctionstatement.html
>
>
> Defining a column in the returned type as CHAR(10) requires that the returned 
> value be of length 10 characters.
> Defining a table function with a return type of:
>returns TABLE  column0 char( 10 ), column1 char( 10 ))
> seems to just return whatever the Java ResultSet implementation handed it.
> My guess this is true for all variable length types, no casting of the value 
> occurs when it is returned to the SQL domain.
> Java single value functions and procedure out parameters do perform any 
> required casting to ensure the value is of the declared type.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions

[A B (JIRA)]

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

A B updated DERBY-3310:
---

Attachment: d3310_writeup_1.html

I did some tracing through the various compilation stages for the short 
reproduction provided by
Knut Anders in his February 21st comment.  Attached is d3310_writeup_1.html, 
which is an attempt
to describe my findings.  Hopefully this is helpful...

> ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
> --
>
> Key: DERBY-3310
> URL: https://issues.apache.org/jira/browse/DERBY-3310
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.4.0.0
>Reporter: Dyre Tjeldvoll
>Priority: Minor
> Attachments: cast-repro.sql, d3310_writeup_1.html, 
> derby-3310_remove_genNormalizeResultSetNode_diff.txt, 
> derby-3310_try1_diff.txt, derby3310_rsn_cleanup_1.txt
>
>
> The following code 
> CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT);
> -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT)
> INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2
>  FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID;
> gives
> ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class 
> org.apache.derby.iapi.types.SQLInteger) expected to be the same as 
> col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): 
> org.apache.derby.shared.common.sanity.AssertFailure'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-3513:
--

Attachment: derby-3513_diff.txt

A gave the user a patched derby.jar that just changed the newBrokeredStatement 
code to
hold the jdbcLevel in a local variable.
With the patch they were not able to reproduce 
the error so this small change  may serve as a workaround to a probable JIT 
issue.

Unfortunately because of their complex environment, it is difficult to perform 
JIT diagnostics and get this resolved from the JVM side, so the
user has requested that we check in the change, 
so that they can move forward. I wonder if there are
any objections to checking in this change.  I'll plan to check in Thursday if I 
don't hear back.

The NullPointer failure happened with 30-40% of the builds in a complex build 
then test environment for an Application Server based system.  It could not be 
reproduced outside of the build-test environment shown below :

org.apache.derby.tools.sysinfo
-- Java Information --
Java Version:1.5.0
Java Vendor: IBM Corporation
Java home:   /opt/MyServer/java/jre
Java classpath:  /opt/MyServer/derby/lib/derby.jar
OS name: Linux
OS architecture: x86
OS version:  2.6.9-55.ELsmp
Java user name:  builduser
Java user home:  /home/wsbuild
Java user dir:   /opt/MyServer/derby
java.specification.name: Java Platform API Specification
java.specification.version: 1.5
- Derby Information 
JRE - JDBC: J2SE 5.0 - JDBC 3.0

> NullPointerException in newBrokeredStatement in app server environment
> --
>
> Key: DERBY-3513
> URL: https://issues.apache.org/jira/browse/DERBY-3513
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.1.3.2
> Environment: Java Version:1.5.0
> Java Vendor: IBM Corporation
> OS name: Linux
> OS architecture: x86
> OS version:  2.6.9-55.ELsmp
>Reporter: Kathey Marsden
> Attachments: derby-3513_diff.txt
>
>
> User reports in an app server environment an intermittent  
> NullPointerException
> with the 10.1 trace:
>  R java.lang.NullPointerException
> org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448)
>
> ...org.apache.derby.jdbc.XAStatementControl.(XAStatementControl.java:62)
> 
> ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827)
>   
> org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296)
>  [snip user trace]
> The code at line 448 is simply:
> return new BrokeredStatement(statementControl, getJDBCLevel());
> so not much room for an NPE there.   I added println statements to identify 
> the state values and where the NPE is actually occurring but that seemed to 
> make the 
> problem go away.  It may be a JIT issue.
> I gave them the fix for DERBY-2142 and that did not correct the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3513) NullPointerException in newBrokeredStatement in app server environment

[Kathey Marsden (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577595#action_12577595
 ] 

Kathey Marsden commented on DERBY-3513:
---

Here is the full java version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20070608 
(SR5+IY99712))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070426 
(JIT enabled)
J9VM - 20070420_12448_lHdSMR
JIT  - 20070419_1806_r8
GC   - 200704_19)
JCL  - 20070608

> NullPointerException in newBrokeredStatement in app server environment
> --
>
> Key: DERBY-3513
> URL: https://issues.apache.org/jira/browse/DERBY-3513
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.1.3.2
> Environment: Java Version:1.5.0
> Java Vendor: IBM Corporation
> OS name: Linux
> OS architecture: x86
> OS version:  2.6.9-55.ELsmp
>Reporter: Kathey Marsden
> Attachments: derby-3513_diff.txt
>
>
> User reports in an app server environment an intermittent  
> NullPointerException
> with the 10.1 trace:
>  R java.lang.NullPointerException
> org.apache.derby.iapi.jdbc.BrokeredConnection.newBrokeredStatement(BrokeredConnection.java:448)
>
> ...org.apache.derby.jdbc.XAStatementControl.(XAStatementControl.java:62)
> 
> ...org.apache.derby.jdbc.EmbedXAConnection.wrapStatement(EmbedXAConnection.java:827)
>   
> org.apache.derby.iapi.jdbc.BrokeredConnection.createStatement(BrokeredConnection.java:296)
>  [snip user trace]
> The code at line 448 is simply:
> return new BrokeredStatement(statementControl, getJDBCLevel());
> so not much room for an NPE there.   I added println statements to identify 
> the state values and where the NPE is actually occurring but that seemed to 
> make the 
> problem go away.  It may be a JIT issue.
> I gave them the fix for DERBY-2142 and that did not correct the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Regression Test Report - tinderbox_trunk16 636018 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*tinderbox_trunk16* 636018/2008-03-11 18:22:47 CET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
  SunOS-5.10_i86pc-i386
0274274 087.23% derbyall
F:1,E:01045310452 0   1192.67% 
org.apache.derbyTesting.functionTests.suites.All
  Details in  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-636018.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/636018_bySig.html
 
---

Changes in  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/636018.txt 

( All results in http://dbtg.thresher.com/derby/test/ ) 

[jira] Commented: (DERBY-3310) ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions

[Kathey Marsden (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577604#action_12577604
 ] 

Kathey Marsden commented on DERBY-3310:
---

Thank you Army for your detailed write up and articulating what
I could not for the proposed change for this issue.  Dan given 
Army's analysis, do you think there is now sufficient reasoning for
the derby-3310_try1_diff.txt change.

> ASSERT in MergeSort.checkColumnTypes() disallow legal type conversions
> --
>
> Key: DERBY-3310
> URL: https://issues.apache.org/jira/browse/DERBY-3310
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.4.0.0
>Reporter: Dyre Tjeldvoll
>Priority: Minor
> Attachments: cast-repro.sql, d3310_writeup_1.html, 
> derby-3310_remove_genNormalizeResultSetNode_diff.txt, 
> derby-3310_try1_diff.txt, derby3310_rsn_cleanup_1.txt
>
>
> The following code 
> CREATE TABLE U (SNAME VARCHAR(32000), TNAME VARCHAR(32000), C1 BIGINT);
> -- This triggers an ASSERT (because 2 is INTEGER and not BIGINT)
> INSERT INTO U(SNAME, TNAME, C1) SELECT DISTINCT SCHEMANAME, TABLENAME, 2
>  FROM SYS.SYSTABLES T JOIN SYS.SYSSCHEMAS S ON T.SCHEMAID = S.SCHEMAID;
> gives
> ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class 
> org.apache.derby.iapi.types.SQLInteger) expected to be the same as 
> col2.getClass() (class org.apache.derby.iapi.types.SQLLongint): 
> org.apache.derby.shared.common.sanity.AssertFailure'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3494) Move the setup of NormalizeResultSetNode into the NormalizeResultSetNode

[Bryan Pendleton (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577607#action_12577607
 ] 

Bryan Pendleton commented on DERBY-3494:


Very clear writeup, Army, thank you very much!

> 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, 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

[A B (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577610#action_12577610
 ] 

A B commented on DERBY-3494:


Thanks, as always, for the positive feedback, Bryan :)

> 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, 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.

Re: Not able to get in-place compression to release space to file system

[Mike Matrigali]

Is the data such that you can post the database?  If so does the db
zip to a managable size?

Have your recent attempts at in-place compress been single user?

What version are you using?


Øystein Grøvlen wrote:

Øystein Grøvlen wrote:


I have been experimenting a bit with in-place compression on a large
table, but I have not been successful in getting it to give back space
to the file system.  I have table that I have done a lot of bulk
changes to over time.  It is now much smaller than it was at its peak
size, but I am not able to reduce the size of the corresponding files
by in-place compression.  My last attempt:


I have now deleted all records in the table, but inplace compress does 
still not release any pages:


ij> select conglomeratename, isindex, numallocatedpages, numfreepages, 
pagesize, estimspacesaving from new 
org.apache.derby.diag.SpaceTable('T') t order by conglomeratename;

CONGLOMERATENAME
|ISIND&|NUMALLOCATEDPAGES   |NUMFREEPAGES|PAGESIZE 
|ESTIMSPACESAVING
-- 

T |0 |1 
 |419741  |4096   |1719259136
X_I |1 |131 
 |20105   |4096   |82350080


2 rows selected

Backport Request

[Manjula Kutty]

I was trying to run the junit tests on Z/OS platform with 10.3.2.2 and found
that it is hanging. Can any one please backport the change rev#  552046  to
10.3 so that I can just get to know where the test is hanging

-- 
Thanks,
Manjula.

Re: Backport Request

[Daniel John Debrunner]

Manjula Kutty wrote:
I was trying to run the junit tests on Z/OS platform with 10.3.2.2 
 and found that it is hanging. Can any one please 
backport the change rev# 
552046  to 10.3 so that I can just get to know where the test is hanging


As a general FYI - here's the wiki page on how to move changes between 
branches:


http://wiki.apache.org/db-derby/MoveAChangeBetweenBranches

(It's linked from a general how-to page on Derby development)
http://wiki.apache.org/db-derby/DerbyDevHowTo

Anyone can merge a change between branches and then build the source, it 
can help get a change back-ported quicker if someone has already tested 
it before a committer gets around to it.


Dan.

[jira] Updated: (DERBY-3382) Replication: Slave must inform master if DBs are out of sync.

[JIRA]

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

Jørgen Løland updated DERBY-3382:
-

Derby Info: [Patch Available]

> Replication: Slave must inform master if DBs are out of sync.
> -
>
> Key: DERBY-3382
> URL: https://issues.apache.org/jira/browse/DERBY-3382
> Project: Derby
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 10.4.0.0
>Reporter: Øystein Grøvlen
>Assignee: Jørgen Løland
> Fix For: 10.4.0.0
>
> Attachments: derby-3382-1a.diff, derby-3382-1a.stat, 
> derby-3382-1b.diff, derby-3382-1b.stat, derby-3382-test-1a.diff, 
> derby-3382-test-1a.stat
>
>
> If I copy the database to the slave before booting the master, slave will be 
> out of sync with the master since new log records are created during booting. 
>  The slave will then stop replication, but the master will not be notified.
> If I then try to stop or failover the master the master will hang.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1902) Intermittent failures in predicatePushdown.sql

[JIRA]

[ 
https://issues.apache.org/jira/browse/DERBY-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577725#action_12577725
 ] 

Jørgen Løland commented on DERBY-1902:
--

I saw this on Solaris 10/x86 on revision 635860:

*** Start: predicatePushdown jdk1.5.0_06 derbyall:derbylang 2008-03-11 15:34:04
***
4639 del
<   Hash Join ResultSet:
4639a4639
>   Nested Loop Join ResultSet:
4718 del
<   Hash Table ResultSet (11):
4718a4718
>   Sort ResultSet:
4720 del
<   Hash table size = 100
4721 del
<   Hash key is column number 0
4722 del
<   Rows seen = 104
4723 del
<   Rows filtered = 0


... and so on. I have the entire test directory intact if requested.

> Intermittent failures in predicatePushdown.sql
> --
>
> Key: DERBY-1902
> URL: https://issues.apache.org/jira/browse/DERBY-1902
> Project: Derby
>  Issue Type: Bug
>  Components: Regression Test Failure, SQL, Test
>Affects Versions: 10.3.1.4
> Environment: Seen on both Solaris 10 and Linux on 2-CPU Opteron 
> boxes, disk cache off
>Reporter: Øystein Grøvlen
> Attachments: derbylang.zip
>
>
> For the last week, there have been intermittent failures in the night test in 
> lang/predicatePushdown.sql.  There is a plan diff which starts as follows:
> * Diff file derbyall/derbylang/predicatePushdown.diff
> *** Start: predicatePushdown jdk1.5.0_07 derbyall:derbylang 2006-09-29 
> 00:39:36 ***
> 4593 del
> < Hash Join ResultSet:
> 4593a4593
> > Nested Loop Join ResultSet:
> I did not find any changes that seem relevant before the first failing night 
> test.
> This test has not failed in the tinderbox test which runs on a computer with 
> the disk cache on.  For both computers where the failure is seen, the disk 
> cache has been turned off.  Hence, it may be that another plan is picked 
> because of slower I/O.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.