date:20120217


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

Kim Haase closed DERBY-5372.



Issue was resolved several months ago, so closing.

 Need to document that the != and  operators are pushed into Restricted 
 table functions (once the work on DERBY-5369 wraps up)
 ---

 Key: DERBY-5372
 URL: https://issues.apache.org/jira/browse/DERBY-5372
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
Assignee: Kim Haase
 Fix For: 10.8.2.2, 10.9.0.0

 Attachments: DERBY-5372.diff, cdevspecialtfrestr.html


 DERBY-5369 makes restricted table functions smarter. When work finishes on 
 that issue, we will want to document the fact that the != and  operators 
 are pushed into restricted table functions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (DERBY-5384) Reference Guide talks about a DriverManager method which does not exist.


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

Kim Haase closed DERBY-5384.



Issue was resolved several months ago, so closing.

 Reference Guide talks about a DriverManager method which does not exist.
 

 Key: DERBY-5384
 URL: https://issues.apache.org/jira/browse/DERBY-5384
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
Assignee: Kim Haase
 Fix For: 10.8.2.2, 10.9.0.0

 Attachments: DERBY-5384.diff, DERBY-5384.stat, DERBY-5384.zip


 The section titled java.sql.Driver interface in the Reference Guide 
 mentions the DriverManager.unload() method. There is no such method. I 
 believe that DriverManager.deregisterDriver() is intended.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-866) Derby User Management Enhancements

2012-02-17 Thread Rick Hillegas (Updated) (JIRA)


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

Rick Hillegas updated DERBY-866:


Attachment: UserManagement.html

Attaching rev 6 of the functional spec. This rev clarifies a couple points:

oClarify that if NATIVE authentication is set at the system level, it can 
still be overridden at the database level using database-only properties.

oClarify that you must shutdown the network server before shutting down the 
Derby engine when you are using NATIVE authentication.


 Derby User Management Enhancements
 --

 Key: DERBY-866
 URL: https://issues.apache.org/jira/browse/DERBY-866
 Project: Derby
  Issue Type: Improvement
  Components: Services
Affects Versions: 10.2.1.6
Reporter: Francois Orsini
Assignee: Rick Hillegas
 Attachments: Derby_User_Enhancement.html, 
 Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, 
 UserManagement.html, UserManagement.html, UserManagement.html, 
 UserManagement.html, UserManagement.html, UserManagement.html, 
 derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, 
 derby-866-02-ag-createDropUser.diff, 
 derby-866-03-aa-resetModifyPassword.diff, 
 derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, 
 derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, 
 derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, 
 derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, 
 derby-866-09-ad-nativeAuthenticationService.diff, 
 derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, 
 derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, 
 derby-866-12-ac-passwordExpiration.diff, 
 derby-866-13-ab-systemWideOperationTests.diff, 
 derby-866-14-ac-badNativeSpec.diff, 
 derby-866-15-ae-dbInJarFileOrOnClasspath.diff, 
 derby-866-16-aa-credDBViaSubprotocol.diff, 
 derby-866-17-aa-grantRevokeNative.diff, dummyCredentials.properties


 Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec 
 attached to the JIRA).
 Abstract:
 This feature aims at improving the way BUILT-IN users are managed in Derby by 
 providing a more intuitive and familiar DDL interface. Currently (in 
 10.1.2.1), Built-In users can be defined at the system and/or database level. 
 Users created at the system level can be defined via JVM or/and Derby system 
 properties in the derby.properties file. Built-in users created at the 
 database level are defined via a call to a Derby system procedure 
 (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
 Defining a user at the system level is very convenient and practical during 
 the development phase (EOD) of an application - However, the user's password 
 is not encrypted and consequently appears in clear in the derby.properties 
 file. Hence, for an application going into production, whether it is embedded 
 or not, it is preferable to create users at the database level where the 
 password is encrypted.
 There is no real ANSI SQL standard for managing users in SQL but by providing 
 a more intuitive and known interface, it will ease Built-In User management 
 at the database level as well as Derby's adoption.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (DERBY-5527) Documentation problem: 5 - Verifying the copy of the files

2012-02-17 Thread Kim Haase (Assigned) (JIRA)


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

Kim Haase reassigned DERBY-5527:


Assignee: Kim Haase

 Documentation problem: 5 - Verifying the copy of the files
 --

 Key: DERBY-5527
 URL: https://issues.apache.org/jira/browse/DERBY-5527
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.8.2.2
Reporter: Andres Gomez Casanova
Assignee: Kim Haase
Priority: Trivial
  Labels: docuentation
   Original Estimate: 1h
  Remaining Estimate: 1h

 Creating a directory and copying scripts into the directory
 http://db.apache.org/derby/docs/dev/getstart/
 The fifth step of the procedure to Creating a directory and copying scripts 
 into the directory, there is a verify copy, but the Current path is on the 
 DERBYTUTOR directory, but in the previous step, the procedure indicated to 
 change to that directory.
 I mean, the verify should be only a dir or ls without any parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (DERBY-5334) Incorrect permission arguments given for SYSCS_UTIL.SYSCS_SET_USER_ACCESS


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

Kim Haase closed DERBY-5334.



Issue was resolved several months ago, so closing.

 Incorrect permission arguments given for SYSCS_UTIL.SYSCS_SET_USER_ACCESS
 -

 Key: DERBY-5334
 URL: https://issues.apache.org/jira/browse/DERBY-5334
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
Assignee: Kim Haase
 Fix For: 10.8.2.2, 10.9.0.0

 Attachments: DERBY-5334.diff, rrefsetuseraccess.html


 The Reference Guide topic for SYSCS_UTIL.SYSCS_SET_USER_ACCESS incorrectly 
 states that the permissions are
   fullAcess
   readOnlyAccess
 You will get an error if you try to set those permissions. The actual 
 permissions are
   FULLACCESS
   READONLYACCESS
 The following script shows this problem:
 ij connect 
 'jdbc:derby:memory:db;create=true;user=admin;password=adminpassword' as 
 admin_conn;
 ij call syscs_util.syscs_set_user_access ('BRUNNER', 'READONLYACCESS');
 0 rows inserted/updated/deleted
 ij call syscs_util.syscs_set_user_access ('BRUNNER', 'FULLACCESS');
 0 rows inserted/updated/deleted
 ij call syscs_util.syscs_set_user_access ('BRUNNER', null );
 0 rows inserted/updated/deleted
 ij call syscs_util.syscs_set_user_access ('BRUNNER', 'readOnlyAccess');
 ERROR XCZ00: Unknown permission 'readOnlyAccess'.
 ij call syscs_util.syscs_set_user_access ('BRUNNER', 'fullAccess');
 ERROR XCZ00: Unknown permission 'fullAccess'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (DERBY-5404) Document DBO restriction for four diagnostic VTIs


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

Kim Haase closed DERBY-5404.



Thanks for updating the component, Mike.

 Document DBO restriction for four diagnostic VTIs
 -

 Key: DERBY-5404
 URL: https://issues.apache.org/jira/browse/DERBY-5404
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.8.2.2, 10.9.0.0
Reporter: Kim Haase
Assignee: Kim Haase
 Fix For: 10.8.2.2, 10.9.0.0

 Attachments: DERBY-5404-2.diff, DERBY-5404.diff, 
 rrefsyscsdiagtables.html, rrefsyscsdiagtables.html


 DERBY-5395 restricts access to these four diagnostic tables/functions to the 
 database owner:
   syscs_diag.statement_cache
   syscs_diag.transaction_table
   syscs_diag.error_log_reader( )
   syscs_diag.statement_duration() 
 The topic SYSCS_DIAG diagnostic tables and functions should include this 
 information.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (DERBY-4408) missing DOCTYPE and META tags in toc.html and index.html pages


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

Kim Haase closed DERBY-4408.



Issue was resolved several months ago, so closing.

 missing DOCTYPE and META tags in toc.html and index.html pages
 --

 Key: DERBY-4408
 URL: https://issues.apache.org/jira/browse/DERBY-4408
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.3.3.0
Reporter: Myrna van Lunteren
Assignee: Kim Haase
 Fix For: 10.8.2.2, 10.9.0.0

 Attachments: DERBY-4408-2.diff, DERBY-4408-3.diff, DERBY-4408-3.stat, 
 DERBY-4408-3.zip, DERBY-4408-4.diff, DERBY-4408-5.diff, DERBY-4408-5.stat, 
 DERBY-4408-6.diff, DERBY-4408-6.stat, DERBY-4408.diff, DERBY-4408.diff, 
 DERBY-4408.stat, DERBY-4408.zip, index.html, insert-header.diff, toc.html


 I found a tool that analyzes the documentation for possible accessibility 
 issues, and it found that the index.html and toc.html files from all 6 books 
 have issues:
   INDEX.HTML
  977   Missing DOCTYPE tag.  Required to define version of XHTML being 
 used.   
  833   Missing META tag.  Required CHARSET value must be defined in this 
 file. 
  TOC.HTML
  831   Missing DOCTYPE tag.  Required to define version of HTML being 
 used.  Line: 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (DERBY-4637) The Developer's Guide implies that, for in-memory database names, Derby does not resolve relative and absolute paths to the same in-memory database


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

Kim Haase closed DERBY-4637.



Issue was resolved several months ago, so closing.

 The Developer's Guide implies that, for in-memory database names, Derby does 
 not resolve relative and absolute paths to the same in-memory database
 ---

 Key: DERBY-4637
 URL: https://issues.apache.org/jira/browse/DERBY-4637
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.6.1.0
Reporter: Rick Hillegas
Assignee: Kim Haase
 Fix For: 10.8.2.2, 10.9.0.0

 Attachments: DERBY-4637.diff, DERBY-4637.stat, DERBY-4637.zip


 The Developer's Guide says in the section titled 'Conventions for specifying 
 the database path':
 When accessing databases from the file system (instead of from memory, the 
 classpath, or a jar file), any path that is not absolute is interpreted as 
 relative to the system directory.
 A casual reader might interpret this to mean that the system directory is not 
 used to resolve paths in the names of in-memory databases. But, in fact, 
 Derby does use the system directory to qualify relative paths in the names of 
 in-memory databases.
 For instance, if the system directory is /Users/blah/derby/dummy, then Derby 
 treats the following  urls as identifiers for the same in-memory database:
 jdbc:derby:memory:db
 jdbc:derby:memory:/Users/blah/derby/dummy/db
 Similarly, Derby treats the following urls as names for the same in-memory 
 database:
 jdbc:derby:memory:/foo/bar/db
 jdbc:derby:memory:/foo/bar/../bar/db
 The Developer's Guide could use a section on how to resolve in-memory 
 database names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DERBY-5621) Failure in SecureServerTest )junit.framework.AssertionFailedError: Failed ping after changing trace directory:

2012-02-17 Thread Kathey Marsden (Created) (JIRA)

Failure in SecureServerTest )junit.framework.AssertionFailedError: Failed ping 
after changing trace directory: 
---

 Key: DERBY-5621
 URL: https://issues.apache.org/jira/browse/DERBY-5621
 Project: Derby
  Issue Type: Bug
  Components: Network Server, Test
Affects Versions: 10.9.0.0
 Environment: ava.specification.name: Java Platform API Specification
