[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[ https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301508#comment-14301508 ] Mamta A. Satoor commented on DERBY-6786: Hi Bryan, thanks for your suggestion. I was thinking of what you suggested when I was looking at possible fix but I do not think we know that we are going to do 2 phases of bind. May be there is a way to determine that but I haven't looked into that further. Also, I ran the junit suite and derbyall with my proposed change and everything ran fine. Additionally, I ran these two test suites with a println in JoinNode:buildRCL() in case we find that there is already a resultcolumn list built when we get in the method. And I found not just INSERT with join clause but also special instances of JOIN SELECTs which find that resultcolumn list is not null. I would suggest anyone with time to pursue this fix. I might not be able to get to this jira in near future. NullPointerException in INSERT INTO statement with multiple subselects -- Key: DERBY-6786 URL: https://issues.apache.org/jira/browse/DERBY-6786 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1, 10.11.1.1 Environment: not relevant, but tested under Windows 7 32bit, Windows Server 2008 64bit, Java 6 and Java 7. Reporter: Johannes Stadler Labels: NullPointerException Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql Hello, I'm getting this wrapped NullPointerException when I try to execute an INSERT INTO SQL statement: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711) at org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179) at de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49) at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28) Caused by: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) ... 12 more Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:370) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:436) ... 10 more Caused by: java.lang.NullPointerException at org.apache.derby.exe.acf81e0010x014axa9c2x46e6x00c6dc781.e2(Unknown Source) at org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:105) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:275) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:263) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127) at
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[
https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294886#comment-14294886
]
Mamta A. Satoor commented on DERBY-6786:
I have done more debugging and found that the code in JoinNode:buildRCL() is
what is causing for us to run into NPE.
The code here checks if we already have built a ResultColumnList. If yes, then
we leave the routine with no other work.
/* NOTE - we only need to build this list if it does not
already
* exist. This can happen in the degenerate case of an insert
* select with a join expression in a derived table within the
select.
*/
if (getResultColumns() != null)
{
return;
}
If the ResultColumnList for JoinNode is not built yet, we go through the
LeftResultSet's result column list and make a copy of it, build virtual nodes
on top of them and then we do the same with RightResultSet's result column list
and then we append thecopy of the right resultcolumns to the copy of the left
result columns and use it as JoinNode's result column list.
In case of our INSERT case, as described earlier in this jira, we go through
two cycles of binds. Once for the SELECT inside the INSERT statement and then
for the bind of INSERT statement itself(which causes the SELECT to rebind
itself). In the first iteration of bind of the SELECT, the JoinNode.buildRCL
will find the resultcolumn list to be null and hence we build a result column
list using left resultset and right resultset. The second time when we come
again for the bind of the SELECT, we find that the result column list already
exist and hence we just return from this method. But I believe what is
happening is that the resultset list built in the first cycle ends up having
virtual nodes created on top of it and that causes it to loose its column id. I
removed the if condition from JoinNode.buildRCL and we do not run into NPE with
the test cases provided here. I am going to enable the junit test case
zztestDerby6786InsertIntoSelectCase3 and see if it runs successfully. I will
also run the test case added for DERBY-6788. If they both pass, I will run our
junit suite and derbyall suite to see how things go.
This if condition has been there from Derby 10.1 days(and that is why we see
the failures in 10.1 codeline as well). But my guess is that the reason we have
the if condition in JoinNode.buildRCL is to avoid recreating the result column
list. But it looks like, it should be ok to remove the if statement and let the
result column list to be built again during the second round of the bind of
SELECT in case of INSERT statement.
NullPointerException in INSERT INTO statement with multiple subselects
--
Key: DERBY-6786
URL: https://issues.apache.org/jira/browse/DERBY-6786
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1,
10.11.1.1
Environment: not relevant, but tested under Windows 7 32bit, Windows
Server 2008 64bit, Java 6 and Java 7.
Reporter: Johannes Stadler
Labels: NullPointerException
Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql
Hello,
I'm getting this wrapped NullPointerException when I try to execute an INSERT
INTO SQL statement:
java.sql.SQLException: The exception 'java.lang.NullPointerException' was
thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179)
at
de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49)
at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28)
Caused by:
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[
https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287115#comment-14287115
]
Mamta A. Satoor commented on DERBY-6786:
So this is where the column mapping seems to go wrong but the comment seems to
say that if this work was not done, the mappings will be wrong. Here is the
code from JoinNode.java:getMatchingColumn:603
/* Insert will bind the underlying result sets which have
* tables twice. On the 2nd bind, resultColumns != null,
* we must return the RC from the JoinNode's RCL which is above
* the RC that we just found above. (Otherwise, the source
* for the ColumnReference will be from the wrong ResultSet
* at generate().)
*/
if (getResultColumns() != null)
{
for (ResultColumn rc : getResultColumns())
{
VirtualColumnNode vcn = (VirtualColumnNode)
rc.getExpression();
if (resultColumn == vcn.getSourceColumn())
{
resultColumn = rc;
break;
}
}
}
The if condition above will be false for the test case with no INSERT. But in
case of INSERT, we will go inside the if code and regenerate the virtual nodes
with different column positions. This code has been in there since 10.1
codeline and may be that explains why this has failed all the way back in 10.1
codeline
NullPointerException in INSERT INTO statement with multiple subselects
--
Key: DERBY-6786
URL: https://issues.apache.org/jira/browse/DERBY-6786
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1,
10.11.1.1
Environment: not relevant, but tested under Windows 7 32bit, Windows
Server 2008 64bit, Java 6 and Java 7.
Reporter: Johannes Stadler
Labels: NullPointerException
Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql
Hello,
I'm getting this wrapped NullPointerException when I try to execute an INSERT
INTO SQL statement:
java.sql.SQLException: The exception 'java.lang.NullPointerException' was
thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179)
at
de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49)
at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28)
Caused by: java.sql.SQLException: The exception
'java.lang.NullPointerException' was thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
... 12 more
Caused by: java.sql.SQLException: Java exception: ':
java.lang.NullPointerException'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:370)
at
[jira] [Issue Comment Deleted] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[
https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-6786:
---
Comment: was deleted
(was: So this is where the column mapping seems to go wrong but the comment
seems to say that if this work was not done, the mappings will be wrong. Here
is the code from JoinNode.java:getMatchingColumn:603
/* Insert will bind the underlying result sets which have
* tables twice. On the 2nd bind, resultColumns != null,
* we must return the RC from the JoinNode's RCL which is above
* the RC that we just found above. (Otherwise, the source
* for the ColumnReference will be from the wrong ResultSet
* at generate().)
*/
if (getResultColumns() != null)
{
for (ResultColumn rc : getResultColumns())
{
VirtualColumnNode vcn = (VirtualColumnNode)
rc.getExpression();
if (resultColumn == vcn.getSourceColumn())
{
resultColumn = rc;
break;
}
}
}
The if condition above will be false for the test case with no INSERT. But in
case of INSERT, we will go inside the if code and regenerate the virtual nodes
with different column positions. This code has been in there since 10.1
codeline and may be that explains why this has failed all the way back in 10.1
codeline)
NullPointerException in INSERT INTO statement with multiple subselects
--
Key: DERBY-6786
URL: https://issues.apache.org/jira/browse/DERBY-6786
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1,
10.11.1.1
Environment: not relevant, but tested under Windows 7 32bit, Windows
Server 2008 64bit, Java 6 and Java 7.
Reporter: Johannes Stadler
Labels: NullPointerException
Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql
Hello,
I'm getting this wrapped NullPointerException when I try to execute an INSERT
INTO SQL statement:
java.sql.SQLException: The exception 'java.lang.NullPointerException' was
thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179)
at
de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49)
at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28)
Caused by: java.sql.SQLException: The exception
'java.lang.NullPointerException' was thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
... 12 more
Caused by: java.sql.SQLException: Java exception: ':
java.lang.NullPointerException'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:370)
at
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[ https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287557#comment-14287557 ] Mamta A. Satoor commented on DERBY-6786: Thanks Bryan for the tip. I normally do System.out.println and then print stack trace but I like your one statement to do both. Thanks again. NullPointerException in INSERT INTO statement with multiple subselects -- Key: DERBY-6786 URL: https://issues.apache.org/jira/browse/DERBY-6786 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1, 10.11.1.1 Environment: not relevant, but tested under Windows 7 32bit, Windows Server 2008 64bit, Java 6 and Java 7. Reporter: Johannes Stadler Labels: NullPointerException Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql Hello, I'm getting this wrapped NullPointerException when I try to execute an INSERT INTO SQL statement: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711) at org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179) at de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49) at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28) Caused by: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) ... 12 more Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:370) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:436) ... 10 more Caused by: java.lang.NullPointerException at org.apache.derby.exe.acf81e0010x014axa9c2x46e6x00c6dc781.e2(Unknown Source) at org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:105) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:275) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:263) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:519) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:461) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:340) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1344) ... 5 more Most likely this bug has already been reported as DERBY-5041, which has already been closed (although I don't use a GROUP BY clause). The original statement is quite complex and partially generated, but the error can be reproduced easily, using a
[jira] [Comment Edited] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[ https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14284548#comment-14284548 ] Mamta A. Satoor edited comment on DERBY-6786 at 1/20/15 10:33 PM: -- I have been debugging this issue a little bit and what I have found so far in the case with INSERT and in the case with no INSERT is that the case with INSERT goes through additional cycle of binding of the SELECT clause. Here are the two cases 1)With INSERT insert into t select erg.* from ( select d2.s from (select k,s from k1) as d1 left join (select k,s from k2) as d2 on d1.k=d2.k ) as erg where s 10; 2)Without INSERT select erg.* from ( select d2.s from (select k,s from k1) as d1 left join (select k,s from k2) as d2 on d1.k=d2.k ) as erg where s 10; In both of the cases above, first we go through the bind phase of SELECT erg.*... first. 1)In case with INSERT, here is the code path for the first round of binding of SELECT erg,*... SelectNode.bindExpressions(FromList) line: 549 SelectNode.bindExpressionsWithTables(FromList) line: 738 InsertNode(DMLStatementNode).bindExpressionsWithTables() line: 232 InsertNode(DMLStatementNode).bindResultSetsWithTables(DataDictionary) line: 165 InsertNode.bindStatement() line: 246 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 401 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 99 . 2)In case of no INSERT sql, here is the code path for the binding of SELECT erg,*... CursorNode.bindStatement() line: 283 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 401 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 99 At the end of this, the query nodes for the two queries seem to be in sync. But, for the case with INSERT, we go through the bind phase of SELECT erg.* again through the following codepath SelectNode.bindExpressions(FromList) line: 523 InsertNode(DMLStatementNode).bindExpressions() line: 209 InsertNode.bindStatement() line: 338 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 401 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 99 There is following comment before this second round of binding in InsertNode.bindStatement() /* Bind the expressions now that the result columns are bound * NOTE: This will be the 2nd time for those underlying ResultSets * that have tables (no harm done), but it is necessary for those * that do not have tables. It's too hard/not work the effort to * avoid the redundancy. */ It is in this second phase of rounding, it looks like we bind the columns to incorrect position. More work is needed to pin point where exactly the column mapping is going wrong. was (Author: mamtas): I have been debugging this issue a little bit and what I have found so far in the case with INSERT and in the case with no INSERT is that the case with INSERT goes through additional cycle of binding of the SELECT clause. Here are the two cases 1)With INSERT insert into t select erg.* from ( select d2.s from (select k,s from k1) as d1 left join (select k,s from k2) as d2 on d1.k=d2.k ) as erg where s 10; 2)Without INSERT select erg.* from ( select d2.s from (select k,s from k1) as d1 left join (select k,s from k2) as d2 on d1.k=d2.k ) as erg where s 10; In both of the cases above, first we go through the bind phase of SELECT erg.*... first. 1)In case with INSERT, here is the code path for the first round of binding of SELECT erg,*... SelectNode.bindNonVTITables(DataDictionary, FromList) line: 490 InsertNode(DMLStatementNode).bindTables(DataDictionary) line: 190 InsertNode(DMLStatementNode).bindResultSetsWithTables(DataDictionary) line: 162 InsertNode.bindStatement() line: 246 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 401 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 99 . 2)In case of no INSERT sql, here is the code path for the binding of SELECT erg,*... CursorNode.bindStatement() line: 283 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 401 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 99 At the end of this, the query nodes for the two queries seem to be in sync. But, for the case with INSERT, we go through the bind phase of SELECT erg.* again through the following codepath SelectNode.bindExpressions(FromList) line: 523 InsertNode(DMLStatementNode).bindExpressions() line: 209 InsertNode.bindStatement() line: 338
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[ https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14284548#comment-14284548 ] Mamta A. Satoor commented on DERBY-6786: I have been debugging this issue a little bit and what I have found so far in the case with INSERT and in the case with no INSERT is that the case with INSERT goes through additional cycle of binding of the SELECT clause. Here are the two cases 1)With INSERT insert into t select erg.* from ( select d2.s from (select k,s from k1) as d1 left join (select k,s from k2) as d2 on d1.k=d2.k ) as erg where s 10; 2)Without INSERT select erg.* from ( select d2.s from (select k,s from k1) as d1 left join (select k,s from k2) as d2 on d1.k=d2.k ) as erg where s 10; In both of the cases above, first we go through the bind phase of SELECT erg.*... first. 1)In case with INSERT, here is the code path for the first round of binding of SELECT erg,*... SelectNode.bindNonVTITables(DataDictionary, FromList) line: 490 InsertNode(DMLStatementNode).bindTables(DataDictionary) line: 190 InsertNode(DMLStatementNode).bindResultSetsWithTables(DataDictionary) line: 162 InsertNode.bindStatement() line: 246 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 401 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 99 . 2)In case of no INSERT sql, here is the code path for the binding of SELECT erg,*... CursorNode.bindStatement() line: 283 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 401 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 99 At the end of this, the query nodes for the two queries seem to be in sync. But, for the case with INSERT, we go through the bind phase of SELECT erg.* again through the following codepath SelectNode.bindExpressions(FromList) line: 523 InsertNode(DMLStatementNode).bindExpressions() line: 209 InsertNode.bindStatement() line: 338 GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: 401 GenericStatement.prepare(LanguageConnectionContext, boolean) line: 99 There is following comment before this second round of binding in InsertNode.bindStatement() /* Bind the expressions now that the result columns are bound * NOTE: This will be the 2nd time for those underlying ResultSets * that have tables (no harm done), but it is necessary for those * that do not have tables. It's too hard/not work the effort to * avoid the redundancy. */ It is in this second phase of rounding, it looks like we bind the columns to incorrect position. More work is needed to pin point where exactly the column mapping is going wrong. NullPointerException in INSERT INTO statement with multiple subselects -- Key: DERBY-6786 URL: https://issues.apache.org/jira/browse/DERBY-6786 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1, 10.11.1.1 Environment: not relevant, but tested under Windows 7 32bit, Windows Server 2008 64bit, Java 6 and Java 7. Reporter: Johannes Stadler Labels: NullPointerException Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql Hello, I'm getting this wrapped NullPointerException when I try to execute an INSERT INTO SQL statement: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711) at org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179) at
[jira] [Comment Edited] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery
[
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14274193#comment-14274193
]
Mamta A. Satoor edited comment on DERBY-2238 at 1/12/15 9:24 PM:
-
Kim and Myrna, following is another example which is similar to the one we are
removing but is scalar subquery. Thanks
– Introduce a way of generating new data values,
– using a query which selects from a VALUES clause (which is an
– alternate form of a fullselect).
– This query shows how a table can be derived called X having
– 1 column R1 and 1 row of data.
SELECT R1
FROM (VALUES('GROUP 1')) as X(R1);
was (Author: mamtas):
Kim and Myrna, following is another example which is similar to the one we are
removing but is scalar. Thanks
– Introduce a way of generating new data values,
– using a query which selects from a VALUES clause (which is an
– alternate form of a fullselect).
– This query shows how a table can be derived called X having
– 1 column R1 and 1 row of data.
SELECT R1
FROM (VALUES('GROUP 1')) as X(R1);
Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery
--
Key: DERBY-2238
URL: https://issues.apache.org/jira/browse/DERBY-2238
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.2.2.0
Environment:
http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Assignee: Myrna van Lunteren
Labels: derby_triage10_11
Attachments: DERBY-2238.diff, rrefscalarsubquery.html
In the page, I found next example.
-- Introduce a way of generating new data values,
-- using a query which selects from a VALUES clause (which is an
-- alternate form of a fullselect).
-- This query shows how a table can be derived called X having
-- 2 columns R1 and R2 and 1 row of data.
SELECT R1,R2
FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
I think this is not ScalarSubquery because the result have two columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery
[
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14274193#comment-14274193
]
Mamta A. Satoor commented on DERBY-2238:
Kim and Myrna, following is another example which is similar to the one we are
removing but is scalar. Thanks
– Introduce a way of generating new data values,
– using a query which selects from a VALUES clause (which is an
– alternate form of a fullselect).
– This query shows how a table can be derived called X having
– 1 column R1 and 1 row of data.
SELECT R1
FROM (VALUES('GROUP 1')) as X(R1);
Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery
--
Key: DERBY-2238
URL: https://issues.apache.org/jira/browse/DERBY-2238
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.2.2.0
Environment:
http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Assignee: Myrna van Lunteren
Labels: derby_triage10_11
Attachments: DERBY-2238.diff, rrefscalarsubquery.html
In the page, I found next example.
-- Introduce a way of generating new data values,
-- using a query which selects from a VALUES clause (which is an
-- alternate form of a fullselect).
-- This query shows how a table can be derived called X having
-- 2 columns R1 and R2 and 1 row of data.
SELECT R1,R2
FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
I think this is not ScalarSubquery because the result have two columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6725) Add a system function which returns the name of the database.
[ https://issues.apache.org/jira/browse/DERBY-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14274824#comment-14274824 ] Mamta A. Satoor commented on DERBY-6725: The issue with my jar generation was what that I was compiling with jdk1.6 rather than jdk 1.8(thanks to Myrna's comment above in narrowing down the problem). To fix the problem, I reverted the changes that were made by jdk1.6 to *.lastcontents. Next, using jdk 1.8, I rebuilt the sane classes and then sane jars. But the jar creation ran into expected problem because I have added a new junit test with my changes as follows tstinginfowriter: [propertyfile] Updating property file: C:\p4clients\svnmain\client7\trunk\classes\org\apache\derby\info\tsting.properties [zip] Building zip: C:\p4clients\svnmain\client7\trunk\jars\insane\derbyTesting.jar jardriftcheck: [java] ERROR: class org.apache.derbyTesting.functionTests.tests.lang.Derby6725GetDatabaseName.class in [java]derbyTesting.jar was not previously there. [java] [java] Exception in thread main java.lang.Exception: [java] jar drift check failed; see DERBY-6471 for info. [java] See error in build output or call ant jardriftcheck. [java] If the new class is expected run ant refreshjardriftcheck. [java] NB: Run the refresh for both sane and insane builds. [java] Use the highest supported JVM (currently Java 8) [java] to ensure all classes are built. [java] [java] at org.apache.derbyBuild.JarDriftTest.main(Unknown Source) BUILD FAILED To fix this, as per the instructions above, I ran ant refreshjardriftcheck and then built the jar files and this time, the jar files got created successfully. And there was only one .lastcontents was changed this time ( java\build\org\apache\derbyBuild\lastgoodjarcontents\sane.derbyTesting.jar.lastcontents) because of the new junit test addition. I repeated the same steps for insane jars. The error message from refreshjardriftcheck does mention to use the highest supported JVM but I have to admit I didn't quite understand what it meant by to ensure all classes are built when I first ran into issues with jdk1.6 derby build. Add a system function which returns the name of the database. - Key: DERBY-6725 URL: https://issues.apache.org/jira/browse/DERBY-6725 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.12.0.0 Reporter: Rick Hillegas Assignee: Mamta A. Satoor Attachments: DERBY6725_getdbname_patch1_diff.txt, DERBY6725_getdbname_patch1_stat.txt Got this request in private conversation with a user. Other databases provide this functionality. Seems straightforward to add. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery
[
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14273912#comment-14273912
]
Mamta A. Satoor commented on DERBY-2238:
There are two examples on the page mentioned by Tomohito. They are as follows
Examples
-- avg always returns a single value, so the subquery is
-- a scalarSubquery
SELECT NAME, COMM
FROM STAFF
WHERE EXISTS
(SELECT AVG(BONUS + 800)
FROM EMPLOYEE
WHERE COMM 5000
AND EMPLOYEE.LASTNAME = UPPER(STAFF.NAME)
)
-- Introduce a way of generating new data values,
-- using a query which selects from a VALUES clause (which is an
-- alternate form of a fullselect).
-- This query shows how a table can be derived called X having
-- 2 columns R1 and R2 and 1 row of data.
SELECT R1,R2
FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
Of this, I believe the first example is correct since that is an example of
scalar subquery being used in the WHERE clause. But Kim is correct about the
second example being wrong as it is not as example of scalar query and there is
no subquery in that example. We should delete the second example. Thanks.
Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery
--
Key: DERBY-2238
URL: https://issues.apache.org/jira/browse/DERBY-2238
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.2.2.0
Environment:
http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Labels: derby_triage10_11
In the page, I found next example.
-- Introduce a way of generating new data values,
-- using a query which selects from a VALUES clause (which is an
-- alternate form of a fullselect).
-- This query shows how a table can be derived called X having
-- 2 columns R1 and R2 and 1 row of data.
SELECT R1,R2
FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
I think this is not ScalarSubquery because the result have two columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DERBY-6725) Add a system function which returns the name of the database.
[ https://issues.apache.org/jira/browse/DERBY-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6725: --- Attachment: DERBY6725_getdbname_patch1_stat.txt DERBY6725_getdbname_patch1_diff.txt Attaching a patch which adds a new system function to get the name of the database. I added a new junit test for this feature which ends up adding a new class to derby testing jar. Building of jars prompted me to run ant refreshjardriftcheck because of the changes in the jar file. After running ant refreshjardriftcheck, I was able to create the jar files. I thought though the only changes I would see in *.lastcontents would be addition of the new test added by me but I see several other diffs in *.lastcontents file that I am not sure why they are there. Will appreciate if someone more familiar with refreshjardriftcheck can make sure everything is fine? I will commit in couple days. Thanks Add a system function which returns the name of the database. - Key: DERBY-6725 URL: https://issues.apache.org/jira/browse/DERBY-6725 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.12.0.0 Reporter: Rick Hillegas Assignee: Mamta A. Satoor Attachments: DERBY6725_getdbname_patch1_diff.txt, DERBY6725_getdbname_patch1_stat.txt Got this request in private conversation with a user. Other databases provide this functionality. Seems straightforward to add. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[
https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265822#comment-14265822
]
Mamta A. Satoor commented on DERBY-6786:
While looking at the issue, I found that the queries from repro sql do not
result into NPE if the data in the tables is different.
create table k1 (k varchar(64), s decimal);
create table k2 (k varchar(64), s decimal);
create table t (s decimal);
insert into k1 values ('110007', 224);
insert into k2 values ('110007', 361);
Note that both the tables above has same value for column k and thus join will
actually result in matching rows.
Now for all the 4 queries provided in repro case by Johannes will actually find
a matching row and for such a data, there is no NPE. In the case where no
matching row is found, issue might be that Derby is not equipped to handle such
a case for the 2 queries provided in the repro.
NullPointerException in INSERT INTO statement with multiple subselects
--
Key: DERBY-6786
URL: https://issues.apache.org/jira/browse/DERBY-6786
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1,
10.11.1.1
Environment: not relevant, but tested under Windows 7 32bit, Windows
Server 2008 64bit, Java 6 and Java 7.
Reporter: Johannes Stadler
Labels: NullPointerException
Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql
Hello,
I'm getting this wrapped NullPointerException when I try to execute an INSERT
INTO SQL statement:
java.sql.SQLException: The exception 'java.lang.NullPointerException' was
thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179)
at
de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49)
at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28)
Caused by: java.sql.SQLException: The exception
'java.lang.NullPointerException' was thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
... 12 more
Caused by: java.sql.SQLException: Java exception: ':
java.lang.NullPointerException'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:370)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:436)
... 10 more
Caused by: java.lang.NullPointerException
at
org.apache.derby.exe.acf81e0010x014axa9c2x46e6x00c6dc781.e2(Unknown
Source)
at
org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:105)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:275)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:263)
at
org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127)
at
org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:519)
[jira] [Comment Edited] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[
https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265822#comment-14265822
]
Mamta A. Satoor edited comment on DERBY-6786 at 1/6/15 8:17 AM:
While looking at the issue, I found that the queries from repro sql do not
result into NPE if the data in the tables is different.
create table k1 (k varchar(64), s decimal);
create table k2 (k varchar(64), s decimal);
create table t (s decimal);
insert into k1 values ('110007', 224);
insert into k2 values ('110007', 361);
Note that both the tables above have same value for column k and thus join will
actually result in matching rows.
Now for all the 4 queries provided in repro case by Johannes will actually find
a matching row and for such a data, there is no NPE.
In the case where no matching row is found(which is the case with the data set
provided in the repro case by Johannes), issue might be that Derby is not
equipped to handle empty resultset for the 2 queries provided in the repro.
was (Author: mamtas):
While looking at the issue, I found that the queries from repro sql do not
result into NPE if the data in the tables is different.
create table k1 (k varchar(64), s decimal);
create table k2 (k varchar(64), s decimal);
create table t (s decimal);
insert into k1 values ('110007', 224);
insert into k2 values ('110007', 361);
Note that both the tables above has same value for column k and thus join will
actually result in matching rows.
Now for all the 4 queries provided in repro case by Johannes will actually find
a matching row and for such a data, there is no NPE. In the case where no
matching row is found, issue might be that Derby is not equipped to handle such
a case for the 2 queries provided in the repro.
NullPointerException in INSERT INTO statement with multiple subselects
--
Key: DERBY-6786
URL: https://issues.apache.org/jira/browse/DERBY-6786
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1,
10.11.1.1
Environment: not relevant, but tested under Windows 7 32bit, Windows
Server 2008 64bit, Java 6 and Java 7.
Reporter: Johannes Stadler
Labels: NullPointerException
Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql
Hello,
I'm getting this wrapped NullPointerException when I try to execute an INSERT
INTO SQL statement:
java.sql.SQLException: The exception 'java.lang.NullPointerException' was
thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179)
at
de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49)
at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28)
Caused by: java.sql.SQLException: The exception
'java.lang.NullPointerException' was thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
... 12 more
Caused by: java.sql.SQLException: Java exception: ':
java.lang.NullPointerException'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[ https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266901#comment-14266901 ] Mamta A. Satoor commented on DERBY-6786: Hopefully the information I shared earlier is useful. I am working on other issues currently and hence will not be able to spend much time on this issue at this time. NullPointerException in INSERT INTO statement with multiple subselects -- Key: DERBY-6786 URL: https://issues.apache.org/jira/browse/DERBY-6786 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1, 10.11.1.1 Environment: not relevant, but tested under Windows 7 32bit, Windows Server 2008 64bit, Java 6 and Java 7. Reporter: Johannes Stadler Labels: NullPointerException Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql Hello, I'm getting this wrapped NullPointerException when I try to execute an INSERT INTO SQL statement: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711) at org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179) at de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49) at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28) Caused by: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) ... 12 more Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:370) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:436) ... 10 more Caused by: java.lang.NullPointerException at org.apache.derby.exe.acf81e0010x014axa9c2x46e6x00c6dc781.e2(Unknown Source) at org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:105) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:275) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:263) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:519) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:461) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:340) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1344) ... 5 more Most likely this bug has already been reported as DERBY-5041, which has already been closed (although I don't use a GROUP BY clause). The original statement is quite complex and partially generated, but the error can be
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[
https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266802#comment-14266802
]
Mamta A. Satoor commented on DERBY-6786:
You are correct Johannes. Just want to share some more information from my
debugging which enforces your point.
First of all, for reference purposes, here are the tables we are dealing with
following tables
create table k1 (k varchar(64), s decimal);
create table k2 (k varchar(64), s decimal);
create table t (s decimal);
And one of the queries that may result in npe (depending on what data is in the
tables) is as follows
insert into t
select erg.* from (
select d2.s from (select k,s from k1) as d1
left join (select k,s from k2) as d2 on d1.k=d2.k
) as erg
where s 10;
For the query above, we generate various internal Derby resultsets. The issue
appears to be what resultset gets associated to column s in predicate where s
10. It would seem that for this predicate, column s should be associated with
the internal resulset created for outermost select which is select erg.*.
Instead, it looks like it is getting associated with the 2nd select in the join
clause which is (select k,s from k2) as d2
Lets look at the contents of these two internal resultsets for different data
in tables k1 and k2 to understand the NPE better.
case 1)
Let's say the only data into the two tables is
delete from k1;
delete from k2;
insert into k1 values ('110007', 224);
insert into k2 values ('110007', 361);
For this data, the join above will result into a match because both k1 and k2
have '110007' for column k. The contents of resultset for (select k,s from k2)
as d2 is { 110007, 361 } and the merged row looks like { 110007, 224, 110007,
361 }. Here, even though predicate column s is incorrectly associated with
internal resultset for (select k,s from k2) as d2, we will not get a npe
because that resultset for the given data is not null(because there was a
matching row in table k2.)
Case 2)
Let's say the only data into the two tables is
delete from k1;
delete from k2;
insert into k1 values ('110007', 224);
insert into k2 values ('110007', null);
Again, for this data, the join above will result into a match because both k1
and k2 have '110007' for column k. The contents of resultset for (select k,s
from k2) as d2 is { 110007, NULL } and the merged row looks like { 110007, 224,
110007, 361 }. For this case again, we will not get a npe because the resultset
associated with (select k,s from k2) as d2 is not null (because there was a
matching row in table k2.)
Case 3)
This is the case where we run into NPE.
Let's say the only data into the two tables is
delete from k1;
delete from k2;
insert into k1 values ('110007', 224);
insert into k2 values ('110019', 361);
For this data, the join above will not find a matching row in k2. Because of
this, the resultset associated with (select k,s from k2) as d2 will be null but
the merged row will look like { 110007, 224, NULL, NULL }. Predicate where s
10 association with resultset for (select k,s from k2) as d2 I believe is the
cause of npe. It seems like we should be looking at the merged row resultset to
find predicate s's value. Doing that will work for all the 3 cases covered
here.
It will appear that to fix the issue, we will need to fix the predicate's
assoication with correct resulset and that will automatically generate the
correct run time behavior.
NullPointerException in INSERT INTO statement with multiple subselects
--
Key: DERBY-6786
URL: https://issues.apache.org/jira/browse/DERBY-6786
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1,
10.11.1.1
Environment: not relevant, but tested under Windows 7 32bit, Windows
Server 2008 64bit, Java 6 and Java 7.
Reporter: Johannes Stadler
Labels: NullPointerException
Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql
Hello,
I'm getting this wrapped NullPointerException when I try to execute an INSERT
INTO SQL statement:
java.sql.SQLException: The exception 'java.lang.NullPointerException' was
thrown while evaluating an expression.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
at
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[ https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264899#comment-14264899 ] Mamta A. Satoor commented on DERBY-6786: Thanks for providing the repro. I tried it on top of the trunk and was able to reproduce the behavior you noticed. NullPointerException in INSERT INTO statement with multiple subselects -- Key: DERBY-6786 URL: https://issues.apache.org/jira/browse/DERBY-6786 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1, 10.11.1.1 Environment: not relevant, but tested under Windows 7 32bit, Windows Server 2008 64bit, Java 6 and Java 7. Reporter: Johannes Stadler Labels: NullPointerException Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql Hello, I'm getting this wrapped NullPointerException when I try to execute an INSERT INTO SQL statement: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711) at org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179) at de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49) at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28) Caused by: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) ... 12 more Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:370) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:436) ... 10 more Caused by: java.lang.NullPointerException at org.apache.derby.exe.acf81e0010x014axa9c2x46e6x00c6dc781.e2(Unknown Source) at org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:105) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:275) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:263) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:519) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:461) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:340) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1344) ... 5 more Most likely this bug has already been reported as DERBY-5041, which has already been closed (although I don't use a GROUP BY clause). The original statement is quite complex and partially generated, but the error can be reproduced easily, using a statement as simple as this:
[jira] [Commented] (DERBY-6786) NullPointerException in INSERT INTO statement with multiple subselects
[ https://issues.apache.org/jira/browse/DERBY-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264981#comment-14264981 ] Mamta A. Satoor commented on DERBY-6786: I am looking at the code to see if I can understand what the issue might be. NullPointerException in INSERT INTO statement with multiple subselects -- Key: DERBY-6786 URL: https://issues.apache.org/jira/browse/DERBY-6786 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0, 10.5.1.1, 10.8.2.2, 10.9.1.0, 10.10.1.1, 10.11.1.1 Environment: not relevant, but tested under Windows 7 32bit, Windows Server 2008 64bit, Java 6 and Java 7. Reporter: Johannes Stadler Labels: NullPointerException Attachments: acaaeec04ex014axaa2ex076bx00c72a081.java, repro.sql Hello, I'm getting this wrapped NullPointerException when I try to execute an INSERT INTO SQL statement: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:101) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:349) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:85) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1437) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:711) at org.apache.derby.impl.jdbc.EmbedStatement.executeLargeUpdate(EmbedStatement.java:190) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179) at de.foconis.dakobp.unittests.div.TestMain.testNullpointer(TestMain.java:49) at de.foconis.dakobp.unittests.div.TestMain.main(TestMain.java:28) Caused by: java.sql.SQLException: The exception 'java.lang.NullPointerException' was thrown while evaluating an expression. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) ... 12 more Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:125) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:370) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:436) ... 10 more Caused by: java.lang.NullPointerException at org.apache.derby.exe.acf81e0010x014axa9c2x46e6x00c6dc781.e2(Unknown Source) at org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:105) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:275) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:263) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:519) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:461) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:340) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1344) ... 5 more Most likely this bug has already been reported as DERBY-5041, which has already been closed (although I don't use a GROUP BY clause). The original statement is quite complex and partially generated, but the error can be reproduced easily, using a statement as simple as this: insert into t select erg.* from (
[jira] [Commented] (DERBY-6783) WHEN clause in CREATE TRIGGER for UPDATE is not working for the sql script below
[ https://issues.apache.org/jira/browse/DERBY-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14250299#comment-14250299 ] Mamta A. Satoor commented on DERBY-6783: WHEN clause was added in release 10.11 so this issue is specific to 10.11. WHEN clause in CREATE TRIGGER for UPDATE is not working for the sql script below Key: DERBY-6783 URL: https://issues.apache.org/jira/browse/DERBY-6783 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.1.1 Reporter: Mamta A. Satoor Following sql script was shared on derby-user(http://mail-archives.apache.org/mod_mbox/db-derby-user/201412.mbox/%3c548aba6d.8000...@zoho.com%3e). The UPDATE TRIGGER with the WHEN clause below does not fire as expected. Same script works fine on DB2. ij version 10.11 ij connect 'jdbc:derby:MyDbTest;create=true'; ij CREATE TABLE t1 (id INTEGER, done_date DATE, status CHAR(1)); 0 rows inserted/updated/deleted ij CREATE TRIGGER tr1 AFTER UPDATE OF status ON t1 REFERENCING NEW AS newrow FOR EACH ROW WHEN (newrow.status='d') UPDATE t1 SET done_date=current_date WHERE id=newrow.id; 0 rows inserted/updated/deleted ij insert into t1 values (1, null, 'a'); 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |a 1 row selected ij UPDATE t1 SET status='d'; 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |d 1 row selected ij exit; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6778) SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport
[ https://issues.apache.org/jira/browse/DERBY-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14244574#comment-14244574 ] Mamta A. Satoor commented on DERBY-6778: Checked the 10.8 runs at http://people.apache.org/~myrnavl/derby_test_results/ and the tests ran fine with no SSL test failures. SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport Key: DERBY-6778 URL: https://issues.apache.org/jira/browse/DERBY-6778 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.3 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.8.3.3 Attachments: DERBY6778_patch1_diff.txt DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) was fixed in 10.12 codeline. The backport of the fix to 10.8(other codelines do not have this issue) has caused SSL related tests to fail on 10.8 codeline with IBM jdk 1.4.2. This jira is created to provide a fix on 10.8 codeline for IBM jdk 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DERBY-6783) WHEN clause in CREATE TRIGGER for UPDATE is not working for the sql script below
Mamta A. Satoor created DERBY-6783: -- Summary: WHEN clause in CREATE TRIGGER for UPDATE is not working for the sql script below Key: DERBY-6783 URL: https://issues.apache.org/jira/browse/DERBY-6783 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.1.1 Reporter: Mamta A. Satoor Following sql script was shared on derby-user. The UPDATE TRIGGER with the WHEN clause does not fire as expected. Same script works fine on DB2. ij version 10.11 ij connect 'jdbc:derby:MyDbTest;create=true'; ij CREATE TABLE t1 (id INTEGER, done_date DATE, status CHAR(1)); 0 rows inserted/updated/deleted ij CREATE TRIGGER tr1 AFTER UPDATE OF status ON t1 REFERENCING NEW AS newrow FOR EACH ROW WHEN (newrow.status='d') UPDATE t1 SET done_date=current_date WHERE id=newrow.id; 0 rows inserted/updated/deleted ij insert into t1 values (1, null, 'a'); 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |a 1 row selected ij UPDATE t1 SET status='d'; 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |d 1 row selected ij exit; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6783) WHEN clause in CREATE TRIGGER for UPDATE is not working for the sql script below
[ https://issues.apache.org/jira/browse/DERBY-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6783: --- Description: Following sql script was shared on derby-user(http://mail-archives.apache.org/mod_mbox/db-derby-user/201412.mbox/%3c548aba6d.8000...@zoho.com%3e). The UPDATE TRIGGER with the WHEN clause below does not fire as expected. Same script works fine on DB2. ij version 10.11 ij connect 'jdbc:derby:MyDbTest;create=true'; ij CREATE TABLE t1 (id INTEGER, done_date DATE, status CHAR(1)); 0 rows inserted/updated/deleted ij CREATE TRIGGER tr1 AFTER UPDATE OF status ON t1 REFERENCING NEW AS newrow FOR EACH ROW WHEN (newrow.status='d') UPDATE t1 SET done_date=current_date WHERE id=newrow.id; 0 rows inserted/updated/deleted ij insert into t1 values (1, null, 'a'); 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |a 1 row selected ij UPDATE t1 SET status='d'; 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |d 1 row selected ij exit; was: Following sql script was shared on derby-user. The UPDATE TRIGGER with the WHEN clause does not fire as expected. Same script works fine on DB2. ij version 10.11 ij connect 'jdbc:derby:MyDbTest;create=true'; ij CREATE TABLE t1 (id INTEGER, done_date DATE, status CHAR(1)); 0 rows inserted/updated/deleted ij CREATE TRIGGER tr1 AFTER UPDATE OF status ON t1 REFERENCING NEW AS newrow FOR EACH ROW WHEN (newrow.status='d') UPDATE t1 SET done_date=current_date WHERE id=newrow.id; 0 rows inserted/updated/deleted ij insert into t1 values (1, null, 'a'); 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |a 1 row selected ij UPDATE t1 SET status='d'; 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |d 1 row selected ij exit; WHEN clause in CREATE TRIGGER for UPDATE is not working for the sql script below Key: DERBY-6783 URL: https://issues.apache.org/jira/browse/DERBY-6783 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.1.1 Reporter: Mamta A. Satoor Following sql script was shared on derby-user(http://mail-archives.apache.org/mod_mbox/db-derby-user/201412.mbox/%3c548aba6d.8000...@zoho.com%3e). The UPDATE TRIGGER with the WHEN clause below does not fire as expected. Same script works fine on DB2. ij version 10.11 ij connect 'jdbc:derby:MyDbTest;create=true'; ij CREATE TABLE t1 (id INTEGER, done_date DATE, status CHAR(1)); 0 rows inserted/updated/deleted ij CREATE TRIGGER tr1 AFTER UPDATE OF status ON t1 REFERENCING NEW AS newrow FOR EACH ROW WHEN (newrow.status='d') UPDATE t1 SET done_date=current_date WHERE id=newrow.id; 0 rows inserted/updated/deleted ij insert into t1 values (1, null, 'a'); 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |a 1 row selected ij UPDATE t1 SET status='d'; 1 row inserted/updated/deleted ij SELECT * FROM t1; ID |DONE_DATE |STA --- 1 |NULL |d 1 row selected ij exit; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6778) SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport
[ https://issues.apache.org/jira/browse/DERBY-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6778: --- Issue fix info: (was: Patch Available) Fix Version/s: 10.8.3.3 SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport Key: DERBY-6778 URL: https://issues.apache.org/jira/browse/DERBY-6778 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.3 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.8.3.3 Attachments: DERBY6778_patch1_diff.txt DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) was fixed in 10.12 codeline. The backport of the fix to 10.8(other codelines do not have this issue) has caused SSL related tests to fail on 10.8 codeline with IBM jdk 1.4.2. This jira is created to provide a fix on 10.8 codeline for IBM jdk 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6778) SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport
[ https://issues.apache.org/jira/browse/DERBY-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243053#comment-14243053 ] Mamta A. Satoor commented on DERBY-6778: I have checked in the fix for the issue. This fix should not be moved to any other codeline because the fix is specifically for IBM jdk 1.4.2. I do not believe Derby 10.9 and higher support jdk 1.4.2. In any case, 1.4 is a very old jdk and most likely nobody is using it even with Derby 10.8 SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport Key: DERBY-6778 URL: https://issues.apache.org/jira/browse/DERBY-6778 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.3 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.8.3.3 Attachments: DERBY6778_patch1_diff.txt DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) was fixed in 10.12 codeline. The backport of the fix to 10.8(other codelines do not have this issue) has caused SSL related tests to fail on 10.8 codeline with IBM jdk 1.4.2. This jira is created to provide a fix on 10.8 codeline for IBM jdk 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-6778) SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport
[ https://issues.apache.org/jira/browse/DERBY-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-6778. Resolution: Fixed SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport Key: DERBY-6778 URL: https://issues.apache.org/jira/browse/DERBY-6778 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.3 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.8.3.3 Attachments: DERBY6778_patch1_diff.txt DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) was fixed in 10.12 codeline. The backport of the fix to 10.8(other codelines do not have this issue) has caused SSL related tests to fail on 10.8 codeline with IBM jdk 1.4.2. This jira is created to provide a fix on 10.8 codeline for IBM jdk 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6778) SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport
[ https://issues.apache.org/jira/browse/DERBY-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6778: --- Attachment: DERBY6778_patch1_diff.txt Attaching patch DERBY6778_patch1_diff.txt which disables poodle security work for IBM jdk 1.4.2. This change will only go in 10.8 codeline and for IBM jdk 1.4.2. Derby will continue to have poodle security work for the rest other jvms. Please let me know if there are any comments. On my machine, junit suite did not run into SSL test failures with IBM jdk 1.4.2 after these changes. Running derbyall currently. Will run these tests with other jvm to make sure those jvms work fine. SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport Key: DERBY-6778 URL: https://issues.apache.org/jira/browse/DERBY-6778 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.3 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Attachments: DERBY6778_patch1_diff.txt DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) was fixed in 10.12 codeline. The backport of the fix to 10.8(other codelines do not have this issue) has caused SSL related tests to fail on 10.8 codeline with IBM jdk 1.4.2. This jira is created to provide a fix on 10.8 codeline for IBM jdk 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6778) SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport
[ https://issues.apache.org/jira/browse/DERBY-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6778: --- Issue fix info: Patch Available SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport Key: DERBY-6778 URL: https://issues.apache.org/jira/browse/DERBY-6778 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.3 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Attachments: DERBY6778_patch1_diff.txt DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) was fixed in 10.12 codeline. The backport of the fix to 10.8(other codelines do not have this issue) has caused SSL related tests to fail on 10.8 codeline with IBM jdk 1.4.2. This jira is created to provide a fix on 10.8 codeline for IBM jdk 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DERBY-6778) SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport
Mamta A. Satoor created DERBY-6778: -- Summary: SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport Key: DERBY-6778 URL: https://issues.apache.org/jira/browse/DERBY-6778 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.3 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) was fixed in 10.12 codeline. The backport of the fix to 10.8(other codelines do not have this issue) has caused SSL related tests to fail on 10.8 codeline with IBM jdk 1.4.2. This jira is created to provide a fix on 10.8 codeline for IBM jdk 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6778) SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport
[ https://issues.apache.org/jira/browse/DERBY-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240777#comment-14240777 ] Mamta A. Satoor commented on DERBY-6778: I have been debugging the failures as found at http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm142/1643050-suites.All_diff.txt and http://people.apache.org/~myrnavl/derby_test_results/v10_8/linux/testlog/ibm142/1643044-suites.All_diff.txt The issue is very specific to IBM Jdk 1.4.2 and does not happen with other higher jdks. The problem can be reproduced by starting the Network Server on 10.8 codeline with IBM jdk 1.4.2 and pinging that server will result in handshake failure. eg 1)Start the server java -Djavax.net.ssl.keyStore=SSLTestServerKey.key -Djavax.net.ssl.keyStorePassword=qwerty org.apache.derby.drda.NetworkServerControl -p 1529 start -ssl basic 2)ping the server java -Djavax.net.ssl.keyStore=SSLTestServerKey.key -Djavax.net.ssl.keyStorePassword=qwerty org.apache.derby.drda.NetworkServerControl -p 1529 ping -ssl basic Note that I have SSLTestServerKey.key in my directory in order to user SSL basic configuration. I tried the same experiment with Derby 10.8 network server with IBM jdk1.4.2 but the ping coming from a higher jdk and it gave little more useful information about server trying to use the disabled SSLv3 server and thus causing the handshake between client and server to fail. In order to resolve this issue specific with IBM jdk1.4.2, I am working on 10.8 codeline to disable the poodle security fix in 10.8 codeline just for IBM jdk1.4.2. Hopefully since Jdk 1.4.2 is so old, there are no many people still using it and hence they will not risk into poodle security. After the tests have run successfully on jdk1.4.2 and higher jdk with my changes, I will commit it. I will post the patch for review tomorrow. SSL tests are failing on 10.8 codeline with IBM jdk 1.4.2 after poodle security backport Key: DERBY-6778 URL: https://issues.apache.org/jira/browse/DERBY-6778 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.3 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) was fixed in 10.12 codeline. The backport of the fix to 10.8(other codelines do not have this issue) has caused SSL related tests to fail on 10.8 codeline with IBM jdk 1.4.2. This jira is created to provide a fix on 10.8 codeline for IBM jdk 1.4.2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column
[ https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14238873#comment-14238873 ] Mamta A. Satoor commented on DERBY-6753: Myrna, changes look good. Thanks for working on it. Just one bit of feedback. In the change below, we should say that UPDATE statement should be issued on a table containing an identity column. This will be similar to what we already say for INSERT. @@ -31,20 +31,23 @@ identity column./p pThe value returned by the IDENTITY_VAL_LOCAL function, for a connection, is the value assigned to the identity column of the table identified in the -most recent single row INSERT statement. The INSERT statement must contain +most recent single row INSERT or UPDATE statement. The INSERT statement must contain a VALUES clause on a table containing an identity column. Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column -- Key: DERBY-6753 URL: https://issues.apache.org/jira/browse/DERBY-6753 Project: Derby Issue Type: Task Components: Documentation Affects Versions: 10.12.0.0 Environment: Changes for DERBY-6742 will now make the newly generated value for a single row UPDATE statement available through IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very localized and from my search, the changes need to go only in the reference manual. Basically, DERBY-6414 now allows an identity column's value to be updated using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no way of updating an identity column). This updated value is available through IDENTITY_VAL_LOCAL if only one row was updated of a table with identity column AND identity column was updated as part of that UPDATE with DEFAULT clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. The rules for INSERT are already documented in the reference manual. Reporter: Mamta A. Satoor Assignee: Myrna van Lunteren Attachments: DERBY-6753.diff, DERBY-6753.diff_2, crefjavstateautogen.html, crefjavstateautogen.html, rrefidentityvallocal.html, rrefidentityvallocal.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6768: --- Fix Version/s: 10.8.3.3 List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-6768. Resolution: Fixed It should be fine to backport it further if needed. List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14237061#comment-14237061 ] Mamta A. Satoor commented on DERBY-6764: Looks like the tests(testSSLBasicDSConnect and testSSLBasicDSPlainConnect) failed again on 10.8 http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm142/1643487-suites.All_diff.txt. I am looking into it. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.8.3.0, 10.9.1.0, 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14237084#comment-14237084 ] Mamta A. Satoor commented on DERBY-6764: I am able to repro the problem on my machine. Debugging into what the issue might be. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.8.3.0, 10.9.1.0, 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6768: --- Fix Version/s: 10.9.2.2 List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6768: --- Fix Version/s: 10.10.2.1 List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235129#comment-14235129 ] Mamta A. Satoor commented on DERBY-6764: I ran the SSLTest suite multiple times with IBM 1.4.2 on 10.8 and could not get the test to fail. I also ran the entire junit suite and the tests didn't fail. I will make a dummy commit into 10.8 so that the tests will fire again and see how the tests run with IBM 1.4.2 at http://people.apache.org/~myrnavl/derby_test_results/v10_8 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.8.3.0, 10.9.1.0, 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233389#comment-14233389 ] Mamta A. Satoor commented on DERBY-6764: Myrna, let me look into it. I see that we have jira DERBY-5991(SSLTest timed out waiting for network server to start) but that is intermittent and has not happened in a years time. When I ran the tests on 10.8 codeline, I ran them with higher jdk. I will try IBM 1.4.2 and see if I can repro the problem. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.8.3.0, 10.9.1.0, 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column
[ https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233823#comment-14233823 ] Mamta A. Satoor commented on DERBY-6753: Hi Myrna, thanks for working on the doc changes. In rrefidentityvallocal.dita, we currently in couple places say that the INSERT statement must contain a VALUES clause on a table containing an identity column. You correctly updated it to include UPDATE statement but for UPDATE statement, there will not be VALUES clause, instead there will be SET clause. Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column -- Key: DERBY-6753 URL: https://issues.apache.org/jira/browse/DERBY-6753 Project: Derby Issue Type: Task Components: Documentation Affects Versions: 10.12.0.0 Environment: Changes for DERBY-6742 will now make the newly generated value for a single row UPDATE statement available through IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very localized and from my search, the changes need to go only in the reference manual. Basically, DERBY-6414 now allows an identity column's value to be updated using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no way of updating an identity column). This updated value is available through IDENTITY_VAL_LOCAL if only one row was updated of a table with identity column AND identity column was updated as part of that UPDATE with DEFAULT clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. The rules for INSERT are already documented in the reference manual. Reporter: Mamta A. Satoor Assignee: Myrna van Lunteren Attachments: DERBY-6753.diff, crefjavstateautogen.html, rrefidentityvallocal.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column
[ https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233940#comment-14233940 ] Mamta A. Satoor commented on DERBY-6753: Also in rrefidentityvallocal.dita, we list cases where IDENTITY_VAL_LOCAL will not retrun the expected value. One of those cases is - An INSERT statement with a fullselect. I noticed that in the attached patch, there is now a line for An UPDATE statement with a fullselect but fullselect does not apply to UPDATE so we should not add An UPDATE statement with a fullselect to the list of cases where IDENTITY_VAL_LOCAL will not retrun the expected value. Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column -- Key: DERBY-6753 URL: https://issues.apache.org/jira/browse/DERBY-6753 Project: Derby Issue Type: Task Components: Documentation Affects Versions: 10.12.0.0 Environment: Changes for DERBY-6742 will now make the newly generated value for a single row UPDATE statement available through IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very localized and from my search, the changes need to go only in the reference manual. Basically, DERBY-6414 now allows an identity column's value to be updated using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no way of updating an identity column). This updated value is available through IDENTITY_VAL_LOCAL if only one row was updated of a table with identity column AND identity column was updated as part of that UPDATE with DEFAULT clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. The rules for INSERT are already documented in the reference manual. Reporter: Mamta A. Satoor Assignee: Myrna van Lunteren Attachments: DERBY-6753.diff, crefjavstateautogen.html, rrefidentityvallocal.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column
[ https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233956#comment-14233956 ] Mamta A. Satoor commented on DERBY-6753: One last thing on this patch - has following paragraph If a table with an identity column has an INSERT trigger defined that inserts into another table with another identity column, then the IDENTITY_VAL_LOCAL function will return the generated value for the statement table, and not for the table modified by the trigger. We need to make a similar paragraph fro UPDATE If a table with an identity column has an UPDATE trigger defined that updates another table with another identity column, then the IDENTITY_VAL_LOCAL function will return the generated value for the statement table, and not for the table modified by the trigger. Please feel free to reword these 2 paragraphs as necessary so it doesn't look repetitive. The key here is UPDATE trigger goes with updating another table with identity column and INSERT trigger goes with inserting into another table with identity column. Thanks again for updating the docs. Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column -- Key: DERBY-6753 URL: https://issues.apache.org/jira/browse/DERBY-6753 Project: Derby Issue Type: Task Components: Documentation Affects Versions: 10.12.0.0 Environment: Changes for DERBY-6742 will now make the newly generated value for a single row UPDATE statement available through IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very localized and from my search, the changes need to go only in the reference manual. Basically, DERBY-6414 now allows an identity column's value to be updated using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no way of updating an identity column). This updated value is available through IDENTITY_VAL_LOCAL if only one row was updated of a table with identity column AND identity column was updated as part of that UPDATE with DEFAULT clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. The rules for INSERT are already documented in the reference manual. Reporter: Mamta A. Satoor Assignee: Myrna van Lunteren Attachments: DERBY-6753.diff, crefjavstateautogen.html, rrefidentityvallocal.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-6770) Update the documentation to reflect new information in server log file about list of enabled protocols
[ https://issues.apache.org/jira/browse/DERBY-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-6770. Resolution: Won't Fix Assignee: Mamta A. Satoor Resolving this issue since the additional info in the log about enabled protocols is self explanatory and does not need to be documented. Update the documentation to reflect new information in server log file about list of enabled protocols -- Key: DERBY-6770 URL: https://issues.apache.org/jira/browse/DERBY-6770 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor DERBY-6768(List the enabled protocols in derby.log for network server configuration) added new information info server log file at the startup time to list all the enabled protocols. It will be good to update our documentation to reflect this new information in the log file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Affects Version/s: 10.9.2.2 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.9.2.2, 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Affects Version/s: 10.8.3.3 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.8.3.3, 10.9.2.2, 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Affects Version/s: (was: 10.9.2.2) (was: 10.8.3.3) 10.8.3.0 10.9.1.0 Fix Version/s: 10.9.2.2 10.8.3.3 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.8.3.0, 10.9.1.0, 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-6764. Resolution: Fixed Issue fix info: (was: Patch Available) The issue can be backported further if required. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.8.3.0, 10.9.1.0, 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6768: --- Fix Version/s: 10.11.1.3 List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.11.1.3, 10.12.0.0 Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232592#comment-14232592 ] Mamta A. Satoor commented on DERBY-6768: I just issued a svn commit for backport to 10.11 but for some reason, all I got is $ svn commit --username=mamta Sending. Sending java\drda\org\apache\derby\impl\drda\NetworkServerControlImpl.java Sendingjava\drda\org\apache\derby\loc\drda\messages_en.properties Transmitting file data .. It never came back with the revision number and was hung there for a long time so I cancelled out of it with Ctrl-C. But it seems like commit made it into svn repository because I created a new 10.11 client and I see my changes in there. I will appreciate if someone can do svn update on 10.11 client and if they can see the changes for enabled protocols in NetworkServerControlImpl.java and messages_en.properties. In the mean time, I will work on 10.10 backport. List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.11.1.3, 10.12.0.0 Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232625#comment-14232625 ] Mamta A. Satoor commented on DERBY-6768: Thank you for double checking it Bryan. List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.11.1.3, 10.12.0.0 Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6771) Derby is crashing and writing org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT a
[ https://issues.apache.org/jira/browse/DERBY-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223076#comment-14223076 ] Mamta A. Satoor commented on DERBY-6771: Sidhant, I noticed in your code snippet above, you have used EmbeddedDriver. For client server configuration, you need to to do Class.forName(org.apache.derby.jdbc.ClientDriver); instead of Class.forName(org.apache.derby.jdbc.EmbeddedDriver); Also, like Bryan mentioned, can you please try reenabling SSLv3 temporarily and try connecting just to rule out if it is really the problem with removing SSLv3? Derby is crashing and writing org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 3. Plaintext connection attempt from an SSL enabled client? --- Key: DERBY-6771 URL: https://issues.apache.org/jira/browse/DERBY-6771 Project: Derby Issue Type: Bug Affects Versions: 10.4.2.0 Environment: Linux 2.6.18-348.3.1.el5xen x86_64 Reporter: Sidhant Behura Labels: Crash, DRDAProtocolException, Derby The derby db crashes and writes the following log into derby.out Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 3. Plaintext connection attempt from an SSL enabled client? org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 3. Plaintext connection attempt from an SSL enabled client? at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:513) at org.apache.derby.impl.drda.DDMReader.readDssHeader(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.exchangeServerAttributes(DRDAConnThread.java:1109) at org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:663) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:279) I have observed the PS Perm Generation used space is 99%. Please provide some information what is triggering this and how to resolve this. Thanks in advance... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6773) Derby throws plain SQLIntegrityConstraintViolationException
[ https://issues.apache.org/jira/browse/DERBY-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6773: --- Attachment: DERBY6733Repro.java I made the repro attached to https://hibernate.atlassian.net/browse/HHH-9516 a little bit smaller to show the java.sql.SQLIntegrityConstraintViolationException. The repro is attached here as DERBY6733Repro.java Derby throws plain SQLIntegrityConstraintViolationException --- Key: DERBY-6773 URL: https://issues.apache.org/jira/browse/DERBY-6773 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.10.2.0 Environment: Windows 7 x86_64, Java 1.6.0.45 Reporter: Jochen Wiedmann Priority: Minor Attachments: DERBY6733Repro.java If a unique constraint is violated by an insert statement, then Derby throws an SQLIntegrityConstraintViolationException. The error message contains, in particular, the constraint name and the table name. To distinguish between cases with various constraints, Derby should instead throw a subclass of SQLIntegrityConstraintViolationException, with methods like getConstraintName(), and getTableName(). See also https://hibernate.atlassian.net/browse/HHH-9516. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14222167#comment-14222167 ] Mamta A. Satoor commented on DERBY-6764: My failure mentioned above is happening with sane jars and IBM jdk 1.6 If I use insane jars with same jdk, the tests(both junit and derbyall) run fine. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14222327#comment-14222327 ] Mamta A. Satoor commented on DERBY-6764: Hi Rick, thanks for the pointer. I think Mike tried running the tests with the backport patch and didn't run into any issues. I tried running the tests with the backport patch on a different client of 10.8 branch on my machine with sane jars and it didn't run into any issues. Based on this, unless there is an objection, I will go ahead and commit the backport to 10.8. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Attachment: DERBY6764_10_8_backport_patch1_diff.txt I tried backporting this jira to 10.8 but I am getting following error very early on when I try to junit suite(also, had to make hand change for the backport to work because there is no String.contains(..) method in jk1.4 so I changed the backport code to use String.indexOf(...)=0 but that should not cause any problems). I am trying to run junit suite with IBM jdk1.6 (emb)derbynet.PrepareStatementTest.testBasicPrepare used 65 ms . (emb)derbynet.PrepareStatementTest.testParameterTypes used 89 ms . (emb)derbynet.PrepareStatementTest.testBigTable used 1155 ms . (emb)derbynet.PrepareStatementTest.testBigDecimalSetObject used 58 ms . (emb)derbynet.PrepareStatementTest.testBigDecimalSetObjectWithScale used 20 ms . (emb)derbynet.PrepareStatementTest.testVaryingClientParameterTypeBatch used 22 ms . (emb)derbynet.PrepareStatementTest.testSmallBigDecimal used 26 ms . (emb)derbynet.PrepareStatementTest.testManyPreparedStatements used 147 ms . (emb)derbynet.PrepareStatementTest.testInvalidTimestamp used 26 ms . (emb)derbynet.PrepareStatementTest.testSplitQRYDTABlock used 300 ms . (emb)derbynet.PrepareStatementTest.testExcpetionWithBigParameter used 50 ms . (emb)derbynet.PrepareStatementTest.testLargeReplies used 73 ms . (emb)derbynet.PrepareStatementTest.testAlternatingLobValuesAndNull used 80 ms . (emb)derbynet.PrepareStatementTest.testLargeBatch used 3602 ms . (emb)derbynet.PrepareStatementTest.testDSSLength used 91 ms . (emb)derbynet.PrepareStatementTest.testVariationOfSetObject used 42 ms . (emb)derbynet.PrepareStatementTest.testLargeParameters_a used 28 ms . (emb)derbynet.PrepareStatementTest.testLargeParameters_b used 43 ms . (emb)derbynet.PrepareStatementTest.testDerby3230 used 26 ms . (emb)derbynet.PrepareStatementTest.testReadBlobCloseToMaxDssLength used 13 ms . (emb)derbynet.PrepareStatementTest.testLongColumn used 21 ms EESTART-SPAWNED:SpawnedNetworkServer STANDARD OUTPUT: exit code=1 Fri Nov 21 13:55:01 PST 2014 : Security manager installed using the Basic server security policy. Fri Nov 21 13:55:02 PST 2014 : Access denied (java.net.SocketPermission localhost:1527 listen,resolve) java.security.AccessControlException: Access denied (java.net.SocketPermission localhost:1527 listen,resolve) at java.security.AccessController.throwACE(AccessController.java:100) at java.security.AccessController.checkPermission(AccessController.java:174) at java.lang.SecurityManager.checkPermission(SecurityManager.java:562) at java.lang.SecurityManager.checkListen(SecurityManager.java:1147) at java.net.ServerSocket.bind(ServerSocket.java:442) at java.net.ServerSocket.init(ServerSocket.java:256) at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:6) at org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(NetworkServerControlImpl.java:674) at org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(NetworkServerControlImpl.java:95) at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(NetworkServerControlImpl.java:724) at java.security.AccessController.doPrivileged(AccessController.java:330) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:719) at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2250) at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:331) END-SPAWNED :SpawnedNetworkServer STANDARD OUTPUT: F analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Affects Version/s: 10.10.2.0 Fix Version/s: 10.10.2.1 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.10.2.0, 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.10.2.1, 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6503) Starting network server on a network drive fails with JDK 7 on Windows
[ https://issues.apache.org/jira/browse/DERBY-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216614#comment-14216614 ] Mamta A. Satoor commented on DERBY-6503: I agree it is wise for us to not do this backport considering how involved the FileUtil changes are. The issue is that FileUtil has gotten very out of sync between 10.10 and trunk. The reason for this is that we have had to backport changes out of order from trunk to 10.10 for FileUtil(this is because there are few changes in trunk which are not suitable for bacport to 10.10). This makes backport to FileUtil much harder if the FileUtil is touched a lot by a specific checkin in trunk(which is what happened with this jira). I will label this jira as reject for backport to 10.10 Starting network server on a network drive fails with JDK 7 on Windows -- Key: DERBY-6503 URL: https://issues.apache.org/jira/browse/DERBY-6503 Project: Derby Issue Type: Bug Components: Network Server, Services Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Fix For: 10.11.1.1 Attachments: DERBY6503_backport_patch1_diff.txt, d6503-1a.diff Starting a network server on a network drive with JDK 7 on Windows fails. The reported exception is a ClassCastException, but the underlying exception is the following: java.nio.file.AccessDeniedException: \\host\path\derby.log at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsAclFileAttributeView.setAcl(WindowsAclFileAttributeView.java:221) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwnerViaACLs(FileUtil.java:897) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwner(FileUtil.java:747) at org.apache.derby.impl.services.stream.SingleStream.PBmakeFileHPW(SingleStream.java:205) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:401) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:72) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.services.stream.SingleStream.makeFileHPW(SingleStream.java:394) at org.apache.derby.impl.services.stream.SingleStream.createDefaultStream(SingleStream.java:356) at org.apache.derby.impl.services.stream.SingleStream.makeStream(SingleStream.java:132) at org.apache.derby.impl.services.stream.SingleStream.boot(SingleStream.java:92) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1991) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:334) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:541) at org.apache.derby.impl.services.monitor.FileMonitor.startModule(FileMonitor.java:44) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:362) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:343) at org.apache.derby.impl.services.monitor.FileMonitor.init(FileMonitor.java:58) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:285) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:67) at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:199) at org.apache.derby.jdbc.EmbeddedDriver.clinit(EmbeddedDriver.java:95) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:188) at org.apache.derby.impl.drda.NetworkServerControlImpl.startNetworkServer(NetworkServerControlImpl.java:1032) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:732) at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2277) at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:353) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6503) Starting network server on a network drive fails with JDK 7 on Windows
[ https://issues.apache.org/jira/browse/DERBY-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6503: --- Labels: derby_backport_reject_10_10 (was: ) Starting network server on a network drive fails with JDK 7 on Windows -- Key: DERBY-6503 URL: https://issues.apache.org/jira/browse/DERBY-6503 Project: Derby Issue Type: Bug Components: Network Server, Services Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Labels: derby_backport_reject_10_10 Fix For: 10.11.1.1 Attachments: DERBY6503_backport_patch1_diff.txt, d6503-1a.diff Starting a network server on a network drive with JDK 7 on Windows fails. The reported exception is a ClassCastException, but the underlying exception is the following: java.nio.file.AccessDeniedException: \\host\path\derby.log at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsAclFileAttributeView.setAcl(WindowsAclFileAttributeView.java:221) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwnerViaACLs(FileUtil.java:897) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwner(FileUtil.java:747) at org.apache.derby.impl.services.stream.SingleStream.PBmakeFileHPW(SingleStream.java:205) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:401) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:72) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.services.stream.SingleStream.makeFileHPW(SingleStream.java:394) at org.apache.derby.impl.services.stream.SingleStream.createDefaultStream(SingleStream.java:356) at org.apache.derby.impl.services.stream.SingleStream.makeStream(SingleStream.java:132) at org.apache.derby.impl.services.stream.SingleStream.boot(SingleStream.java:92) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1991) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:334) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:541) at org.apache.derby.impl.services.monitor.FileMonitor.startModule(FileMonitor.java:44) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:362) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:343) at org.apache.derby.impl.services.monitor.FileMonitor.init(FileMonitor.java:58) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:285) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:67) at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:199) at org.apache.derby.jdbc.EmbeddedDriver.clinit(EmbeddedDriver.java:95) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:188) at org.apache.derby.impl.drda.NetworkServerControlImpl.startNetworkServer(NetworkServerControlImpl.java:1032) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:732) at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2277) at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:353) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216673#comment-14216673 ] Mamta A. Satoor commented on DERBY-6764: Bryan, I have not seen Plaintext connection attempt from an SSL enabled client? during my testing for this jira. I have seen error No appropriate protocol when after removing the SSLv3 protocol, the only protocol left was TLS but NaiveTrustManager was looking for SSL in it's code SSLContext ctx = SSLContext.getInstance(SSL);. As part of my checkin for this jira, I changed NaiveTrustManager to look for TLS instead of SSL and that got rid of the No appropriate protocol error. Like you asked on DERBY-6771, I am wondering too if the user is indeed by accident trying to make a plaintext connection in case of SSL connection. I do not think he responded to that question. Looks like though he is going to try the latest 10.10 or 10.11 jars with SSLv3 protocol removed through the configuration file to see if the issue is with Derby 10.4 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6503) Starting network server on a network drive fails with JDK 7 on Windows
[ https://issues.apache.org/jira/browse/DERBY-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6503: --- Attachment: DERBY6503_backport_patch1_diff.txt Here is my attempt at backporting the 2 commits from trunk to 10.10. This patch(DERBY6503_backport_patch1_diff) is not ready for commit. It has been a non-trivial backport with quite a bit of hand changes(specifically in FileUtil.java). I will appreciate if another pair of eyes can see if the hand backport has missed anything. Also, with the patch, I am getting following error during compilation on 10.10(I haven't debugged the build failure yet to see what the problem might be) compile_iapi_error: compile_iapi_services_jsr169: BUILD FAILED C:\p4clients\svn10.10\client1\10.10\build.xml:623: The following error occurred while executing this line: C:\p4clients\svn10.10\client1\10.10\java\engine\build.xml:59: The following error occurred while executing this line: C:\p4clients\svn10.10\client1\10.10\java\engine\org\apache\derby\iapi\build.xml:39: The following error occurred while executing this line: C:\p4clients\svn10.10\client1\10.10\java\engine\org\apache\derby\iapi\services\build.xml:61: The following error occurred while executing this line: C:\p4clients\svn10.10\client1\10.10\java\engine\org\apache\derby\iapi\services\io\build.xml:19: Content is not allowed in prolog. Total time: 1 second Starting network server on a network drive fails with JDK 7 on Windows -- Key: DERBY-6503 URL: https://issues.apache.org/jira/browse/DERBY-6503 Project: Derby Issue Type: Bug Components: Network Server, Services Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Fix For: 10.11.1.1 Attachments: DERBY6503_backport_patch1_diff.txt, d6503-1a.diff Starting a network server on a network drive with JDK 7 on Windows fails. The reported exception is a ClassCastException, but the underlying exception is the following: java.nio.file.AccessDeniedException: \\host\path\derby.log at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsAclFileAttributeView.setAcl(WindowsAclFileAttributeView.java:221) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwnerViaACLs(FileUtil.java:897) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwner(FileUtil.java:747) at org.apache.derby.impl.services.stream.SingleStream.PBmakeFileHPW(SingleStream.java:205) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:401) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:72) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.services.stream.SingleStream.makeFileHPW(SingleStream.java:394) at org.apache.derby.impl.services.stream.SingleStream.createDefaultStream(SingleStream.java:356) at org.apache.derby.impl.services.stream.SingleStream.makeStream(SingleStream.java:132) at org.apache.derby.impl.services.stream.SingleStream.boot(SingleStream.java:92) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1991) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:334) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:541) at org.apache.derby.impl.services.monitor.FileMonitor.startModule(FileMonitor.java:44) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:362) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:343) at org.apache.derby.impl.services.monitor.FileMonitor.init(FileMonitor.java:58) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:285) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:67) at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:199) at org.apache.derby.jdbc.EmbeddedDriver.clinit(EmbeddedDriver.java:95) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:188) at
[jira] [Updated] (DERBY-6287) Don't use reflection to call Java 6 methods in FileUtil
[ https://issues.apache.org/jira/browse/DERBY-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6287: --- Labels: derby_backport_reject_10_10 (was: ) Don't use reflection to call Java 6 methods in FileUtil --- Key: DERBY-6287 URL: https://issues.apache.org/jira/browse/DERBY-6287 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.11.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Labels: derby_backport_reject_10_10 Fix For: 10.11.1.1 Attachments: DERBY6287_patch1_diff.txt, derby-6287-1a.diff The FileUtil class uses reflection to call the following java.io.File methods: setWritable(boolean, boolean) setReadable(boolean, boolean) setExecutable(boolean, boolean) Reflection was used because the methods were introduced in Java 6, and the code had to run on older platforms. Now Java 6 is the lowest supported platform, so we can call the methods directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6287) Don't use reflection to call Java 6 methods in FileUtil
[ https://issues.apache.org/jira/browse/DERBY-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212514#comment-14212514 ] Mamta A. Satoor commented on DERBY-6287: I agree that this should not be backported to 10.10 based on Knut's comments I have marked the backport reject label. Will go back to hand merging the other jira DERBY-6503 Don't use reflection to call Java 6 methods in FileUtil --- Key: DERBY-6287 URL: https://issues.apache.org/jira/browse/DERBY-6287 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.11.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Labels: derby_backport_reject_10_10 Fix For: 10.11.1.1 Attachments: DERBY6287_patch1_diff.txt, derby-6287-1a.diff The FileUtil class uses reflection to call the following java.io.File methods: setWritable(boolean, boolean) setReadable(boolean, boolean) setExecutable(boolean, boolean) Reflection was used because the methods were introduced in Java 6, and the code had to run on older platforms. Now Java 6 is the lowest supported platform, so we can call the methods directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6768: --- Fix Version/s: 10.12.0.0 It is ok to backport this improvement. But I am wondering if it will be confusing to the users using the older releases to see this new piece of information in the log file when the corresponding release documentation(specifically Derby Server and Administration Guide) does not have an explanation for this new line. List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DERBY-6770) Update the documentation to reflect new information in server log file about list of enabled protocols
Mamta A. Satoor created DERBY-6770: -- Summary: Update the documentation to reflect new information in server log file about list of enabled protocols Key: DERBY-6770 URL: https://issues.apache.org/jira/browse/DERBY-6770 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor DERBY-6768(List the enabled protocols in derby.log for network server configuration) added new information info server log file at the startup time to list all the enabled protocols. It will be good to update our documentation to reflect this new information in the log file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-6577) Quantified comparison returns wrong result in CASE, COALESCE, IN and BETWEEN
[
https://issues.apache.org/jira/browse/DERBY-6577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor resolved DERBY-6577.
Resolution: Fixed
Fix Version/s: 10.10.2.1
Assignee: Knut Anders Hatlen (was: Mamta A. Satoor)
Finished backporting to 10.10
Quantified comparison returns wrong result in CASE, COALESCE, IN and BETWEEN
Key: DERBY-6577
URL: https://issues.apache.org/jira/browse/DERBY-6577
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.10.2.0, 10.11.1.1
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Fix For: 10.10.2.1, 10.11.1.1
Attachments: d6577-1a.diff, d6577-2a.diff
I'm seeing this on head of trunk:
{noformat}
ij select c, c = all (values 'Y'), case when c = all (values 'Y') then true
else false end from (values 'Y', 'N') v(c);
C|2|3
-
Y|true |false
N|false|true
2 rows selected
{noformat}
Column 2 and column 3 should have the same value, but something seems to go
wrong when the quantified comparison is used in a CASE expression.
I'm seeing the expected result on 10.10.2.0, though:
{noformat}
ij select c, c = all (values 'Y'), case when c = all (values 'Y') then true
else false end from (values 'Y', 'N') v(c);
C|2|3
-
Y|true |true
N|false|false
2 rows selected
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6725) Add a system function which returns the name of the database.
[ https://issues.apache.org/jira/browse/DERBY-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211360#comment-14211360 ] Mamta A. Satoor commented on DERBY-6725: I am looking into implementing SYSCS_UTIL.SYSCS_GET_DATABASE_NAME. Bryan, unless I am not understanding it right, CURRENT SCHEMA function won't return what we are looking for, right? Add a system function which returns the name of the database. - Key: DERBY-6725 URL: https://issues.apache.org/jira/browse/DERBY-6725 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.12.0.0 Reporter: Rick Hillegas Assignee: Mamta A. Satoor Got this request in private conversation with a user. Other databases provide this functionality. Seems straightforward to add. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Affects Version/s: 10.11.1.1 Fix Version/s: 10.11.1.3 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.11.1.1, 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.11.1.3, 10.12.0.0 Attachments: DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-6503) Starting network server on a network drive fails with JDK 7 on Windows
[ https://issues.apache.org/jira/browse/DERBY-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor reassigned DERBY-6503: -- Assignee: Mamta A. Satoor (was: Mike Matrigali) Starting network server on a network drive fails with JDK 7 on Windows -- Key: DERBY-6503 URL: https://issues.apache.org/jira/browse/DERBY-6503 Project: Derby Issue Type: Bug Components: Network Server, Services Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Fix For: 10.11.1.1 Attachments: d6503-1a.diff Starting a network server on a network drive with JDK 7 on Windows fails. The reported exception is a ClassCastException, but the underlying exception is the following: java.nio.file.AccessDeniedException: \\host\path\derby.log at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsAclFileAttributeView.setAcl(WindowsAclFileAttributeView.java:221) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwnerViaACLs(FileUtil.java:897) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwner(FileUtil.java:747) at org.apache.derby.impl.services.stream.SingleStream.PBmakeFileHPW(SingleStream.java:205) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:401) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:72) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.services.stream.SingleStream.makeFileHPW(SingleStream.java:394) at org.apache.derby.impl.services.stream.SingleStream.createDefaultStream(SingleStream.java:356) at org.apache.derby.impl.services.stream.SingleStream.makeStream(SingleStream.java:132) at org.apache.derby.impl.services.stream.SingleStream.boot(SingleStream.java:92) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1991) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:334) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:541) at org.apache.derby.impl.services.monitor.FileMonitor.startModule(FileMonitor.java:44) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:362) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:343) at org.apache.derby.impl.services.monitor.FileMonitor.init(FileMonitor.java:58) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:285) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:67) at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:199) at org.apache.derby.jdbc.EmbeddedDriver.clinit(EmbeddedDriver.java:95) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:188) at org.apache.derby.impl.drda.NetworkServerControlImpl.startNetworkServer(NetworkServerControlImpl.java:1032) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:732) at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2277) at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:353) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6503) Starting network server on a network drive fails with JDK 7 on Windows
[ https://issues.apache.org/jira/browse/DERBY-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211384#comment-14211384 ] Mamta A. Satoor commented on DERBY-6503: After checking with Mike, I am doing the backport to 10.10 Starting network server on a network drive fails with JDK 7 on Windows -- Key: DERBY-6503 URL: https://issues.apache.org/jira/browse/DERBY-6503 Project: Derby Issue Type: Bug Components: Network Server, Services Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Fix For: 10.11.1.1 Attachments: d6503-1a.diff Starting a network server on a network drive with JDK 7 on Windows fails. The reported exception is a ClassCastException, but the underlying exception is the following: java.nio.file.AccessDeniedException: \\host\path\derby.log at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsAclFileAttributeView.setAcl(WindowsAclFileAttributeView.java:221) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwnerViaACLs(FileUtil.java:897) at org.apache.derby.iapi.services.io.FileUtil.limitAccessToOwner(FileUtil.java:747) at org.apache.derby.impl.services.stream.SingleStream.PBmakeFileHPW(SingleStream.java:205) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:401) at org.apache.derby.impl.services.stream.SingleStream.run(SingleStream.java:72) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.services.stream.SingleStream.makeFileHPW(SingleStream.java:394) at org.apache.derby.impl.services.stream.SingleStream.createDefaultStream(SingleStream.java:356) at org.apache.derby.impl.services.stream.SingleStream.makeStream(SingleStream.java:132) at org.apache.derby.impl.services.stream.SingleStream.boot(SingleStream.java:92) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1991) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:334) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:541) at org.apache.derby.impl.services.monitor.FileMonitor.startModule(FileMonitor.java:44) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:362) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:343) at org.apache.derby.impl.services.monitor.FileMonitor.init(FileMonitor.java:58) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:285) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:67) at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:199) at org.apache.derby.jdbc.EmbeddedDriver.clinit(EmbeddedDriver.java:95) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:188) at org.apache.derby.impl.drda.NetworkServerControlImpl.startNetworkServer(NetworkServerControlImpl.java:1032) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:732) at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2277) at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:353) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6287) Don't use reflection to call Java 6 methods in FileUtil
[ https://issues.apache.org/jira/browse/DERBY-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211854#comment-14211854 ] Mamta A. Satoor commented on DERBY-6287: I am looking into backporting this to 10.10 because DERBY-6503 has been identified as a candidate for 10.10 backport but the changes for DERBY-6503 are conflicting with changes that went in for DERBY-6287. If there is an issue with backporting DERBY-6287 to 10.10, please let me know but from the description of this improvement, it seems like it should be ok. Don't use reflection to call Java 6 methods in FileUtil --- Key: DERBY-6287 URL: https://issues.apache.org/jira/browse/DERBY-6287 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.11.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.11.1.1 Attachments: derby-6287-1a.diff The FileUtil class uses reflection to call the following java.io.File methods: setWritable(boolean, boolean) setReadable(boolean, boolean) setExecutable(boolean, boolean) Reflection was used because the methods were introduced in Java 6, and the code had to run on older platforms. Now Java 6 is the lowest supported platform, so we can call the methods directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6287) Don't use reflection to call Java 6 methods in FileUtil
[ https://issues.apache.org/jira/browse/DERBY-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6287: --- Attachment: DERBY6287_patch1_diff.txt Here is the patch for backport to 10.10. I had to hand make the changes for backporting. Running derbyall right now. Don't use reflection to call Java 6 methods in FileUtil --- Key: DERBY-6287 URL: https://issues.apache.org/jira/browse/DERBY-6287 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.11.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.11.1.1 Attachments: DERBY6287_patch1_diff.txt, derby-6287-1a.diff The FileUtil class uses reflection to call the following java.io.File methods: setWritable(boolean, boolean) setReadable(boolean, boolean) setExecutable(boolean, boolean) Reflection was used because the methods were introduced in Java 6, and the code had to run on older platforms. Now Java 6 is the lowest supported platform, so we can call the methods directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DERBY-6287) Don't use reflection to call Java 6 methods in FileUtil
[ https://issues.apache.org/jira/browse/DERBY-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211920#comment-14211920 ] Mamta A. Satoor edited comment on DERBY-6287 at 11/14/14 6:36 AM: -- Here is the patch(DERBY6287_patch1_diff.txt) for backport to 10.10. I had to hand make the changes for backporting. Running derbyall right now. was (Author: mamtas): Here is the patch for backport to 10.10. I had to hand make the changes for backporting. Running derbyall right now. Don't use reflection to call Java 6 methods in FileUtil --- Key: DERBY-6287 URL: https://issues.apache.org/jira/browse/DERBY-6287 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.11.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.11.1.1 Attachments: DERBY6287_patch1_diff.txt, derby-6287-1a.diff The FileUtil class uses reflection to call the following java.io.File methods: setWritable(boolean, boolean) setReadable(boolean, boolean) setExecutable(boolean, boolean) Reflection was used because the methods were introduced in Java 6, and the code had to run on older platforms. Now Java 6 is the lowest supported platform, so we can call the methods directly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-5615) NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on
[ https://issues.apache.org/jira/browse/DERBY-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-5615. Resolution: Fixed Fix Version/s: 10.10.2.1 Assignee: Knut Anders Hatlen (was: Mamta A. Satoor) Backport to 10.10 done. Assigning back to Knut. NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on Key: DERBY-5615 URL: https://issues.apache.org/jira/browse/DERBY-5615 Project: Derby Issue Type: Bug Components: SQL, Store Affects Versions: 10.9.1.0 Reporter: Rick Hillegas Assignee: Knut Anders Hatlen Labels: derby_triage10_9 Fix For: 10.10.2.1, 10.11.1.1 Attachments: 5615.policy, 5615_bug.sql, 5615_init.sql, 5615_script, d5615-1a.diff, d5615-1b.diff, d5615-2a.diff, derby.log, derby.log I get an NPE trying to select from a table on which I don't have select privilege. The database is stored in a jar file accessed via the classpath protocol. BUILTIN authentication and sql authorization are turned on in the database. Running under a Java security manager. I will attach a repro. Here is the NPE: Failed Statement is: select * from KIWI.t java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:661) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:591) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java:1316) at org.apache.derby.impl.store.access.btree.OpenBTree.init(OpenBTree.java:380) at org.apache.derby.impl.store.access.btree.BTreeController.init(BTreeController.java:1250) at org.apache.derby.impl.store.access.btree.index.B2IController.init(B2IController.java:140) at org.apache.derby.impl.store.access.btree.index.B2I.open(B2I.java:821) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:476) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1308) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.debugGenerateInfo(DataDictionaryImpl.java:9584) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndexMinion(DataDictionaryImpl.java:9492) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:9303) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2887) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2851) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.finishTableDescriptor(DataDictionaryImpl.java:2408) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptorIndex1Scan(DataDictionaryImpl.java:2277) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTableDescriptor(DataDictionaryImpl.java:2293) at org.apache.derby.impl.sql.catalog.NameTDCacheable.setIdentity(NameTDCacheable.java:110) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptor(DataDictionaryImpl.java:2224) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.faultInTabInfo(DataDictionaryImpl.java:9905) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getNonCoreTI(DataDictionaryImpl.java:9702) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedPermissionsDescriptor(DataDictionaryImpl.java:13712) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTablePermsDescriptor(DataDictionaryImpl.java:13660) at org.apache.derby.impl.sql.catalog.PermissionsCacheable.setIdentity(PermissionsCacheable.java:71) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getPermissions(DataDictionaryImpl.java:13364) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTablePermissions(DataDictionaryImpl.java:13350) at org.apache.derby.iapi.sql.dictionary.StatementTablePermission.oneAuthHasPermissionOnTable(StatementTablePermission.java:239) at org.apache.derby.iapi.sql.dictionary.StatementTablePermission.hasPermissionOnTable(StatementTablePermission.java:160) at
[jira] [Commented] (DERBY-6759) Derby 10.10 backport issue (fall 2014)
[ https://issues.apache.org/jira/browse/DERBY-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208755#comment-14208755 ] Mamta A. Satoor commented on DERBY-6759: I am working on my backports right now. thanks Derby 10.10 backport issue (fall 2014) -- Key: DERBY-6759 URL: https://issues.apache.org/jira/browse/DERBY-6759 Project: Derby Issue Type: Task Affects Versions: 10.10.2.1 Reporter: Myrna van Lunteren This issue is issue is used to track an effort to backport fixes to 10.10 Here is a filter for the list: https://issues.apache.org/jira/issues/?filter=12326503 Here is the approach 1) Choose a bug to backport from the list: Look at comment to make sure nobody else has picked up the issue. 2) Reassign the issue to yourself (without reopening), put a comment that you are backporting the fix to 10.10 and link to this issue. 3) After backport reassign the bug to the original owner and adjust fix version. 4) If you were not able to backport for some reason, label derby_backport_reject10_10 as appropriate and unlink from this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-6228) DisconnectException when executing an SELECT [LOB column] ORDER BY [...] statement with TYPE_SCROLL_[IN]SENSITIVE and CONCUR_UPDATABLE
[ https://issues.apache.org/jira/browse/DERBY-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-6228. Resolution: Fixed Fix Version/s: 10.10.2.1 Assignee: Dyre Tjeldvoll (was: Mamta A. Satoor) Finished backporting to 10.10. Assigning back to Dyre. DisconnectException when executing an SELECT [LOB column] ORDER BY [...] statement with TYPE_SCROLL_[IN]SENSITIVE and CONCUR_UPDATABLE -- Key: DERBY-6228 URL: https://issues.apache.org/jira/browse/DERBY-6228 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.8.3.0, 10.10.1.1 Reporter: Lukas Eder Assignee: Dyre Tjeldvoll Labels: derby_triage10_11 Fix For: 10.10.2.1, 10.11.1.1 Attachments: Derby6228.java, derby-6228-a.diff Here's a minimal program to reproduce the issue: Connection c = DriverManager.getConnection( jdbc:derby://localhost:1527/test;create=true, TEST, TEST); Statement s = c.createStatement(); s.executeUpdate( CREATE TABLE t( + id INT NOT NULL, + c CLOB + )); s.executeUpdate(INSERT INTO t VALUES (1, null)); s.executeUpdate(INSERT INTO t VALUES (2, null)); PreparedStatement stmt = c.prepareStatement( SELECT * FROM t ORDER BY id, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE); ResultSet rs = stmt.executeQuery(); rs.next(); The above leads to this exception: java.sql.SQLNonTransientConnectionException: Netzwerkprotokollausnahme: DSS-Länge ist beim Beenden des Parsing-Vorgangs der ID-Kette größer als 0. Die Verbindung wurde beendet. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.ResultSet.next(Unknown Source) at org.jooq.test._.testcases.KeepResultSetTests.testKeepRSWithUpdateOnChangeLazy(KeepResultSetTests.java:330) at org.jooq.test.jOOQAbstractTest.testKeepRSWithUpdateOnChangeLazy(jOOQAbstractTest.java:2240) ... Caused by: org.apache.derby.client.am.DisconnectException: Netzwerkprotokollausnahme: DSS-Länge ist beim Beenden des Parsing-Vorgangs der ID-Kette größer als 0. Die Verbindung wurde beendet. at org.apache.derby.client.net.Reply.endOfSameIdChainData(Unknown Source) at org.apache.derby.client.net.NetResultSetReply.readPositioningFetch(Unknown Source) at org.apache.derby.client.net.ResultSetReply.readPositioningFetch(Unknown Source) at org.apache.derby.client.net.NetResultSet.readPositioningFetch_(Unknown Source) at org.apache.derby.client.am.ResultSet.getRowCount(Unknown Source) at org.apache.derby.client.am.ResultSet.resultSetContainsNoRows(Unknown Source) at org.apache.derby.client.am.ResultSet.getNextRowset(Unknown Source) at org.apache.derby.client.am.ResultSet.nextX(Unknown Source) ... 30 more To reproduce the above, all of the following things seem relevant: 1. There is at least one BLOB or CLOB column being selected 2. An ORDER BY clause is added 3. ResultSet.TYPE_SCROLL_SENSITIVE or ResultSet.TYPE_SCROLL_INSENSITIVE is set 4. ResultSet.CONCUR_UPDATABLE is set -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
[ https://issues.apache.org/jira/browse/DERBY-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6768: --- Attachment: DERBY-6768_patch1_diff.txt Attaching a patch which will now print the enabled protocols list when the server starts up in the log file. A sample new line in the log will look as follows Wed Nov 12 21:32:21 PST 2014 : Apache Derby Network Server - 10.12.0.0 alpha - (1636020M) Enabled Protocols are SSLv3, TLSv1, TLSv1.1, TLSv1.2 Of course, the list of protocols will be different depending on the JVM. When I start my network server, the log file has the bootup message and the enabled protocols Wed Nov 12 21:32:21 PST 2014 : Apache Derby Network Server - 10.12.0.0 alpha - (1636020M) started and ready to accept SSL connections on port 1529 Wed Nov 12 21:32:21 PST 2014 : Apache Derby Network Server - 10.12.0.0 alpha - (1636020M) Enabled Protocols are SSLv3, TLSv1, TLSv1.1, TLSv1.2 If there is any feedback on the wordings of the enabled protocols info, please let me know. Thanks List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Attachments: DERBY-6768_patch1_diff.txt DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14209347#comment-14209347 ] Mamta A. Satoor commented on DERBY-6764: It is ok to backport this fix for earlier releases. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Issue fix info: Patch Available analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Attachment: DERBY6764_backport10_11_patch1_diff.txt Attaching patch DERBY6764_backport10_11_patch1_diff.txt to backport the changes to 10.11 codeline. I have run derbyall and junit suite on 10.11 with this patch and they ran fine. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14196408#comment-14196408 ] Mamta A. Satoor commented on DERBY-6764: Knut, you are absolutely right about SSLv2Hello needing to be in upper case. I will fix that. I am looking at your other comment above System.arraycopy line. Thanks for reviewing the changes. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14196437#comment-14196437 ] Mamta A. Satoor commented on DERBY-6764: It is possible with some jvms to have both SSLv3 and SSLv2Hello enabled so I will change the System.arraycopy to not assume that only one protocol was removed. Instead, it will use the counter removedProtocolsCount which maintains how many exact protocols were removed. Will commit these changes soon. Also, I am wondering if there is any regression test we can write for this jira? I do plan to fix DERBY-6768 today so atleast the list of enabled protocols on the server side will be in the log file. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197210#comment-14197210 ] Mamta A. Satoor commented on DERBY-6764: I have been negligent with my checkin. Will fix the issue soon. As for using ArrayList, I avoided using them because I think it will be a good fix to backport to earlier releases where we may not have access to ArrayList. I could have used ArrayList here and change the code to old fashion during the backport but chose to be consistent. Please let me know if we prefer to use ArrayList on releases where they are available and then change the code for earlier releases. Thanks analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197219#comment-14197219 ] Mamta A. Satoor commented on DERBY-6764: Commit 1636668 from Mamta A. Satoor in branch 'code/trunk' [ https://svn.apache.org/r1636668 ] DERBY-6764(analyze impact of poodle security alert on Derby client - server ssl support) Changes based on Knut's feedback. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-674) Add a new regression test to catch large increases in the size of jar files
[ https://issues.apache.org/jira/browse/DERBY-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197221#comment-14197221 ] Mamta A. Satoor commented on DERBY-674: --- The commit comment above is meant for DERBY-6764 and not DERBY-674. Add a new regression test to catch large increases in the size of jar files --- Key: DERBY-674 URL: https://issues.apache.org/jira/browse/DERBY-674 Project: Derby Issue Type: Improvement Components: Test Reporter: David Van Couvering Priority: Minor Labels: derby_triage10_8 Footprint is one of the key principles of Derby. We should have a regression test that looks at the size of the various jar files and compares them against a high-water-mark and report an error or warning if the size exceeds the water mark. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Affects Version/s: 10.12.0.0 Fix Version/s: 10.12.0.0 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Affects Versions: 10.12.0.0 Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Fix For: 10.12.0.0 Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-6764: --- Attachment: DERBY6764_patch1_stat.txt DERBY6764_patch1_diff.txt Attaching a patch(DERBY6764_patch1_diff.txt) for this jira. It basically implements in Derby code what has been discussed in the Java example above. It goes through list of enabled protocols, removes SSLv3 and SSLv2Hello from list of enabled protocols. One thing that was causing problem is that NaiveTrustManager was using SSL as shown below for SSL basic implementation in Derby. SSLContext ctx = SSLContext.getInstance(SSL); With above code, if we remove SSLv3 and SSLv2Hello, there are no enabled protocols left. And client would give following exception when trying to connect to the server Exception in thread main java.lang.Exception: DRDA_NoIO.S:Could not connect to Derby Network Server on host 127.0.0.1, port 1527: No appropriate protocol To fix the problem, I have changed NaiveTrustManager to use TLS rather than SSL. With this, we now have TLS protocols enabled and hence client can make connection to the server. If anyone sees issues with changing from SSL to TLS in NaiveTrustManager , please let me know. I have fired the junit suite and next will run derbyall. Please let me know if there is any feedback on the patch. Thanks analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Attachments: DERBY6764_patch1_diff.txt, DERBY6764_patch1_stat.txt Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DERBY-6768) List the enabled protocols in derby.log for network server configuration
Mamta A. Satoor created DERBY-6768: -- Summary: List the enabled protocols in derby.log for network server configuration Key: DERBY-6768 URL: https://issues.apache.org/jira/browse/DERBY-6768 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.12.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor DERBY-6764 is the result of poodle security alert in SSLv3 and SSLv2Hello protocols. For future, it will be good to know the protocols that are enabled on the server side so it is easier to know if the product may be impacted by a security issue with any specific protocol. To achieve this, at the server boot up time, we should list these enabled protocols in derby.log -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-6068) Increase the arbitrary 32K limit imposed by DRDA on number of Sections used for open statements
[ https://issues.apache.org/jira/browse/DERBY-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor resolved DERBY-6068. Resolution: Won't Fix Increase the arbitrary 32K limit imposed by DRDA on number of Sections used for open statements Key: DERBY-6068 URL: https://issues.apache.org/jira/browse/DERBY-6068 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.10.1.1 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor We recommend users to close the statements ResultSet.getStatement().close() to make sure the statements get closed. But it would help us to increase the limit of 32K on open statements in case a machine is slow and gargbage collection is not happening fast enough. One instance where we ran into this 32K limit violation is DERBY-6054. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14188622#comment-14188622 ] Mamta A. Satoor commented on DERBY-6764: I ran the Java program with multiple JVMs and following is the result of those runs IBM jvms * java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20140415 (SR16 FP6 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows 7 x86-32 j9vmwi3223ifx-20140401 (JIT enabled) J9VM - 20140326_194053_lHdSMr JIT - 20130920_46470ifx1_r8 GC - 20120911_AA) JCL - 20140415 Supported protocols are SSLv3 TLS TLSv1 SSL SSL_TLS Enabled protocols are SSLv3 TLS TLSv1 SSL SSL_TLS This enabled protocols list should not have SSLv3 TLS TLSv1 SSLv3 SSL SSL_TLS * java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr16-20140418_01(SR16)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows 7 x86-32 jvmwi3260sr16-20140416_196573 (JIT enabled, AOT enabled) J9VM - 20140416_196573 JIT - r9_20130920_46510ifx5 GC - GA24_Java6_SR16_20140416_1614_B196573) JCL - 20140406_01 Supported protocols are SSLv3 TLSv1 TLSv1.1 TLSv1.2 Enabled protocols are SSLv3 TLSv1 This enabled protocols list should not have SSLv3 TLSv1 * java version 1.7.0 Java(TM) SE Runtime Environment (build pwi3270sr7-20140410_01(SR7)) IBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 x86-32 20140409_195732 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR7_20140409_1418_B195732 JIT - r11.b06_20140409_61252 GC - R26_Java726_SR7_20140409_1418_B195732 J9CL - 20140409_195732) JCL - 20140409_01 based on Oracle 7u55-b13 Supported protocols are SSLv3 TLSv1 TLSv1.1 TLSv1.2 Enabled protocols are SSLv3 TLSv1 TLSv1.1 TLSv1.2 This enabled protocols list should not have SSLv3 TLSv1 TLSv1.1 TLSv1.2 Sun jvms * java version 1.5.0_45 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_45-b05) Java HotSpot(TM) Client VM (build 1.5.0_45-b05, mixed mode) Supported protocols are SSLv2Hello SSLv3 TLSv1 Enabled protocols are SSLv2Hello SSLv3 TLSv1 This enabled protocols list should not have SSLv3 SSLv2Hello TLSv1 * java version 1.6.0_45 Java(TM) SE Runtime Environment (build 1.6.0_45-b06) Java HotSpot(TM) Client VM (build 20.45-b01, mixed mode) Supported protocols are SSLv2Hello SSLv3 TLSv1 Enabled protocols are SSLv2Hello SSLv3 TLSv1 This enabled protocols list should not have SSLv3 SSLv2Hello TLSv1 * java version 1.7.0_21 Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode) Supported protocols are SSLv2Hello SSLv3 TLSv1 TLSv1.1 TLSv1.2 Enabled protocols are SSLv2Hello SSLv3 TLSv1 TLSv1.1 TLSv1.2 This enabled protocols list should not have SSLv3 SSLv2Hello TLSv1 TLSv1.1 TLSv1.2 * java version 1.8.0_20 Java(TM) SE Runtime Environment (build 1.8.0_20-b26) Java HotSpot(TM) Client VM (build 25.20-b23, mixed mode) Supported protocols are SSLv2Hello SSLv3 TLSv1 TLSv1.1 TLSv1.2 Enabled protocols are SSLv2Hello SSLv3 TLSv1 TLSv1.1 TLSv1.2 This enabled protocols list should not have SSLv3 SSLv2Hello TLSv1 TLSv1.1 TLSv1.2 analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14188627#comment-14188627 ] Mamta A. Satoor commented on DERBY-6764: Notice the peculiar behavior for IBM jdk 1.5. Not sure if it is a bug with the JVM but even after I remove the SSLv3 from the list of enabled protocols, it still shows up in the list of enabled protocols. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20140415 (SR16 FP6 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows 7 x86-32 j9vmwi3223ifx-20140401 (JIT enabled) J9VM - 20140326_194053_lHdSMr JIT - 20130920_46470ifx1_r8 GC - 20120911_AA) JCL - 20140415 Supported protocols are SSLv3 TLS TLSv1 SSL SSL_TLS Enabled protocols are SSLv3 TLS TLSv1 SSL SSL_TLS This enabled protocols list should not have SSLv3 TLS TLSv1 SSLv3 SSL SSL_TLS analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14188958#comment-14188958 ] Mamta A. Satoor commented on DERBY-6764: Hi Rick, I will make the change to remove SSLv2Hello also. Thanks analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor reassigned DERBY-6764: -- Assignee: Mamta A. Satoor analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Assignee: Mamta A. Satoor Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[
https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14186957#comment-14186957
]
Mamta A. Satoor commented on DERBY-6764:
Following java program lists the supported protocols and enabled
protocols(enabled will be susbset of supported protocols). If it find SSLv3 as
one of the enabled protocols, then it removes that protocol from the list of
enabled protocols. This way, poddle security will not be able to force the
socket to use SSLv3. I will work on incorporating same idea in the Derby code.
Please let me know if anyone has any feedback. Thanks
public static void main(String[] args) throws Exception {
int port = 1234;
SSLServerSocketFactory factory = (SSLServerSocketFactory)
SSLServerSocketFactory.getDefault();
SSLServerSocket serverSocket = (SSLServerSocket)
factory.createServerSocket(port);
String[] protocols = serverSocket.getSupportedProtocols();
System.out.println( Supported protocols are);
for ( int i = 0; i protocols.length; i++ )
{
System.out.println( + protocols[ i ] );
}
String[] enabledProtocols = serverSocket.getEnabledProtocols();
System.out.println( Enabled protocols are);
for ( int i = 0; i enabledProtocols.length; i++ )
{
System.out.println( + enabledProtocols[ i ] );
}
//If SSLv3 is one of the enabled protocols, then remove it from the
// list of enabled protocols because of its security breach.
String[] sslv3RemovedProtocols = new String[enabledProtocols.length];
int sslv3RemovedProtocolsCount = 0;
boolean foundSSLv3=false;
for ( int i = 0; i enabledProtocols.length; i++ )
{
if (!enabledProtocols[i].toUpperCase().contains(SSLV3)) {
sslv3RemovedProtocols[sslv3RemovedProtocolsCount] =
enabledProtocols[i];
sslv3RemovedProtocolsCount++;
} else
foundSSLv3=true;
}
String[] enabledProtocolsSSLv3Removed = null;
if(foundSSLv3) {
enabledProtocolsSSLv3Removed = new
String[(sslv3RemovedProtocols.length)-1];
System.arraycopy(sslv3RemovedProtocols, 0,
enabledProtocolsSSLv3Removed, 0, (sslv3RemovedProtocols.length)-1);
serverSocket.setEnabledProtocols(enabledProtocolsSSLv3Removed);
}
enabledProtocols = serverSocket.getEnabledProtocols();
System.out.println( This enabled protocols list should not have SSLv3
);
for ( int i = 0; i enabledProtocols.length; i++ )
{
System.out.println( + enabledProtocols[ i ] );
}
}
When I ran this program with IBM's jdk 1.6, I got following results
Supported protocols are
SSLv3
TLSv1
TLSv1.1
TLSv1.2
Enabled protocols are
SSLv3
TLSv1
This enabled protocols list should not have SSLv3
TLSv1
analyze impact of poodle security alert on Derby client - server ssl support
Key: DERBY-6764
URL: https://issues.apache.org/jira/browse/DERBY-6764
Project: Derby
Issue Type: Task
Reporter: Myrna van Lunteren
Assignee: Mamta A. Satoor
Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability
(CVE-2014-3566)
Derby supports ssl between the client and network server.
We should investigate this and decide if we need to change our product, e.g.
to eliminate support for SSL in favor of its successor TLS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183097#comment-14183097 ] Mamta A. Satoor commented on DERBY-6764: Rick, if we decide to change the derby code so SSLv3 is not an available option, would SSLSocket.setEnabledProtocols achieve the goal of removing SSLv3? We could get a list of supported protocols using SSLSocket.getSupportedProtocols() and remove SSLv3 from it(if it is in the list) and then call setEnabledProtocols with the new list. (or is it better to use SSLSocket.getEnabledProtocols() to get the list of enabled protocols and remove SSLv3 from that list and use this new list for SSLSocket.setEnabledProtocols). If we go with this path, then I think we will not have to worry about what JVM vendor we are working with. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183652#comment-14183652 ] Mamta A. Satoor commented on DERBY-6764: I will look into this and see if I can have some prototype. I will try to first experiment with Rick's test program to see if we can remove SSLv3 specifically. analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[
https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179626#comment-14179626
]
Mamta A. Satoor commented on DERBY-6764:
I modified Rick's java program in my environment to list the provider info for
SSL and TLS. It turns out that the provider is the same for both SSL and TLS
protocols.
import javax.net.ssl.SSLServerSocket;
import javax.net.ssl.SSLServerSocketFactory;
import javax.net.ssl.SSLContext;
public class MamtaJDBC {
public static void main(String[] args) throws Exception {
int port = 1234;
SSLServerSocketFactory factory = (SSLServerSocketFactory)
SSLServerSocketFactory.getDefault();
SSLServerSocket serverSocket = (SSLServerSocket)
factory.createServerSocket(port);
String[] protocols = serverSocket.getSupportedProtocols();
System.out.println( Supports protocol for getDefault are);
for ( int i = 0; i protocols.length; i++ )
{
System.out.println( + protocols[ i ] );
}
System.out.println( ssl provider is +
SSLContext.getInstance(SSL).getProvider().getInfo());
System.out.println( tls provider is +
SSLContext.getInstance(TLS).getProvider().getInfo());
}
}
The output of this program when run with IBM jdk 1.7 is as follows
$ java org.apache.derbyTesting.functionTests.tests.lang.MamtaJDBC
Supports protocol for getDefault are
SSLv3
TLSv1
TLSv1.1
TLSv1.2
ssl provider is IBM JSSE provider2 (implements IbmX509 key/trust factories,
SSLv3, TLSv1)
tls provider is IBM JSSE provider2 (implements IbmX509 key/trust factories,
SSLv3, TLSv1)
Since explicit request for SSL protocol returns TLS implementations as well, we
should be ok with Derby code explicitly asking for 'SSL' and we do not need to
make any changes for TLS. If the jdk provides TLS implementations then we will
get those TLS implementations through SSL protocol request.
analyze impact of poodle security alert on Derby client - server ssl support
Key: DERBY-6764
URL: https://issues.apache.org/jira/browse/DERBY-6764
Project: Derby
Issue Type: Task
Reporter: Myrna van Lunteren
Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability
(CVE-2014-3566)
Derby supports ssl between the client and network server.
We should investigate this and decide if we need to change our product, e.g.
to eliminate support for SSL in favor of its successor TLS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178768#comment-14178768 ] Mamta A. Satoor commented on DERBY-6764: Just want to discuss one scenario on this issue. There is just one piece of code in Derby both on client and server side where rather than getting the default protocol, we specifically ask for 'ssl'. That code is in NaiveTrustManager both on the client and server side. org.apache.derby.client.net.NaiveTrustManager org.apache.derby.impl.drda.NaiveTrustManager Between client and server, they can choose to 1)clear text exchanges 2)ssl/tls encryption but no peer authentication and 3)ssl/tls encryption and peer authentication For the second scenario(ssl encryption but no peer authentication), NaiveTrustManager gets used. And NaiveTrustManager specifically asks for SSLContext.getInstance(SSL). I wonder what version of ssl gets used in this scenario. For eg, lets say both client and server are using java version 1.7.0 which supports following protocols Java(TM) SE Runtime Environment (build pwi3270sr7-20140410_01(SR7)) IBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 x86-32 20140409_195732 (JIT enabled, AOT enabled) Supports protocol SSLv3 Supports protocol TLSv1 Supports protocol TLSv1.1 Supports protocol TLSv1.2 will we picking SSLv3 rather than TLSv1.2 since NaiveTrustManager specifically asked for SSL? analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14175265#comment-14175265 ] Mamta A. Satoor edited comment on DERBY-6764 at 10/20/14 10:13 PM: --- It looks like all SSL related code in Network Server client is very localized. For client side it is in 1)org.apache.derby.client.net.NaiveTrustManager, 2)org.apache.derby.client.net.OpenSocketAction, 3)org.apache.derby.jdbc.BasicClientDataSource40 For server side, it is in 1)org.apache.derby.impl.drda.NaiveTrustManager 2)org.apache.derby.impl.drda.NetworkServerControlImpl 3)org.apache.derby.mbeans.drda.NetworkServerMBean I also some code for it in replication area 1)org.apache.derby.impl.store.replication.net.ReplicationMessageReceive 2)org.apache.derby.impl.store.replication.net.ReplicationMessageTransmit was (Author: mamtas): It looks like all SSL related code in Network Server client is very localized. For client side it is in org.apache.derby.client.net.NaiveTrustManager and org.apache.derby.jdbc.BasicClientDataSource40 For server side, it is in org.apache.derby.impl.drda.NaiveTrustManager and org.apache.derby.impl.drda.NetworkServerControlImpl and org.apache.derby.mbeans.drda.NetworkServerMBean analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support
[ https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14175265#comment-14175265 ] Mamta A. Satoor commented on DERBY-6764: It looks like all SSL related code in Network Server client is very localized. For client side it is in org.apache.derby.client.net.NaiveTrustManager and org.apache.derby.jdbc.BasicClientDataSource40 For server side, it is in org.apache.derby.impl.drda.NaiveTrustManager and org.apache.derby.impl.drda.NetworkServerControlImpl and org.apache.derby.mbeans.drda.NetworkServerMBean analyze impact of poodle security alert on Derby client - server ssl support Key: DERBY-6764 URL: https://issues.apache.org/jira/browse/DERBY-6764 Project: Derby Issue Type: Task Reporter: Myrna van Lunteren Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability (CVE-2014-3566) Derby supports ssl between the client and network server. We should investigate this and decide if we need to change our product, e.g. to eliminate support for SSL in favor of its successor TLS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-6068) Increase the arbitrary 32K limit imposed by DRDA on number of Sections used for open statements
[ https://issues.apache.org/jira/browse/DERBY-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor reassigned DERBY-6068: -- Assignee: Mamta A. Satoor Increase the arbitrary 32K limit imposed by DRDA on number of Sections used for open statements Key: DERBY-6068 URL: https://issues.apache.org/jira/browse/DERBY-6068 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.10.1.1 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor We recommend users to close the statements ResultSet.getStatement().close() to make sure the statements get closed. But it would help us to increase the limit of 32K on open statements in case a machine is slow and gargbage collection is not happening fast enough. One instance where we ran into this 32K limit violation is DERBY-6054. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6068) Increase the arbitrary 32K limit imposed by DRDA on number of Sections used for open statements
[ https://issues.apache.org/jira/browse/DERBY-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172049#comment-14172049 ] Mamta A. Satoor commented on DERBY-6068: The 32K limit is imposed by maxNumSections field in org.apache.derby.client.am.SectionManager. I researched this further and found that this limit is dictated by DRDA specification in Volumn 1: Distributed Relational Database Architecture (DRDA). It is covered under SQL Section Number Assignment (SN Rules) on page 489 as copied below SN1 A section number is between 1 and 32,767 inclusive. Based on this, I do not believe we can increase the limit on section numbers. In the past we had run into one issue because of this limitation DERBY-6054 but it was possible to tweak customer's environment to avoid this limitation. Other than that case, I do not think we have run into any issues because of 32K limit. I will close this jira as won't fix. Please let me know if my understanding of the spec is not correct. Increase the arbitrary 32K limit imposed by DRDA on number of Sections used for open statements Key: DERBY-6068 URL: https://issues.apache.org/jira/browse/DERBY-6068 Project: Derby Issue Type: Improvement Components: Network Server Affects Versions: 10.10.1.1 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor We recommend users to close the statements ResultSet.getStatement().close() to make sure the statements get closed. But it would help us to increase the limit of 32K on open statements in case a machine is slow and gargbage collection is not happening fast enough. One instance where we ran into this 32K limit violation is DERBY-6054. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