java.specification.version: 1.6
java.runtime.version: pxi3260sr9fp1-20110208_03 (SR9 FP1)
java.fullversion: JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 
(JIT enabled, AOT enabled)
J9VM - 20110203_074623
JIT  - r9_20101028_17488ifx3
GC   - 20101027_AA
Reporter: Kathey Marsden


I saw this failure on Linux IBM 1.6  Feb 15
http://people.apache.org/~myrnavl/derby_test_results/main/linux/testSummary-1244826.html

1) SecureServerTest( Opened = false, Authenticated= true, 
CustomDerbyProperties= null, WildCardHost= 0.0.0.0 
)junit.framework.AssertionFailedError: Failed ping after changing trace 
directory: 
at 
org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.setTraceDirectory(SecureServerTest.java:381)
at 
org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.testServerStartup(SecureServerTest.java:352)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [URGENT] Critical test situation on trunk

2012-02-17 Thread Katherine Marsden


On 2/3/2012 12:30 PM, Katherine Marsden wrote:
Right now the IBM Tests are not running due to a hang from in 
NativeAuthenticationServiceTest DERBY-5601


http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1239981.html 



 Oracle tests seem to be broken:
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1239719.html 



I am not sure if Oracle has the same issue or something else.

As far as I know these are our only sources of regression tests so I 
think we better close down trunk except for efforts to get the runs 
going again.  Unfortunately for DERBY-5601 I cannot reproduce at least 
with the single test on my machine.Unfortunately also I am about to 
head out of town for the weekend.


 Both IBM and Oracle tests are running through to completion now on all 
platforms. Thanks Rick for the hang fix, Kristian for the spawned 
process improvements and Myrna for debugging the environment and machine 
issues and Mike for making lots of intermittent test failure fixes and 
everyone who did local runs while things were down.  Such a community 
effort!


Here are the latest results with a few new failures.  I filed a new 
issue from the IBM runs in SecureServerTest but not the ones that show 
up in the oracle runs.


IBM trunk Test runs Feb 15 (1244826)
Windows all passed: 
people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1244826.html
Linux 1 new failure in SecureServerTest - 
http://people.apache.org/~myrnavl/derby_test_results/main/linux/testSummary-1244826.html
I filed https://issues.apache.org/jira/browse/DERBY-5621 for the Linux 
issue.


Oracle trunk test runs Feb 15 (1244593)
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-1244593.html
I see new failures in UpdateLocksTest on vista 1.5:  I will leave to 
someone with access to this system to file the issue and determine if it 
might be checkin related.

http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/testlog/vista/1244593-suitesAll_diff.txt

1) 
testReadUncommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)java.sql.SQLException:
 Table/View 'A' already exists in Schema 'APP'.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown 
Source)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
Source)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown 
Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown 
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown 
Source)
at 
org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:185)
at 
org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.testReadUncommitted(UpdateLocksTest.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
Caused by: ERROR X0Y32: Table/View 'A' already exists in Schema 'APP'.
at org.apache.derby.iapi.error.StandardException.newException(Unknown 
Source)
at 
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(Unknown
 Source)
at 
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(Unknown 
Source)
at 
org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown
 Source)
at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
Source)
... 36 more
There was 1 failure:
1) 
testSerializable(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError:
 Missing rows in

Regression Test Report - Daily 1245079 - Sun DBTG

2012-02-17 Thread Ole . Solberg

[Auto-generated mail]

*Daily* 1245079/2012-02-16 18:00:09 MET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.7*
 lin
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 sol
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 sol32
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 vista-64
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
  Details in  
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-1245079.html
 
  Attempted failure analysis in
  
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/1245079_bySig.html
 

*Jvm: 1.6*
 lin
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 sles
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 sol
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 sol32
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 solN+1
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 sparc
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll
   NA NA NANA   JDBCDriversClient
   NA NA NANA   JDBCDriversEmbedded
   NA NA NANA   derbyall
   NA NA NANA   compatibility
   NA NA NANA   demoSuite
 vista
   NA NA NANA   suitesAll
   NA NA NANA   jdbcapiAutoLoad
   NA NA NANA   JDBCDriversAll

[jira] [Commented] (DERBY-5620) Replace illegal characters from test name when creating the failure folder

2012-02-17 Thread Dag H. Wanvik (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210397#comment-13210397
 ] 

Dag H. Wanvik commented on DERBY-5620:
--

Thanks for fixing this! Why not just replace all non-identifier characters with 
underscore or dash? 

 Replace illegal characters from test name when creating the failure folder
 --

 Key: DERBY-5620
 URL: https://issues.apache.org/jira/browse/DERBY-5620
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.9.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
 Attachments: derby-5620-1a-replace_illegal_fs_chars.diff


 Since the name of a JUnit test case can be any string, it should be sanitized 
 and bad characters should be replaced with a valid one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5317) NullPointerException in org.apache.derby.client.net.Request.sendBytes() with client


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

Kathey Marsden updated DERBY-5317:
--

Labels: derby_triage10_9  (was: )

Triaged for 10.9.  Keeping urgency as urgent as it is a client crash and has a 
simple reproduction.

I confirmed the issue reproduces with Repro5317.java  attached and very quickly 
(in case someone has been shying away from this issue because I mentioned it 
takes a long time to reproduce with LobLimitsTest.


$ java Repro5317
Fri Feb 17 09:49:50 PST 2012 : Apache Derby Network Server - 10.9.0.0 alpha - 
(1242867M) started and ready to accept con
nections on port 1527

START insert  clob  -insertClob of size = 31744
Insert Clob (31744) rows= 2 = 382
Rows inserted with clob of size (31744) = 2


START ClobTest #4 - select and then update clob of size= 31744 - Uses setClob 
api
Fri Feb 17 09:49:52 PST 2012 : Execution failed because of a Distributed 
Protocol Error:  DRDA_Proto_SYNTAXRM; CODPNT ar
g  = 200d; Error Code Value = 1d. 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  = 200d; Error Code Value = 1d. Plaintext connection 
attempt from an SSL enabled client?
at 
org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:537)
at 
org.apache.derby.impl.drda.DRDAConnThread.invalidCodePoint(DRDAConnThread.java:8295)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:4366)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:4175)
at 
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:1063)
at 
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295)
Fri Feb 17 09:49:52 PST 2012 : Execution failed because of a Distributed 
Protocol Error:  DRDA_Proto_SYNTAXRM; CODPNT ar
g  = 200d; Error Code Value = 1d. 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  = 200d; Error Code Value = 1d. Plaintext connection 
attempt from an SSL enabled client?
at 
org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:537)
at 
org.apache.derby.impl.drda.DRDAConnThread.invalidCodePoint(DRDAConnThread.java:8295)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:4366)
at 
org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:4175)
at 
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:1063)
at 
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295)
Exception in thread main java.lang.NullPointerException
at org.apache.derby.client.net.Request.sendBytes(Request.java:1212)
at 
org.apache.derby.client.net.Request.flushScalarStreamSegment(Request.java:604)
at 
org.apache.derby.client.net.Request.padScalarStreamForError(Request.java:660)
at 
org.apache.derby.client.net.Request.writePlainScalarStream(Request.java:323)
at 
org.apache.derby.client.net.Request.writeScalarStream(Request.java:247)
at 
org.apache.derby.client.net.Request.writeScalarStream(Request.java:500)
at 
org.apache.derby.client.net.NetStatementRequest.buildEXTDTA(NetStatementRequest.java:1042)
at 
org.apache.derby.client.net.NetStatementRequest.writeExecute(NetStatementRequest.java:151)
at 
org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPreparedStatement.java:174)
at 
org.apache.derby.client.am.PreparedStatement.writeExecute(PreparedStatement.java:1806)
at 
org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2036)
at 
org.apache.derby.client.am.PreparedStatement.executeUpdateX(PreparedStatement.java:417)
at 
org.apache.derby.client.am.PreparedStatement.executeUpdate(PreparedStatement.java:403)
at Repro5317.selectUpdateClob(Repro5317.java:170)
at Repro5317.main(Repro5317.java:42)

kmarsden@IBM-JDPM42DBIO2 ~/repro/derby-5317























think Urgent is correct as 

  NullPointerException in org.apache.derby.client.net.Request.sendBytes()  
 with client
 -

 Key: DERBY-5317
 URL: https://issues.apache.org/jira/browse/DERBY-5317
 Project: Derby
  Issue Type: Bug
  Components: Network Client
Affects Versions: 10.9.0.0
Reporter: Kathey

[jira] [Updated] (DERBY-5338) When attempting to insert a 4GB stream client gives SQLState XN015 network protocol error vs embedded 22003 data too large for type


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

Kathey Marsden updated DERBY-5338:
--

   Urgency: Normal
Bug behavior facts: Crash,Embedded/Client difference  (was: Embedded/Client 
difference)
Labels: derby_triage10_9  (was: )

Triaging for 10.9. Marking urgency as normal as this is a disallowed operation, 
but since the connection is lost, marking it as a crash.  This test in 
LobLimitsTest should be changed to eliminate the special client condition to 
reproduce the issue.


   public void test_02_BlobNegative() throws SQLException {
// Negative Test, use setBlob api to insert a 4GB blob.
setAutoCommit(false);
PreparedStatement insertBlob =
prepareStatement(INSERT INTO BLOBTBL values (?,?,?,?));

BlobImplT _4GbBlob =
new BlobImplT(new RandomByteStreamT(new java.util.Random(),
_4GB), _4GB);

try {
insertBlob_SetBlob(BlobTest #7 (setBlob with 4Gb blob,
insertBlob, _4GbBlob,
_4GB, 0, 1, 0);
fail(Inserting 4BG blob should have thrown exception);
} catch (SQLException sqle) {
// DERBY DOES NOT SUPPORT INSERT OF 4GB BLOB
if (usingDerbyNetClient()) {
// DERBY-5338 client gives wrong SQLState and protocol error
// inserting a 4GB clob. Should be 22003
assertSQLState(XN015,sqle);
} else {
assertSQLState(22003, sqle);
}
commit();
}

 When attempting to insert a 4GB stream client gives SQLState XN015 network 
 protocol error vs embedded 22003 data too large for type
 ---

 Key: DERBY-5338
 URL: https://issues.apache.org/jira/browse/DERBY-5338
 Project: Derby
  Issue Type: Bug
  Components: Network Client
Affects Versions: 10.9.0.0
Reporter: Kathey Marsden
Priority: Minor
  Labels: derby_triage10_9

 In converting LobLimits test DERBY-1903, I see that attempting to insert a 
 4GB stream with client gives the error XN015
 Caused by: org.apache.derby.client.am.SqlException: Network protocol error: 
 the specified size of the InputStream, parameter #4, is less than the actual 
 InputStream length.
   at 
 org.apache.derby.client.net.Request.writePlainScalarStream(Request.java:359)
   at 
 org.apache.derby.client.net.Request.writeScalarStream(Request.java:247)
   at 
 org.apache.derby.client.net.NetStatementRequest.buildEXTDTA(NetStatementRequest.java:963)
   at 
 org.apache.derby.client.net.NetStatementRequest.writeExecute(NetStatementRequest.java:151)
   at 
 org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPreparedStatement.java:174)
   at 
 org.apache.derby.client.am.PreparedStatement.writeExecute(PreparedStatement.java:1800)
   at 
 org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2030)
   at 
 org.apache.derby.client.am.PreparedStatement.executeUpdateX(PreparedStatement.java:417)
   at 
 org.apache.derby.client.am.PreparedStatement.executeUpdate(PreparedStatement.java:403)
   ... 38 more
 vs's embedded's 22003, the length exceeds the maximum length for the data 
 type.
 I am not sure if the connection is lost or not. It typically is with protocol 
 errors.
 Look for this bug number in largedata.LobLimits.java for test case.
 You can remove the exclusion for usingDerbyNetClient and run 
 org.apache.derbyTesting.functionTests.tests.largedata.LobLimitsLiteTest 
 to reproduce the problem.  I will check the test case in soon as part of 
 DERBY-1903

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5341) Client allows insert of stream in excess of column with non-white space characters


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

Kathey Marsden updated DERBY-5341:
--

   Urgency: Urgent
Bug behavior facts: Deviation from standard,Embedded/Client 
difference,Wrong query result  (was: Embedded/Client difference,Wrong query 
result)
Labels: derby_triage10_9  (was: )

Triage for 10.9.  Marking Urgent since it has wrong results.



 Client allows insert of stream in excess of column with  non-white space 
 characters
 ---

 Key: DERBY-5341
 URL: https://issues.apache.org/jira/browse/DERBY-5341
 Project: Derby
  Issue Type: Bug
  Components: Network Client
Affects Versions: 10.9.0.0
Reporter: Kathey Marsden
  Labels: derby_triage10_9

 In converting LobLimits.java DERBY-1903 and trying to enable 
 LobLimitsLiteTest with client. I discovered that this  case fails with client:
try {
 insertClob2(ClobTest #9.1 , conn, insertClob2,
 MORE_DATA_THAN_COL_WIDTH, 4, 1,
MORE_DATA_THAN_COL_WIDTH, CHARDATAFILE);
 fail(ClobTest #9.1  + should have thrown XSDA4); 
 } catch (SQLException sqle) {
 assertSQLState(XSDA4, sqle);
 }
 // no row must be retrieved.
 selectClob2(ClobTest #9.2 , conn, selectClob2, BIG_LOB_SZ, 4, 0,
CHARDATAFILE);
 If I omit the fail assertion, the row actually does get inserted and has 
 presumably been truncated.
 I will check in LobLimits.java soon with this bug number in the comments.
 To reproduce, remove the if(!usingDerbyNetClient) condition and run the test 
 largedata.LobLimitsLiteTest to reproduce the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5411) Client that does not have Security manager permission to connect gets ERROR 08006: Insufficient data while reading from the network Message should be clearer


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

Kathey Marsden updated DERBY-5411:
--

Urgency: Low
 Labels: derby_triage10_9  (was: )

Triaging for 10.9. Marking urgency as low as the problem is that with incorrect 
usage (incorrect permissions) we throw an ugly and informative error instead of 
an informative one.

 Client that does not have Security manager permission to connect gets ERROR 
 08006: Insufficient data while reading from the network Message should be 
 clearer
 ---

 Key: DERBY-5411
 URL: https://issues.apache.org/jira/browse/DERBY-5411
 Project: Derby
  Issue Type: Bug
  Components: Network Client
Affects Versions: 10.8.2.2
Reporter: Kathey Marsden
Priority: Minor
  Labels: derby_triage10_9

 I was doing a little remote testing for the release candidate and noticed if 
 a machine does not have permission to connect, then the client shows the 
 following exception:
 ij connect  'jdbc:derby://9.72.133.41:1527/wombat';
 ERROR 08006: Insufficient data while reading from the network - expected a 
 minimum of 6 bytes and received only 0 bytes.  The connection has been term
 inated.
 java.sql.SQLNonTransientConnectionException: Insufficient data while reading 
 from the network - expected a minimum of 6 bytes and received only 0 byte
 s.  The connection has been terminated.
 at 
 org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
 Source)
 at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
 at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
 at java.sql.DriverManager.getConnection(DriverManager.java:322)
 at java.sql.DriverManager.getConnection(DriverManager.java:297)
 at org.apache.derby.impl.tools.ij.ij.dynamicConnection(Unknown Source)
 at org.apache.derby.impl.tools.ij.ij.ConnectStatement(Unknown Source)
 at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source)
 at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown 
 Source)
 at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main.main(Unknown Source)
 at org.apache.derby.tools.ij.main(Unknown Source)
 Caused by: org.apache.derby.client.am.DisconnectException: Insufficient data 
 while reading from the network - expected a minimum of 6 bytes and receiv
 ed only 0 bytes.  The connection has been terminated.
 at org.apache.derby.client.net.Reply.fill(Unknown Source)
 at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown 
 Source)
 at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source)
 at org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown 
 Source)
 at 
 org.apache.derby.client.net.NetConnectionReply.readExchangeServerAttributes(Unknown
  Source)
 at 
 org.apache.derby.client.net.NetConnection.readServerAttributesAndKeyExchange(Unknown
  Source)
 at 
 org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
  Source)
 at 
 org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
 at org.apache.derby.client.net.NetConnection.flowConnect(Unknown 
 Source)
 at org.apache.derby.client.net.NetConnection.init(Unknown Source)
 at org.apache.derby.client.net.NetConnection40.init(Unknown Source)
 at 
 org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown
  Source)
 ... 12 more
 It would be good to have a clearer error message:
 To Reproduce, use the script and policy file below changing the url for 
 derby.codejars to the correct path for  your enviroment also in the policy 
 file my.policy exchange x.x.x.x with the permitted host and y.y.y.y with the 
 disallowed host.  Then try to connect from the disllowed host with connect  
 'jdbc:derby://x.x.x.x:1527/wombat';
 Script startServer.sh:
 java  -Djava.security.manager 
 -Dderby.codejars=file:c:/cygwin/home/kmarsden/projects/10.8.2testing/db-derby-10.8.2.1-lib/lib/
  -Djava.security.policy=my.policy org.apache.derby.drda.NetworkServerControl 
 start -h 0.0.0.0
 Policy File my.policy (change x.x.x.x and y.y.y.y) to the allowed and 
 disallowed host respectively. )Since the y.y.y.y line is commented it is not 
 really relevant except for testing that remote connections work properly)
 grant codeBase ${derby.codejars}derby.jar
 {
 //
 // These

[jira] [Updated] (DERBY-5534) ResultSet#updateFloat, #updateDouble do not check for NaN and other conditions on client


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

Kathey Marsden updated DERBY-5534:
--

Issue  fix info: Newcomer,Repro attached
 Urgency: Normal
  Labels: derby_triage10_9  (was: )


Triage for 10.9.  Marking normal urgency also Newcomer.  Verified this test 
still fails when enabled for client. I am not totally sure what happens to the 
value, does something get updated since there is no exception?


  This test in ParameterMappingTest

// Remove test when DERBY-5534 is fixed
if (usingEmbedded()) {
assertUpdateState(rs, F04,
  _X, Float.NaN, XXX_FLOAT, 22003);
assertUpdateState(rs, F04,
  _X, Double.MIN_VALUE, XXX_DOUBLE, 22003);

// REAL DB2 limits: remove if DERBY-3398 is implemented
assertUpdateState(rs, F04, bdSmallestPosFloatValue, 22003);
assertUpdateState(rs, F04, bdSmallestNegFloatValue, 22003);

assertUpdateState(rs, F04, bdMaxFloatValue, 22003);
assertUpdateState(rs, F04, bdMinFloatValue, 22003);
}


here was 1 failure:
) 
testDerby5533UpdateXXX(org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest)junit.framework
ionFailedError: exception expected
   at 
org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.assertUpdateState(ParameterMap
t.java:5051)
   at 
org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testDerby5533UpdateXXX(Paramet
ngTest.java:4775)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
   at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

FAILURES!!!
Tests run: 18,  Failures: 1,  Errors: 0



 ResultSet#updateFloat, #updateDouble do not check for NaN and other 
 conditions on client
 

 Key: DERBY-5534
 URL: https://issues.apache.org/jira/browse/DERBY-5534
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.8.2.2
Reporter: Dag H. Wanvik
Priority: Minor
  Labels: derby_triage10_9

 In updateXXX, where XXX is one of Float or Double, embedded throws value out 
 of range when the argument is Float.NaN or Double.NaN, the client does not 
 catch it.
 The server will balk when the row is updated, though, in ResultSet#updateRow. 
 It will be more regular if this is caught in updateXXX also on the client as 
 other range errors are.  The SQL state seen is 22003, which is what embedded 
 throws on updateXXX. See also DERBY-5533.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5553) System property for client tracing -Dderby.client.traceDirectory does not work with XADataSource

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

Kathey Marsden updated DERBY-5553:
--

Issue fix info: High Value Fix,Newcomer
Urgency: Normal
Labels: derby_10.9 (was: )

Triage for 10.9. Marking Newcomer and High Value Fix as it should be straight
forward and as Brett discovered, it can be quite frustrating when diagnosing a
problem to find the diagnostics don't work.

System property for client tracing -Dderby.client.traceDirectory does not
work with XADataSource

Key: DERBY-5553
URL: https://issues.apache.org/jira/browse/DERBY-5553
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.8.2.2, 10.9.0.0
Reporter: Kathey Marsden
Labels: derby_triage10_9
Attachments: XATemplate.java, utilXid.java

The client system property -Dderby.client.traceDirectory does not work with
ClientXADataSource. No trace files are created if this property is set when
making XA Connections.
I am sure it works fine with DriverManager connections and also checked
tracing works fine using connection attributes and XA with.
ds.setConnectionAttributes(traceDirectory=./traceDir);
I have not checked ClientDataSource or ClientConnectionPoolDataSource.
Attached is a reproduction for this issue.
mkdir ./traceDir
javac -g XATemplate.java utilXid.java
java -Dderby.client.traceDirectory=./traceDir XATemplate
You will see that traceDir is empty.
This came up when debugging DERBY-5552

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5560) Java deadlock between LogicalConnection40 and ClientXAConnection40


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

Kathey Marsden updated DERBY-5560:
--

  Issue  fix info: High Value Fix
   Urgency: Urgent
Bug behavior facts: Crash,Performance,Seen in production  (was: Seen in 
production,Performance)
Labels: derby_triage10_9  (was: )

Triage for 10.9. Marking Urgent, Crash (hang) and High Value Fix as we already 
have a patch.  Just need a volunteer to run tests and hopefully  add a test 
case and we can get this checked in.


 Java deadlock between LogicalConnection40 and ClientXAConnection40
 --

 Key: DERBY-5560
 URL: https://issues.apache.org/jira/browse/DERBY-5560
 Project: Derby
  Issue Type: Bug
  Components: Network Client
Affects Versions: 10.8.2.2
 Environment: Solaris 10
 Glassfish V2.1.1 
 ClientXADataSource connection pool setup to close all connections on any error
Reporter: Brett Bergquist
  Labels: derby_triage10_9
 Attachments: DERBY-5560.patch


 There is a Java deadlock between LogicalConnection40 and 
 ClientXAConnection40.  The order of calls that cause the deadlock are:
 Thread 1
 
 LogicalConnection.close
 ClientPooledConnection.recycleConnection
 Thread 2
 
 ClientPooledConnection.close
 LogicalConnection.nullPhysicalConnection
 Thread 1 acquires a lock on the LogicalConnection and attempts to acquire a 
 lock on the ClientPooledConnection
 Thread 2 acquires a lock on the ClientPooledConnection and attempts to 
 acquire a lock on the LogicalConnection
 In production this occurs when one thread is committing a transaction and 
 another thread is trying to close the connection.  This occurred because the 
 Glassfish connection pool is setup to close all connections on any error on 
 any connection and an error has been detected on another connection in the 
 pool.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5561) Race conditions in LogicalConnection checking for a null physical connection


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

Kathey Marsden updated DERBY-5561:
--

Issue  fix info: High Value Fix,Patch Available
 Urgency: Urgent
  Labels: derby_triage10_9  (was: )

Triage for 10.9.  Urgent, High Value Fix. Thanks Brett for the patch and 
Siddharth for picking up the testing and driving it to commit.


 Race conditions in LogicalConnection checking for a null physical connection
 

 Key: DERBY-5561
 URL: https://issues.apache.org/jira/browse/DERBY-5561
 Project: Derby
  Issue Type: Bug
  Components: Network Client
Affects Versions: 10.8.2.2
 Environment: Solaris 10
 Glassfish V2.1.1
 ClientXADataSource connection pool
Reporter: Brett Bergquist
Assignee: Siddharth Srivastava
  Labels: derby_triage10_9
 Attachments: DERBY-5561.patch


 There are race conditions with checkForNullPhysicalConnection calls in 
 LogicalConnection.  checkForNullPhysicalConnection is not synchronized and it 
 checks for the member phsyicalConnection which can be cleared by 
 nullPhsyicalConnection (which is synchronized) and close (which is 
 synchronized) and closeWithoutRecyclingToPool (which is synchronized).
 This affects nativeSQL, getAutoCommit, getTransactionIsolation, 
 getWarnings, isReadOnly, getCatalog, getTypeMap, createStatement, 
 prepareCall, prepareStatement, setHoldability, getHoldability, 
 setSavePoint, rollBack, releaseSavePoint, getSchema, setSchema.
 All of these call checkForNullPhysicalConnection and then use the member 
 physicalConnection after that call returns.  Because these methods are not 
 synchronized, between the time checkForNullPhysicalConnectoin returns and 
 physicalConnection is used, the physicalConnection member could be set to 
 null and then a NPE occurs.
 Probably all of these methods should be changed to synchronized.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5607) Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server

2012-02-17 Thread Kathey Marsden (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210438#comment-13210438
 ] 

Kathey Marsden commented on DERBY-5607:
---

Would it make sense to  avoid DriverManager usage in EmbeddedDataSource?



 Deadlock in Java 5 VM when using NATIVE authentication with a client running 
 in the same VM as the server
 -

 Key: DERBY-5607
 URL: https://issues.apache.org/jira/browse/DERBY-5607
 Project: Derby
  Issue Type: Bug
  Components: Network Client, Network Server, Services
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Attachments: NASTHang.java, derby-5607-01-aa-userInternalDriver.diff


 A deadlock in the Java 5 VM hangs connection attempts if you are using NATIVE 
 authentication with a client which runs in the same VM as the server. I will 
 attach a test case which demonstrates this. This bug is implicated in the 
 failures being discussed on https://issues.apache.org/jira/browse/DERBY-5601 
 and was disclosed by the discussion on this email thread: 
 http://old.nabble.com/-URGENT--Critical-test-situation-on-trunk-to33259629.html#a33259629
 The bug arises when NativeAuthenticationServiceImpl attempts a nested 
 connection to the Credentials database during database creation. The nested 
 connection is attempted in order to dertermine whether the user has 
 system-wide privilege to create databases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5220) Output from org.apache.derby.drda.NetworkServerControl runtimeinfo are truncated if the amount of data exceeds some threshold


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

Kathey Marsden updated DERBY-5220:
--

Urgency: Low
 Labels: derby_triage10_9  (was: )

Soren Vejrup Carlsen, can you verify this problem is fixed with 10.8.2.2 which 
has the fix for DERBY-5326?
Knut mentioned that fix may correct this problem.  

Also triage for 10.9. Mark low for now. Awaiting fix verification.



 Output from org.apache.derby.drda.NetworkServerControl runtimeinfo are 
 truncated if the amount of data exceeds some threshold
 -

 Key: DERBY-5220
 URL: https://issues.apache.org/jira/browse/DERBY-5220
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.5.3.0
 Environment:  java -Xmx1536m  -cp 
 /home/test/CSRTEST7/lib/db/derbynet.jar:/home/test/CSRTEST7/lib/db/derby.jar 
 org.apache.derby.drda.NetworkServerControl sysinfo -p 8128
 - Derby Network Server Information 
 Version: CSS10050/10.5.3.0 - (802917)  Build: 802917  DRDA Product Id: 
 CSS10050
 -- listing properties --
 derby.drda.maxThreads=0
 derby.drda.sslMode=off
 derby.drda.keepAlive=true
 derby.drda.minThreads=0
 derby.drda.portNumber=8128
 derby.drda.logConnections=false
 derby.drda.timeSlice=0
 derby.drda.startNetworkServer=false
 derby.drda.host=localhost
 derby.drda.traceAll=false
 -- Java Information --
 Java Version:1.6.0_21
 Java Vendor: Sun Microsystems Inc.
 Java home:   /usr/java/jdk1.6.0_21/jre
 Java classpath:  
 /home/test/CSRTEST7/lib/db/derbynet.jar:/home/test/CSRTEST7/lib/db/derby.jar
 OS name: Linux
 OS architecture: i386
 OS version:  2.6.18-53.el5PAE
 Java user name:  test
 Java user home:  /home/test
 Java user dir:   /home/test/CSRTEST7
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.6
 - Derby Information 
 JRE - JDBC: Java SE 6 - JDBC 4.0
 [/home/test/CSRTEST7/lib/db/derby.jar] 10.5.3.0 - (802917)
 [/home/test/CSRTEST7/lib/db/derbynet.jar] 10.5.3.0 - (802917)
 --
 - Locale Information -
 --
Reporter: Soren Vejrup Carlsen
  Labels: derby_triage10_9

 When using the runtimeinfo command with the 
 org.apache.derby.drda.NetworkServerControl program
 It seems that the output is truncated, as if the output exceeeds some 
 threshold or met some internal timeout, so that it does not wait for the rest 
 of the data.
 In that case, the output starts with 
 {code}
 -- Derby Network Server Runtime Information ---
 -- Session Information ---
 Session # :1
 Database :harvestDatabase/fullhddb
 User :APP
 # Statements:12
 {code}
 but does not end with something like
 {code}
 -
 # Connection Threads : 3
 # Active Sessions : 3
 # Waiting  Sessions : 0
 Total Memory : 64356352   Free Memory : 62239544
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5607) Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server

2012-02-17 Thread Rick Hillegas (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210446#comment-13210446
 ] 

Rick Hillegas commented on DERBY-5607:
--

Hi Kathey,

That might make sense and might eliminate other possible deadlocks in the VM. 
On the other hand, Derby bootstrapping has proven to be very brittle and we 
would want to think about this carefully. Unless we have evidence that there is 
another deadlock in there, I would advice caution. Thanks.

 Deadlock in Java 5 VM when using NATIVE authentication with a client running 
 in the same VM as the server
 -

 Key: DERBY-5607
 URL: https://issues.apache.org/jira/browse/DERBY-5607
 Project: Derby
  Issue Type: Bug
  Components: Network Client, Network Server, Services
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Attachments: NASTHang.java, derby-5607-01-aa-userInternalDriver.diff


 A deadlock in the Java 5 VM hangs connection attempts if you are using NATIVE 
 authentication with a client which runs in the same VM as the server. I will 
 attach a test case which demonstrates this. This bug is implicated in the 
 failures being discussed on https://issues.apache.org/jira/browse/DERBY-5601 
 and was disclosed by the discussion on this email thread: 
 http://old.nabble.com/-URGENT--Critical-test-situation-on-trunk-to33259629.html#a33259629
 The bug arises when NativeAuthenticationServiceImpl attempts a nested 
 connection to the Credentials database during database creation. The nested 
 connection is attempted in order to dertermine whether the user has 
 system-wide privilege to create databases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5234) Unable to insert data into table. Failed due be ERROR XSDG0: Page Page(51919,Container(0, 1104)) could not be read from disk.


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

Kathey Marsden updated DERBY-5234:
--

 Component/s: (was: Network Server)
  (was: SQL)
  (was: JDBC)
  Store
Priority: Critical  (was: Major)
Issue  fix info: High Value Fix,Repro attached
  Labels: ERROR XSDG0 apache corruption data derby derby_triage10_9 
 (was: ERROR XSDG0 apache corruption data derby)

Triage for 10.9. Marking Critical priority,  Urgent Urgency, High Value Fix.  
Changing component to store. I was able to reproduce with the attached repro at 
 10.9.0.0 alpha - (1242867)

java.sql.SQLException: Page Page(10219,Container(0, 1168)) could not be read 
from disk.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278)
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:2340)
at 
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1715)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:311)
at DbCompressErrorTester.insertData(DbCompressErrorTester.java:162)
at DbCompressErrorTester.test(DbCompressErrorTester.java:116)
at DbCompressErrorTester.main(DbCompressErrorTester.java:38)
Caused by: java.sql.SQLException: Page Page(10219,Container(0, 1168)) could not 
be read from disk.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:12
2)
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
... 12 more
Caused by: java.sql.SQLException: Java exception: 'Reached end of file while 
attempting to read a whole page.: java.io.E
OFException'.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:12
2)
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:436)
... 10 more
Caused by: java.io.EOFException: Reached end of file while attempting to read a 
whole page.
at 
org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:1169)
at 
org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(RAFContainer4.java:430)
at 
org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:370)
at 
org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:263)
at 
org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:673)
at 
org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:193)
at 
org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295)
at 
org.apache.derby.impl.store.raw.data.FileContainer.initPage(FileContainer.java:2430)
at 
org.apache.derby.impl.store.raw.data.FileContainer.newPage(FileContainer.java:1878)
at 
org.apache.derby.impl.store.raw.data.BaseContainer.addPage(BaseContainer.java:314)
at 
org.apache.derby.impl.store.raw.data.BaseContainerHandle.addPage(BaseContainerHandle.java:183)
at 
org.apache.derby.impl.store.access.heap.HeapController.doInsert(HeapController.java:302)
at 
org.apache.derby.impl.store.access.heap.HeapController.insert(HeapController.java:575)
at 
org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java:457)
at 
org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:999)
at 
org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:519)
at

[jira] [Updated] (DERBY-5261) NetworkServerControl prints usage message twice on some errors


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

Kathey Marsden updated DERBY-5261:
--

Urgency: Low
 Labels: derby_triage10_9  (was: )

 NetworkServerControl prints usage message twice on some errors
 --

 Key: DERBY-5261
 URL: https://issues.apache.org/jira/browse/DERBY-5261
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.8.1.2
Reporter: Knut Anders Hatlen
Priority: Minor
  Labels: derby_triage10_9

 If you invoke NetworkServerControl with an invalid command, the usage message 
 will be printed twice.
 $ java -jar derbynet.jar abc
 Mon Jun 06 10:14:25 CEST 2011 : Command abc is unknown.
 Usage: NetworkServerControl commands 
 Commands:
 start [-h host] [-p portnumber] [-noSecurityManager] [-ssl sslmode]
 shutdown [-h host][-p portnumber] [-ssl sslmode] [-user username] 
 [-password password]
 ping [-h host][-p portnumber] [-ssl sslmode]
 sysinfo [-h host][-p portnumber] [-ssl sslmode]
 runtimeinfo [-h host][-p portnumber] [-ssl sslmode]
 logconnections {on|off} [-h host][-p portnumber] [-ssl sslmode]
 maxthreads max[-h host][-p portnumber] [-ssl sslmode]
 timeslice milliseconds[-h host][-p portnumber] [-ssl sslmode]
 trace {on|off} [-s session id][-h host][-p portnumber] [-ssl sslmode]
 tracedirectory traceDirectory[-h host][-p portnumber] [-ssl sslmode]
 Mon Jun 06 10:14:25 CEST 2011 : No command given.
 Usage: NetworkServerControl commands 
 Commands:
 start [-h host] [-p portnumber] [-noSecurityManager] [-ssl sslmode]
 shutdown [-h host][-p portnumber] [-ssl sslmode] [-user username] 
 [-password password]
 ping [-h host][-p portnumber] [-ssl sslmode]
 sysinfo [-h host][-p portnumber] [-ssl sslmode]
 runtimeinfo [-h host][-p portnumber] [-ssl sslmode]
 logconnections {on|off} [-h host][-p portnumber] [-ssl sslmode]
 maxthreads max[-h host][-p portnumber] [-ssl sslmode]
 timeslice milliseconds[-h host][-p portnumber] [-ssl sslmode]
 trace {on|off} [-s session id][-h host][-p portnumber] [-ssl sslmode]
 tracedirectory traceDirectory[-h host][-p portnumber] [-ssl sslmode]
 Printing it once should be enough.
 The same problem is seen if you don't specify a required argument for an 
 option. For example java -jar derbynet start -p (no port number).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5328) The private fields of the NetServlet can be changed by multiple threads, giving rise to race conditions and corruptions.

2012-02-17 Thread Kathey Marsden (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210468#comment-13210468
]

Kathey Marsden commented on DERBY-5328:
---

Rick committed a change for this issue:
#1155367Tue Aug 09 13:56:04 UTC 2011rhillegas
DERBY-5328: Improve the re-entrancy of the NetServlet.
Files Changed
MODIFY /db/derby/code/trunk/java/drda/org/apache/derby/drda/NetServlet.java
Comment

Is it fixed or is there more work to do?

The private fields of the NetServlet can be changed by multiple threads,
giving rise to race conditions and corruptions.

Key: DERBY-5328
URL: https://issues.apache.org/jira/browse/DERBY-5328
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
Attachments: derby-5328-01-aa-simpleFields.diff

At the beginning of the NetServlet class, there are a number of private
fields. These fields can be inspected and changed by any thread running
inside NetServlet.doGet(). Due to the way that app servers dispatch servlet
requests, this means that multiple threads can be operating inside doGet() at
the same time, clobbering one another's work. The weirdest instance of this
is the shared PrintWriter (called out) which is used to produce the
response web page sent back by the servlet. Multiple threads all writing to
the same PrintWriter will create a very bizarre response page. The following
improvements should be made:
1) The server field should be set by a synchronized method.
2) Every run through doGet() should create its own PrintWriter which is
passed to other methods. The instance-wide out field should be removed.
3) Various other fields should be re-coded using the Atomic classes
introduced by Java 5. These fields include logStatus and traceStatus.
This solution can be implemented if the community votes to approve the
sunsetting of JVM 1.4 (currently at the polls).

[jira] [Updated] (DERBY-5400) Toggling of network tracing should be protected by requiring the user to specify the credentials of the system administrator.


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

Kathey Marsden updated DERBY-5400:
--

Issue  fix info: Release Note Needed
  Labels: derby_triage10_9  (was: )

Triage for 10.9.

Marking Release note needed as this would be a behavior change.


 Toggling of network tracing should be protected by requiring the user to 
 specify the credentials of the system administrator.
 -

 Key: DERBY-5400
 URL: https://issues.apache.org/jira/browse/DERBY-5400
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
  Labels: derby_triage10_9

 For servers which are brought up with the system administrator's credentials, 
 we should require those credentials to be specified when turning network 
 tracing on and off.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5401) The NetServlet should require system administrator credentials in order to perform its operations on a server which requires authentication.


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

Kathey Marsden updated DERBY-5401:
--

Issue  fix info: Release Note Needed
  Labels: derby_triage10_9  (was: )

Triage for 10.9. Marking relese note needed as it will be a behavior change.
I tend to think that the servlet is mostly there for demo purposes, so 
considered changing urgency to Low, but left it at Normal.


 The NetServlet should require system administrator credentials in order to 
 perform its operations on a server which requires authentication.
 

 Key: DERBY-5401
 URL: https://issues.apache.org/jira/browse/DERBY-5401
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
  Labels: derby_triage10_9

 If Derby authentication is required on the VM running derby.war, then the 
 NetServlet forms should require system administrator credentials in order to 
 issue any commands. In addition, the network connection between the browser 
 forms and the VM should be encrypted so that those credentials cannot be 
 snooped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (DERBY-5511) NetworkServerControl start in java applicaton but it's exit with application main thread exit

2012-02-17 Thread Kathey Marsden (Resolved) (JIRA)


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

Kathey Marsden resolved DERBY-5511.
---

Resolution: Not A Problem

Resolving Not a Problem per earlier comments.


 NetworkServerControl start in java applicaton but it's exit with application 
 main thread exit
 -

 Key: DERBY-5511
 URL: https://issues.apache.org/jira/browse/DERBY-5511
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.8.2.2
 Environment: java 1.6.0_u29 64bit windows 7 sp1 
Reporter: moonumi

 public static void main(String[] args) {
 NetworkServerControl serverControl=new 
 NetworkServerControl(InetAddress.getByName(localhost),1527);
 serverControl.start(new PrintWriter(System.out,true));
 }
 run java application.
 derby started servermode.
 but imediate exit with application main thread.
 it do not wait other connection.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs


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

Kathey Marsden updated DERBY-5552:
--

Urgency: Urgent
 Labels: derby_triage10_9  (was: )

Triage for 10.9. 
This issue is in progress and should be committed soon.

I think I am going to just double check that subsequent operations on the 
connection start a new local transaction and that the old global transaction is 
really dead.  The test confirms we cannot do an XA end but should probably also 
check the transaction table. If all that checks out I will  check in the change 
as is.

Thanks Mike and Brett for the input.





 Derby threads hanging when using ClientXADataSource and a deadlock or lock 
 timeout occurs
 -

 Key: DERBY-5552
 URL: https://issues.apache.org/jira/browse/DERBY-5552
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.8.1.2
 Environment: Solaris 10, Glassfish V2.1.1,
Reporter: Brett Bergquist
Assignee: Kathey Marsden
Priority: Blocker
  Labels: derby_triage10_9
 Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, 
 ReproDerby5552LockTimeout.java, appserverstack.txt, client.tar.Z, 
 derby-5552_withtest_diff.txt, derby-5552_withtest_diff.txt, derby.log, 
 derbystackatshutdown.txt, execute.patch, transactionsleft.txt


 The issue arrives when multiple XA transactions are done in parallel and 
 there is either a lock timeout or a lock deadlock detected.  When this 
 happens the connection is leaked in the Glassfish connection pool and the 
 client thread hangs in 
 org.apache.derby.client.netReply.fill(Reply.java:172).  
 Shutting down the app server fails because the thread has a lock in 
 org.apache.derby.client.net.NetConnection40 and another task is calling 
 org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214)
  which is waiting for the lock.
 Killing the appsever using kill and then attempting to shutdown Derby 
 network server causes the Network Server to hang.  One of the threads hangs 
 waiting for a lock at 
 org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525)
  and the main thread has this locked at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242)
  and it itself is waiting for a lock which belongs to a thread that is stuck 
 at 
 org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118)
  which is in the TIMED_WAITING state.
 Only by killing the Network Server using kill is possible at this point.
 There are transactions left even though all clients have been removed.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5328) The private fields of the NetServlet can be changed by multiple threads, giving rise to race conditions and corruptions.

2012-02-17 Thread Rick Hillegas (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-5328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210487#comment-13210487
]

Rick Hillegas commented on DERBY-5328:
--

Hi Kathey,

I believe there is more work to be done on this issue. Thanks.

The private fields of the NetServlet can be changed by multiple threads,
giving rise to race conditions and corruptions.

[jira] [Updated] (DERBY-5584) Select statement with subqueries with group by and count distinct statements returns wrong number of results

2012-02-17 Thread Dag H. Wanvik (Issue Comment Edited) (JIRA)


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

Kathey Marsden updated DERBY-5584:
--

   Component/s: (was: Network Server)
SQL
  Issue  fix info: High Value Fix,Patch Available,Repro attached
   Urgency: Urgent
Bug behavior facts: Deviation from standard,Wrong query result  (was: 
Deviation from standard)
Labels: derby_triage10_9  (was: )

Triage for 10.9. Moved component to SQL and checked appropriate boxes.
I wonder. Is this a regression?

 Thanks Bryan for working on this issue.



 Select statement with subqueries with group by and count distinct statements 
 returns wrong number of results
 

 Key: DERBY-5584
 URL: https://issues.apache.org/jira/browse/DERBY-5584
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.7.1.1
 Environment: Output from sysinfo
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.6
 java.runtime.version: 1.6.0_20-b02
 - Derby Information 
 JRE - JDBC: Java SE 6 - JDBC 4.0
 [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derby.jar] 10.7.1.1 - 
 (1040133)
 [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbytools.jar] 10.7.1.1 - 
 (1040133)
 [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbynet.jar] 10.7.1.1 - 
 (1040133)
 [/home/piotrz/Desktop/db-derby-10.7.1.1-bin/lib/derbyclient.jar] 10.7.1.1 - 
 (1040133)
 --
 - Locale Information -
 Current Locale :  [English/United States [en_US]]
 Found support for locale: [cs]
version: 10.7.1.1 - (1040133)
 Found support for locale: [de_DE]
version: 10.7.1.1 - (1040133)
 Found support for locale: [es]
version: 10.7.1.1 - (1040133)
 Found support for locale: [fr]
version: 10.7.1.1 - (1040133)
 Found support for locale: [hu]
version: 10.7.1.1 - (1040133)
 Found support for locale: [it]
version: 10.7.1.1 - (1040133)
 Found support for locale: [ja_JP]
version: 10.7.1.1 - (1040133)
 Found support for locale: [ko_KR]
version: 10.7.1.1 - (1040133)
 Found support for locale: [pl]
version: 10.7.1.1 - (1040133)
 Found support for locale: [pt_BR]
version: 10.7.1.1 - (1040133)
 Found support for locale: [ru]
version: 10.7.1.1 - (1040133)
 Found support for locale: [zh_CN]
version: 10.7.1.1 - (1040133)
 Found support for locale: [zh_TW]
version: 10.7.1.1 - (1040133)
Reporter: Piotr Zgadzaj
Assignee: Bryan Pendleton
  Labels: derby_triage10_9
 Attachments: patch1.txt, query.log, tests.out, tests.sql, try1.txt


 Steps to reproduce:
 1. Create database, connect to database with any JDBC client
 2. create two tables:
 CREATE TABLE TEST_5 (
profile_id INTEGER NOT NULL,
group_ref INTEGER NOT NULL,
matched_count INTEGER NOT NULL
);
CREATE TABLE TEST_6 (
profile_id INTEGER NOT NULL,
group_ref INTEGER NOT NULL,
matched_count INTEGER NOT NULL
);
 3. Insert two records for each table:
 insert into test_5 values (1, 1,1);
 insert into test_5 values (2, 1, 2);
 insert into test_6 values (1, 1,1);
 insert into test_6 values (2, 1, 2);
 4. Run following statement
 SELECT *
 FROM
  (SELECT ps1.group_ref,
COUNT(DISTINCT ps1.matched_count) AS matched_count
  FROM test_5 ps1
  GROUP BY ps1.group_ref,
ps1.profile_id
  ) a,
  (SELECT ps2.group_ref,
COUNT( DISTINCT ps2.matched_count) AS matched_count
  FROM test_6 ps2
  GROUP BY ps2.group_ref,
ps2.profile_id
  ) b
 As a result I've got 3 records instead of 4 - at least Oracle 10g
 returns 4 records for this statement. Maybe i'm doing something wrong.
 Do you have any suggestions / possible workarounds for this problem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-2687) store/encryptDatabase.sql fails intermittently with ClassNotFoundException, Log Corrupted

2012-02-17 Thread Dag H. Wanvik (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210540#comment-13210540
 ] 

Dag H. Wanvik commented on DERBY-2687:
--

I have rewritten encryptDatabase.sql to JUnit and made the test ignore  the 
wrong boot issue. Even though this doesn't solve the wrong password change, 
it's incremental improvement. I'll make a new issue for storing the full digest 
to reduce the collision chance for both issues. 

 store/encryptDatabase.sql fails intermittently with ClassNotFoundException, 
 Log Corrupted
 -

 Key: DERBY-2687
 URL: https://issues.apache.org/jira/browse/DERBY-2687
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.2.2.1, 10.3.1.4
 Environment: Microsoft Windows XP Professional - 5.1.2600 Service 
 Pack 2, Sun JVM 1.4.2_08-b03, 10.2.2.1.
 SUSE Linux Enterprise Server 10 (x86_64) (Linux 2.6.16.21-0.8-smp), Sun JVM 
 1.6.0_01-b06, trunk (SVN 531991).
 Solaris 10 x86, Sun JVM 1.5.0, SVN 371617 (2006-01-23).
 Solaris 9 SPARC, Sun JVM 1.5.0, SVN 169872 (2005-05-13).
 etc...
Reporter: John H. Embretsen
  Labels: derby_triage10_5_2
 Attachments: derby.log, tmp-82.zip, wombat.zip


 Failure seen in derbyall/encryptionAll run on WinXP (10.2.2.1). So far unable 
 to reproduce (standalone or as part of derbyall, encryptionAll or 
 encryptionBlowfish).
 method
 store/encryptDatabase.sql
 /method
 signature
 Failure details:
 * Diff file 
 derbyall/encryptionAll/encryptionBlowfish/encryptDatabase.diff
 *** Start: encryptDatabase jdk1.4.2_08 encryptionAll:encryptionBlowfish 
 2007-05-21 05:07:55 ***
 95 del
  ERROR XBM06: Startup failed. An encrypted database cannot be accessed 
 without the correct boot password.
 95a95
  ERROR XJ001: Java exception: 'ERROR XBM0U: No class was registered for 
  identifier 15009.: java.lang.ClassNotFoundException'.
 Test Failed.
 *** End:   encryptDatabase jdk1.4.2_08 encryptionAll:encryptionBlowfish 
 2007-05-21 05:08:12 ***
 /signature
 derby.log also reports ERROR XSLA3: Log Corrupted, has invalid data in the 
 log stream.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-866) Derby User Management Enhancements

2012-02-17 Thread Rick Hillegas (Updated) (JIRA)


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

Rick Hillegas updated DERBY-866:


Attachment: derby-866-18-aa-encryptedCredentialsDB.diff

Attaching derby-866-18-aa-encryptedCredentialsDB. This patch adds tests for 
encrypted credentials databases. I need to run full regression tests.

I have successfully run NativeAuthenticationServiceTest on the following 
platforms:

1) Java 6 on Mac OSX
2) Java 6 on XP
3) Java 5 on XP
4) OJEC 

Touches the following files:

-

M   java/testing/org/apache/derbyTesting/junit/DriverManagerConnector.java
M   java/testing/org/apache/derbyTesting/junit/DataSourceConnector.java
M   java/testing/org/apache/derbyTesting/junit/TestConfiguration.java
M   java/testing/org/apache/derbyTesting/junit/XADataSourceConnector.java
M   
java/testing/org/apache/derbyTesting/junit/ConnectionPoolDataSourceConnector.java
M   java/testing/org/apache/derbyTesting/junit/Connector.java

Added ability to create a test connection with arbitrary properties.

-

M   
java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java
M   
java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast_init.sql
M   java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast1.jar

New test for encrypted credentials databases.


 Derby User Management Enhancements
 --

 Key: DERBY-866
 URL: https://issues.apache.org/jira/browse/DERBY-866
 Project: Derby
  Issue Type: Improvement
  Components: Services
Affects Versions: 10.2.1.6
Reporter: Francois Orsini
Assignee: Rick Hillegas
 Attachments: Derby_User_Enhancement.html, 
 Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, 
 UserManagement.html, UserManagement.html, UserManagement.html, 
 UserManagement.html, UserManagement.html, UserManagement.html, 
 derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, 
 derby-866-02-ag-createDropUser.diff, 
 derby-866-03-aa-resetModifyPassword.diff, 
 derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, 
 derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, 
 derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, 
 derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, 
 derby-866-09-ad-nativeAuthenticationService.diff, 
 derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, 
 derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, 
 derby-866-12-ac-passwordExpiration.diff, 
 derby-866-13-ab-systemWideOperationTests.diff, 
 derby-866-14-ac-badNativeSpec.diff, 
 derby-866-15-ae-dbInJarFileOrOnClasspath.diff, 
 derby-866-16-aa-credDBViaSubprotocol.diff, 
 derby-866-17-aa-grantRevokeNative.diff, 
 derby-866-18-aa-encryptedCredentialsDB.diff, dummyCredentials.properties


 Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec 
 attached to the JIRA).
 Abstract:
 This feature aims at improving the way BUILT-IN users are managed in Derby by 
 providing a more intuitive and familiar DDL interface. Currently (in 
 10.1.2.1), Built-In users can be defined at the system and/or database level. 
 Users created at the system level can be defined via JVM or/and Derby system 
 properties in the derby.properties file. Built-in users created at the 
 database level are defined via a call to a Derby system procedure 
 (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
 Defining a user at the system level is very convenient and practical during 
 the development phase (EOD) of an application - However, the user's password 
 is not encrypted and consequently appears in clear in the derby.properties 
 file. Hence, for an application going into production, whether it is embedded 
 or not, it is preferable to create users at the database level where the 
 password is encrypted.
 There is no real ANSI SQL standard for managing users in SQL but by providing 
 a more intuitive and known interface, it will ease Built-In User management 
 at the database level as well as Derby's adoption.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.

2012-02-17 Thread Dag H. Wanvik (Created) (JIRA)

Reduce the chance for hash collisions when checking bootPassword at boot time 
and when changing password.
-

 Key: DERBY-5622
 URL: https://issues.apache.org/jira/browse/DERBY-5622
 Project: Derby
  Issue Type: Improvement
  Components: Store
Reporter: Dag H. Wanvik


There are two issues, already seen in DERBY-2687:

   the boot issue: there is a 1/2**16 chance that a wrong bootpassword will 
allow boot to proceed (but since its decoded key is wrong the boot will fail).
   the oassword change issue: similarly, there is a chance that the wrong 
bootpassword will be accepted trying to change it via 
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('bootPassword', ...) at least for 
algorithms that do not check IV (initialization vector) in addition to the
digest, e.g. DES/ECB/NoPadding

The latter case may lead to data corruption, cf. DERBY-2687 discussion. I think 
the risk is fairly low, though: One would need to have execution permission to 
change the property if SQL authorization is used, and in most scenarios the 
supplied existing password would be correct. But since the results can be bad, 
it would be good to reduce or eliminate the risk.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (DERBY-2687) store/encryptDatabase.sql fails intermittently with ClassNotFoundException, Log Corrupted

[
https://issues.apache.org/jira/browse/DERBY-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210540#comment-13210540
]

Dag H. Wanvik edited comment on DERBY-2687 at 2/17/12 9:06 PM:
---

I have rewritten encryptDatabase.sql to JUnit and made the test ignore the
wrong boot issue. Even though this doesn't solve the wrong password change,
it's incremental improvement. I'll make a new issue for storing the full digest
to reduce the collision chance for both issues. [Update: DERBY-5622].

was (Author: dagw):
I have rewritten encryptDatabase.sql to JUnit and made the test ignore the
wrong boot issue. Even though this doesn't solve the wrong password change,
it's incremental improvement. I'll make a new issue for storing the full digest
to reduce the collision chance for both issues.

store/encryptDatabase.sql fails intermittently with ClassNotFoundException,
Log Corrupted
-

Key: DERBY-2687
URL: https://issues.apache.org/jira/browse/DERBY-2687
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.2.2.1, 10.3.1.4
Environment: Microsoft Windows XP Professional - 5.1.2600 Service
Pack 2, Sun JVM 1.4.2_08-b03, 10.2.2.1.
SUSE Linux Enterprise Server 10 (x86_64) (Linux 2.6.16.21-0.8-smp), Sun JVM
1.6.0_01-b06, trunk (SVN 531991).
Solaris 10 x86, Sun JVM 1.5.0, SVN 371617 (2006-01-23).
Solaris 9 SPARC, Sun JVM 1.5.0, SVN 169872 (2005-05-13).
etc...
Reporter: John H. Embretsen
Labels: derby_triage10_5_2
Attachments: derby.log, tmp-82.zip, wombat.zip

Failure seen in derbyall/encryptionAll run on WinXP (10.2.2.1). So far unable
to reproduce (standalone or as part of derbyall, encryptionAll or
encryptionBlowfish).
method
store/encryptDatabase.sql
/method
signature
Failure details:
* Diff file
derbyall/encryptionAll/encryptionBlowfish/encryptDatabase.diff
*** Start: encryptDatabase jdk1.4.2_08 encryptionAll:encryptionBlowfish
2007-05-21 05:07:55 ***
95 del
ERROR XBM06: Startup failed. An encrypted database cannot be accessed
without the correct boot password.
95a95
ERROR XJ001: Java exception: 'ERROR XBM0U: No class was registered for
identifier 15009.: java.lang.ClassNotFoundException'.
Test Failed.
*** End: encryptDatabase jdk1.4.2_08 encryptionAll:encryptionBlowfish
2007-05-21 05:08:12 ***
/signature
derby.log also reports ERROR XSLA3: Log Corrupted, has invalid data in the
log stream.

[jira] [Updated] (DERBY-5622) Reduce the chance for hash collisions when checking bootPassword at boot time and when changing password.

2012-02-17 Thread Dag H. Wanvik (Updated) (JIRA)

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

Dag H. Wanvik updated DERBY-5622:
-

Description:
There are two issues, already seen in DERBY-2687:

the boot issue: there is a 1/2**16 chance that a wrong bootPassword will
allow boot to proceed (but since its decoded key is wrong the boot will fail).
the password change issue: similarly, there is a chance that the wrong
bootPassword will be accepted trying to change it via
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('bootPassword', ...) at least for
algorithms that do not check IV (initialization vector) in addition to the
digest, e.g. DES/ECB/NoPadding

The latter case may lead to data corruption, cf. DERBY-2687 discussion. I think
the risk is fairly low, though: One would need to have execution permission to
change the property if SQL authorization is used, and in most scenarios the
supplied existing password would be correct. But since the results can be bad,
it would be good to reduce or eliminate the risk.

was:
There are two issues, already seen in DERBY-2687:

the boot issue: there is a 1/2**16 chance that a wrong bootpassword will
allow boot to proceed (but since its decoded key is wrong the boot will fail).
the oassword change issue: similarly, there is a chance that the wrong
bootpassword will be accepted trying to change it via
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('bootPassword', ...) at least for
algorithms that do not check IV (initialization vector) in addition to the
digest, e.g. DES/ECB/NoPadding

Reduce the chance for hash collisions when checking bootPassword at boot time
and when changing password.
-

Key: DERBY-5622
URL: https://issues.apache.org/jira/browse/DERBY-5622
Project: Derby
Issue Type: Improvement
Components: Store
Reporter: Dag H. Wanvik

There are two issues, already seen in DERBY-2687:
the boot issue: there is a 1/2**16 chance that a wrong bootPassword will
allow boot to proceed (but since its decoded key is wrong the boot will fail).
the password change issue: similarly, there is a chance that the wrong
bootPassword will be accepted trying to change it via
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('bootPassword', ...) at least for
algorithms that do not check IV (initialization vector) in addition to the
digest, e.g. DES/ECB/NoPadding
The latter case may lead to data corruption, cf. DERBY-2687 discussion. I
think the risk is fairly low, though: One would need to have execution
permission to change the property if SQL authorization is used, and in most
scenarios the supplied existing password would be correct. But since the
results can be bad, it would be good to reduce or eliminate the risk.

[jira] [Updated] (DERBY-5319) Multiline log message on database boot is always written with UNIX newlines


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

Mike Matrigali updated DERBY-5319:
--

Issue  fix info: Newcomer
 Urgency: Low
  Labels: derby_triage10_9  (was: )

Triage for 10.9. 

 Multiline log message on database boot is always written with UNIX newlines
 ---

 Key: DERBY-5319
 URL: https://issues.apache.org/jira/browse/DERBY-5319
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.9.0.0
Reporter: Kristian Waagan
Priority: Trivial
  Labels: derby_triage10_9

 On Windows the log file will contain both native newlines and UNIX newlines. 
 This  may or may not be a problem, depending on the tools being used to read 
 derby.log.
 The message has id D001.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5358) SYSCS_COMPRESS_TABLE failed with conglomerate not found exception


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

Mike Matrigali updated DERBY-5358:
--

Urgency: Normal

 SYSCS_COMPRESS_TABLE failed with conglomerate not found exception
 -

 Key: DERBY-5358
 URL: https://issues.apache.org/jira/browse/DERBY-5358
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen

 When running the D4275.java repro attached to DERBY-4275 (with the patch 
 invalidate-during-invalidation.diff as well as the fix for DERBY-5161 to 
 prevent the select thread from failing) in four parallel processes on the 
 same machine, one of the processes failed with the following stack trace:
 java.sql.SQLException: The exception 'java.sql.SQLException: The conglomerate 
 (4,294,967,295) requested does not exist.' was thrown while evaluating an 
 expression.
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98)
 at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
 at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:407)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348)
 at 
 org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2290)
 at 
 org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
 at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1341)
 at D4275.main(D4275.java:52)
 Caused by: java.sql.SQLException: The exception 'java.sql.SQLException: The 
 conglomerate (4,294,967,295) requested does not exist.' was thrown while 
 evaluating an expression.
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
 ... 10 more
 Caused by: java.sql.SQLException: The conglomerate (4,294,967,295) requested 
 does not exist.
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
 at 
 org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:400)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348)
 at 
 org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2290)
 at 
 org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
 at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:308)
 at 
 org.apache.derby.catalog.SystemProcedures.SYSCS_COMPRESS_TABLE(SystemProcedures.java:792)
 at 
 org.apache.derby.exe.acd381409ax0131x72b6x8e11x037164a81.g0(Unknown 
 Source)
 at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46)
 at 
 org.apache.derby.impl.sql.execute.CallStatementResultSet.open(CallStatementResultSet.java:75)
 at 
 org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:448)
 at 
 org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:319)
 at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
 ... 3 more
 Caused by: ERROR XSAI2: The conglomerate (4,294,967,295)

[jira] [Updated] (DERBY-5358) SYSCS_COMPRESS_TABLE failed with conglomerate not found exception


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

Mike Matrigali updated DERBY-5358:
--

Labels: derby_triage10_9  (was: )

Triage for 10.9.   leaving normal urgency unless it found that the issue leaves 
db corrupted in some way.  The message has the
feel of a temporary timing issue.

 SYSCS_COMPRESS_TABLE failed with conglomerate not found exception
 -

 Key: DERBY-5358
 URL: https://issues.apache.org/jira/browse/DERBY-5358
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
  Labels: derby_triage10_9

 When running the D4275.java repro attached to DERBY-4275 (with the patch 
 invalidate-during-invalidation.diff as well as the fix for DERBY-5161 to 
 prevent the select thread from failing) in four parallel processes on the 
 same machine, one of the processes failed with the following stack trace:
 java.sql.SQLException: The exception 'java.sql.SQLException: The conglomerate 
 (4,294,967,295) requested does not exist.' was thrown while evaluating an 
 expression.
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98)
 at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
 at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:407)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348)
 at 
 org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2290)
 at 
 org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
 at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1341)
 at D4275.main(D4275.java:52)
 Caused by: java.sql.SQLException: The exception 'java.sql.SQLException: The 
 conglomerate (4,294,967,295) requested does not exist.' was thrown while 
 evaluating an expression.
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
 ... 10 more
 Caused by: java.sql.SQLException: The conglomerate (4,294,967,295) requested 
 does not exist.
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
 at 
 org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:400)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348)
 at 
 org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2290)
 at 
 org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
 at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:308)
 at 
 org.apache.derby.catalog.SystemProcedures.SYSCS_COMPRESS_TABLE(SystemProcedures.java:792)
 at 
 org.apache.derby.exe.acd381409ax0131x72b6x8e11x037164a81.g0(Unknown 
 Source)
 at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46)
 at 
 org.apache.derby.impl.sql.execute.CallStatementResultSet.open(CallStatementResultSet.java:75)
 at 
 org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:448)
 at

[jira] [Updated] (DERBY-5377) AssertionFailedError in testCaseCS4595B_NonUniqueIndex in AccessTest


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

Mike Matrigali updated DERBY-5377:
--

Issue  fix info: High Value Fix
 Urgency: Urgent
  Labels: derby_triage10_9  (was: )

Triage for 10.9.   Would be nice to get a fix for this as it is causing pretty 
regular nightly failures in 10.8.  
I have run test on 10.8 nightly test machine where failures are seen often, and 
have not been able to reproduce.
Tried running just the test java file 100 times under load and under no load 
and no repro.  


 AssertionFailedError in testCaseCS4595B_NonUniqueIndex in AccessTest
 

 Key: DERBY-5377
 URL: https://issues.apache.org/jira/browse/DERBY-5377
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.8.2.3, 10.9.0.0
 Environment: Vista, Java 1.5, trunk
Reporter: Dag H. Wanvik
  Labels: derby_triage10_9
 Attachments: d5377-dump-stats.diff


 There was 1 failure:
 1) 
 testCaseCS4595B_NonUniqueIndex(org.apache.derbyTesting.functionTests.tests.store.AccessTest)junit.framework.AssertionFailedError
   at 
 org.apache.derbyTesting.functionTests.tests.store.AccessTest.assertStatsOK(AccessTest.java:402)
   at 
 org.apache.derbyTesting.functionTests.tests.store.AccessTest.doTestCaseCS4595B(AccessTest.java:1720)
   at 
 org.apache.derbyTesting.functionTests.tests.store.AccessTest.testCaseCS4595B_NonUniqueIndex(AccessTest.java:1830)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
 Cf. 
 http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-1154534.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5416) SYSCS_COMPRESS_TABLE causes an OutOfMemoryError when the heap is full at call time and then gets mostly garbage collected later on


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

Mike Matrigali updated DERBY-5416:
--

Urgency: Normal

Any suggestions on a better way to determine if sort should use more in-memory. 
 It seems for performance derby should be 
using more memory for these operations automatically, but as this issue points 
out operations can fail if the choice is wrong.
Solutions should be zero-admin by default, with maybe tuning knobs to work 
around issues like this one where the default does
not work.  

 SYSCS_COMPRESS_TABLE causes an OutOfMemoryError when the heap is full at call 
 time and then gets mostly garbage collected later on
 --

 Key: DERBY-5416
 URL: https://issues.apache.org/jira/browse/DERBY-5416
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.6.2.1, 10.7.1.1, 10.8.1.2
Reporter: Ramin Baradari
Priority: Critical
  Labels: derby_triage10_9
 Attachments: compress_test_5416.patch


 When compressing a table with an index that is larger than the maximum heap 
 size and therefore cannot be hold in memory as a whole an OutOfMemoryError 
 can occur. 
 For this to happen the heap usage must be close to the maximum heap size at 
 the start of the index recreation and then while the entries are sorted a 
 garbage collection run must clean out most of the heap. This can happen 
 because a concurrent process releases a huge chunk of memory or just because 
 the buffer of a previous table compression has not yet been garbage 
 collected. 
 The internally used heuristics to guess when more memory can be used for the 
 merge inserter estimates that more memory is available and then the sort 
 buffer gets doubled. The buffer size gets doubled until the heap usage is 
 back to the level when the merge inserter was first initialized or when the 
 OOM occurs.
 The problem lies in MergeInsert.insert(...). The check if the buffer can be 
 doubled contains the expression estimatedMemoryUsed  0 where 
 estimatedMemoryUsed is the difference in current heap usage and heap usage at 
 initialization. Unfortunately, in the aforementioned scenario this will be 
 true until the heap usage will reach close to maximum heap size before 
 doubling the buffer size will be stopped.
 I've tested it with 10.6.2.1, 10.7.1.1 and 10.8.1.2 but the actual bug most 
 likely exists in prior versions too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5450) in nstest: XSLA6: Cannot recover from database and 40XT4 errors in nstest (sane jars) after ASSERT FAILED org.apache.derby.shared.common.sanity.AssertFailure: ASSERT


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

Mike Matrigali updated DERBY-5450:
--

  Issue  fix info: High Value Fix
   Urgency: Urgent
Bug behavior facts: Crash,Data corruption
Labels: derby_triage10_9  (was: )

10.9 bug triage.  Without a reproducible case this is going to be hard to fix, 
but would be worth looking through the data and log for clues.  
There is at least one known issue that looks similar that I will link to the 
issue.

 in nstest: XSLA6: Cannot recover from database  and 40XT4 errors in nstest 
 (sane jars) after ASSERT FAILED   
 org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED  
 inconsistency in space management during insert
 -

 Key: DERBY-5450
 URL: https://issues.apache.org/jira/browse/DERBY-5450
 Project: Derby
  Issue Type: Bug
  Components: Store, Test
Affects Versions: 10.8.2.2
 Environment: SUSE Linux 10, ibm 1.6 SR9 FP1. 2 CPU machine, but 
 hyperthreading on
Reporter: Myrna van Lunteren
  Labels: derby_triage10_9
 Attachments: d5450_derbylog.jar


 With the 10.8 (10.8.2.2) tree sync-ed up to revision: 1179754, I ran NsTest 
 Embedded with sane jars, but no derby.properties file.
 I saw the following AssertFailure:
 org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED  
 inconsistency in space management during insert:  slot = 146 
 getSlotOffset(slot) = 3206 dataWritten = 19 freeSpace = -15 firstFreeByte = 
 3149 page = ---
 page id: Page(378,Container(0, 1153)) Overflow: false PageVersion: 895 
 SlotsInUse: 159 DeletedRowCount: 93 PageStatus: 1 NextId: 317 firstFreeByte: 
 3149 freeSpace: -15 totalSpace: 4028 spareSpace: 0% minimumRecordSize : 1 
 PageSize: 4096
 This was followed by:
   BEGIN SHUTDOWN ERROR STACK -
 ERROR XSLA6: Cannot recover the database.
 and somewhat later: 
 ERROR 40XT4: An attempt was made to close a transaction that was still 
 active. The transaction has been aborted.
 But after a while we get back to the errors always seen with this test (ERROR 
 22003 and XBM06).
 I will attach the derby.log, in case someone likes to look at puzzling 
 behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5600) ) testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError: Failo


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

Kathey Marsden updated DERBY-5600:
--

Component/s: Replication
 Labels: derby_triage10_9  (was: )

 ) 
 testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError:
  Failover did not succeed at 
 org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase.
 ---

 Key: DERBY-5600
 URL: https://issues.apache.org/jira/browse/DERBY-5600
 Project: Derby
  Issue Type: Bug
  Components: Network Server, Replication
Affects Versions: 10.8.2.3
 Environment: Linux vmware 
Reporter: Kathey Marsden
  Labels: derby_triage10_9

 Saw this on Feb 1 run 10.8.2.3.129442 Linux vmware
 testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError:
  Failover did not succeed
   at 
 org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase.java:813)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:359)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing.testReplication_Local_1_Indexing(ReplicationRun_Local_1Indexing.java:102)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled
  Code))
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled
  Code))
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled
  Code))
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java(Compiled 
 Code))
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.runBare(ReplicationRun.java:222)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java(Inlined 
 Compiled Code))
   at junit.extensions.TestSetup$1.protect(TestSetup.java(Inlined Compiled 
 Code))
   at junit.extensions.TestSetup.run(TestSetup.java(Compiled Code))
 Caused by: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 
 08004, SQLERRMC: Connection refused to database 
 '/local1/cloudtst/dev/src/NightlyBuildResults.2012-02-01/ibm142_suites.All/db_slave/wombat'
  because it is in replication slave mode.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
   at java.sql.DriverManager.getConnection(DriverManager.java(Compiled 
 Code))
   at java.sql.DriverManager.getConnection(DriverManager.java(Compiled 
 Code))
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:338)
   ... 31 more
 Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: 
 -1, SQLSTATE: 08004, SQLERRMC: Connection refused to database 
 '/local1/cloudtst/dev/src/NightlyBuildResults.2012-02-01/ibm142_suites.All/db_slave/wombat'
  because it is in replication slave mode.
   at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source)
   at 
 org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown
  Source)
   at 
 org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown
  Source)
   at 
 org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.init(Unknown Source)
   at org.apache.derby.client.net.Cl

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5534) ResultSet#updateFloat, #updateDouble do not check for NaN and other conditions on client

2012-02-17 Thread Dag H. Wanvik (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210700#comment-13210700
]

Dag H. Wanvik commented on DERBY-5534:
--

Hi Kathey, cf this quote from the description The server will balk when the
row is updated, though, in ResultSet#updateRow. It will be more regular if this
is caught in updateXXX, i.e. we get an error, but later/in another method call
than on embedded. In the test we only do updateXXX, so no exception.

ResultSet#updateFloat, #updateDouble do not check for NaN and other
conditions on client

Key: DERBY-5534
URL: https://issues.apache.org/jira/browse/DERBY-5534
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client
Affects Versions: 10.8.2.2
Reporter: Dag H. Wanvik
Priority: Minor
Labels: derby_triage10_9

In updateXXX, where XXX is one of Float or Double, embedded throws value out
of range when the argument is Float.NaN or Double.NaN, the client does not
catch it.
The server will balk when the row is updated, though, in ResultSet#updateRow.
It will be more regular if this is caught in updateXXX also on the client as
other range errors are. The SQL state seen is 22003, which is what embedded
throws on updateXXX. See also DERBY-5533.

[jira] [Updated] (DERBY-5600) ) testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError: Failo


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

Kathey Marsden updated DERBY-5600:
--

Urgency: Normal

 ) 
 testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError:
  Failover did not succeed at 
 org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase.
 ---

 Key: DERBY-5600
 URL: https://issues.apache.org/jira/browse/DERBY-5600
 Project: Derby
  Issue Type: Bug
  Components: Network Server, Replication
Affects Versions: 10.8.2.3
 Environment: Linux vmware 
Reporter: Kathey Marsden
  Labels: derby_triage10_9

 Saw this on Feb 1 run 10.8.2.3.129442 Linux vmware
 testReplication_Local_1_Indexing(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError:
  Failover did not succeed
   at 
 org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase.java:813)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:359)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing.testReplication_Local_1_Indexing(ReplicationRun_Local_1Indexing.java:102)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled
  Code))
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled
  Code))
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled
  Code))
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java(Compiled 
 Code))
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.runBare(ReplicationRun.java:222)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java(Inlined 
 Compiled Code))
   at junit.extensions.TestSetup$1.protect(TestSetup.java(Inlined Compiled 
 Code))
   at junit.extensions.TestSetup.run(TestSetup.java(Compiled Code))
 Caused by: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 
 08004, SQLERRMC: Connection refused to database 
 '/local1/cloudtst/dev/src/NightlyBuildResults.2012-02-01/ibm142_suites.All/db_slave/wombat'
  because it is in replication slave mode.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
   at java.sql.DriverManager.getConnection(DriverManager.java(Compiled 
 Code))
   at java.sql.DriverManager.getConnection(DriverManager.java(Compiled 
 Code))
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:338)
   ... 31 more
 Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: 
 -1, SQLSTATE: 08004, SQLERRMC: Connection refused to database 
 '/local1/cloudtst/dev/src/NightlyBuildResults.2012-02-01/ibm142_suites.All/db_slave/wombat'
  because it is in replication slave mode.
   at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source)
   at 
 org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown
  Source)
   at 
 org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown
  Source)
   at 
 org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.init(Unknown Source)
   at org.apache.derby.client.net.Cl

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5610) ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes


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

Kathey Marsden updated DERBY-5610:
--

Urgency: Normal
 Labels: derby_triage10_9  (was: )

Triage for 10.9

 ServerPropertiesTest prints .java.net.SocketException: Connection reset to 
 console but test passes
 --

 Key: DERBY-5610
 URL: https://issues.apache.org/jira/browse/DERBY-5610
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.8.2.3
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Priority: Minor
  Labels: derby_triage10_9
 Attachments: derby-5610_diff.txt


 ServerPropertiesTest showed the below output when running. The ping retries 
 and the test passes. 
 I am not sure if in fact a Connection reset is a valid response if the server 
 is not fully up and the test is just being too verbose or if it is real 
 problem that we get this Error.
 .java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.net.SocketInputStream.read(SocketInputStream.java:90)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown 
 Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown 
 Source)
   at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown 
 Source)
   at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source)
   at 
 org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.shutdownServer(ServerPropertiesTest.java:309)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:484)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:600)
   at junit.framework.TestCase.runTest(TestCase.java:154)
   at junit.framework.TestCase.runBare(TestCase.java:127)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:118)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at junit.framework.TestSuite.runTest(TestSuite.java:208)
   at junit.framework.TestSuite.run(TestSuite.java:203)
   at junit.framework.TestSuite.runTest(TestSuite.java:208)
   at junit.framework.TestSuite.run(TestSuite.java:203)
   at junit.textui.TestRunner.doRun(TestRunner.java:116)
   at junit.textui.TestRunner.start(TestRunner.java:172)
   at junit.textui.TestRunner.main(TestRunner.java:138)
 java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.net.SocketInputStream.read(SocketInputStream.java:90)
   at

[jira] [Commented] (DERBY-5611) Permissions granted by server.policy to derbytools.jar are not sufficient to run ij

2012-02-17 Thread Kathey Marsden (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210713#comment-13210713
 ] 

Kathey Marsden commented on DERBY-5611:
---

I agree the tools permissions are there for the benefit of NetworkServerControl 
sysinfo.
Should this be closed Not a Problem?


 Permissions granted by server.policy to derbytools.jar are not sufficient to 
 run ij
 ---

 Key: DERBY-5611
 URL: https://issues.apache.org/jira/browse/DERBY-5611
 Project: Derby
  Issue Type: Bug
  Components: Network Server, Tools
Affects Versions: 10.9.0.0
Reporter: Rick Hillegas
Priority: Minor

 server.policy grants derbytools.jar the permission to read several system 
 properties.  However, at startup ij tries to read all of the system 
 properties. This happens in ij.jj in the initFromEnvironment() method. To 
 call System.getProperties(), you need the following permission:
   permission java.util.PropertyPermission *, read,write;
 ij startup fails with this error trace:
 Exception in thread main java.security.AccessControlException: access 
 denied (java.util.PropertyPermission * read,write)
   at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
   at 
 java.security.AccessController.checkPermission(AccessController.java:546)
   at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
   at 
 java.lang.SecurityManager.checkPropertiesAccess(SecurityManager.java:1252)
   at java.lang.System.getProperties(System.java:581)
   at org.apache.derby.impl.tools.ij.ij$1.run(ij.java:113)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.apache.derby.impl.tools.ij.ij.initFromEnvironment(ij.java:111)
   at 
 org.apache.derby.impl.tools.ij.utilMain.initFromEnvironment(utilMain.java:175)
   at org.apache.derby.impl.tools.ij.Main.init(Main.java:244)
   at org.apache.derby.impl.tools.ij.Main.getMain(Main.java:196)
   at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
   at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
   at org.apache.derby.tools.ij.main(ij.java:59)
 Here are some ways to fix this problem:
 1) Remove the whole block of permissions for derbytools.jar. Maybe those 
 permissions don't belong in server.policy. Note that a similar block of 
 permissions also appears in template.policy with a comment suggesting that 
 they are sufficient for running the Derby tools.
 2) Add to the derbytools block the missing permission.
 3) Re-write initFromEnvironment() so that it reads only a few properties 
 rather than all properties.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5621) Failure in SecureServerTest )junit.framework.AssertionFailedError: Failed ping after changing trace directory: