[jira] [Commented] (DERBY-5359) Missing xmlns attribute for html element in docs
[ https://issues.apache.org/jira/browse/DERBY-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094465#comment-13094465 ] Knut Anders Hatlen commented on DERBY-5359: --- Thanks for the patch, Jayaram! I applied the patch and built the reference manual. It looks like the xmlns attribute is correctly inserted into the html element. However, there's also an xmlns attribute inserted into some elements where it doesn't belong. For example, in the toc.html file you attached, we have this: body ul lia xmlns= href=rrefcopyright.html//li lia xmlns= href=rreflicense.html//li lia xmlns= href=crefmpref1002477.html/ ul The html validator now complains that there shouldn't be an xmlns attribute in the a element. I don't see exactly this when I build it in my environment, but I do see xmlns attributes inserted into meta and ul elements: meta xmlns= content=text/html; charset=utf-8 http-equiv=Content-Type / ... body ul xmlns= ... Similar things seem to happen in the html files for the topics. For example in rrefclob.html: html xmlns=http://www.w3.org/1999/xhtml; lang=en-us xml:lang=en-us head xmlns= ... body xmlns= id=rrefcloba name=rrefclob!-- --/a ... When I read the comments on DERBY-4408 again, I see that Kim experienced similar problem. See https://issues.apache.org/jira/browse/DERBY-4408?focusedCommentId=13069007page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13069007. I'm not sure what we'll have to do to get around that problem. Missing xmlns attribute for html element in docs Key: DERBY-5359 URL: https://issues.apache.org/jira/browse/DERBY-5359 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Jayaram Subramanian Attachments: derby5359.diff, html.zip The html files in the documentation that are declared as XHTML don't pass as valid XHTML because the html elements lack the xmlns attribute. Examples: http://db.apache.org/derby/docs/dev/ref/index.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Findex.html http://db.apache.org/derby/docs/dev/ref/toc.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Ftoc.html http://db.apache.org/derby/docs/dev/ref/rrefcallprocedure.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Frrefcallprocedure.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5359) Missing xmlns attribute for html element in docs
[ https://issues.apache.org/jira/browse/DERBY-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5359: -- Issue fix info: (was: [Patch Available]) The changes in lib/index.html look fine, so I committed that part of the patch (revision 1163601, backported to 10.8 with revison 1163602). Missing xmlns attribute for html element in docs Key: DERBY-5359 URL: https://issues.apache.org/jira/browse/DERBY-5359 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Jayaram Subramanian Attachments: derby5359.diff, html.zip The html files in the documentation that are declared as XHTML don't pass as valid XHTML because the html elements lack the xmlns attribute. Examples: http://db.apache.org/derby/docs/dev/ref/index.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Findex.html http://db.apache.org/derby/docs/dev/ref/toc.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Ftoc.html http://db.apache.org/derby/docs/dev/ref/rrefcallprocedure.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Frrefcallprocedure.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5283) Crash / process termination during SYSCS_DISABLE_LOG_ARCHIVE_MODE can leave service.properties broken
[ https://issues.apache.org/jira/browse/DERBY-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094507#comment-13094507 ] Kristian Waagan commented on DERBY-5283: I think we can improve the situation here, and I have written a prototype patch that fixes this. However, before moving on to the code, I have a few questions. Is it safe to assume that we can always undo the change to the properties file? Undo would be to continue using the old properties file, and redo would be to start using the new properties file. I understand that some, if not most, of the properties are only set at database creation time. There are two types of error conditions: a) The VM is killed while updating the service properties. b) Updating the service properties is aborted due to a problem (most likely file privileges problem) - the VM stays up In (a) recovery must happen on the next boot, whereas for (b) actions must be taken to correct the situation immediately. Both of these cases would involve a set of file operations; verifying, deleting, or renaming a file. As a further improvement, I would suggest that we print an entry to derby.log when Derby automatically recovers from a problem with the service.properties file. When it comes to the content of the files on disk, are the following assumptions valid? 1) Writing to streams from Java may produce incomplete files. 2) Low level file operations invoked from Java, like delete and rename, will always result in valid files on disk. Note that this does not imply that rename(old,new) is atomic, but, assuming new didn't already exist, new will be a complete copy of old if it exists after the crash. I started out with a rather complex solution for this (using checksums), but I think I'll take the time to simplify it - we can add to it if required. Crash / process termination during SYSCS_DISABLE_LOG_ARCHIVE_MODE can leave service.properties broken - Key: DERBY-5283 URL: https://issues.apache.org/jira/browse/DERBY-5283 Project: Derby Issue Type: Bug Components: Miscellaneous Affects Versions: 10.6.1.0, 10.8.1.2 Environment: sysinfo -- Java Information -- Java Version:1.6.0_26 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files (x86)\Java\jre6 Java classpath: .;C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derby.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbynet.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbyclient.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbytools.jar OS name: Windows 7 OS architecture: x86 OS version: 6.1 Java user name: bmason Java user home: C:\Users\BMASON Java user dir: C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin java.specification.name: Java Platform API Specification java.specification.version: 1.6 java.runtime.version: 1.6.0_26-b03 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derby.jar] 10.6.1.0 - (938214) [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbytools.jar] 10.6.1.0 - (938214) [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbynet.jar] 10.6.1.0 - (938214) [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbyclient.jar] 10.6.1.0 - (938214) -- - Locale Information - Current Locale : [English/New Zealand [en_NZ]] Found support for locale: [cs] version: 10.6.1.0 - (938214) Found support for locale: [de_DE] version: 10.6.1.0 - (938214) Found support for locale: [es] version: 10.6.1.0 - (938214) Found support for locale: [fr] version: 10.6.1.0 - (938214) Found support for locale: [hu] version: 10.6.1.0 - (938214) Found support for locale: [it] version: 10.6.1.0 - (938214) Found support for locale: [ja_JP] version: 10.6.1.0 - (938214) Found support for locale: [ko_KR] version: 10.6.1.0 - (938214) Found support for locale: [pl] version: 10.6.1.0 - (938214) Found support for locale: [pt_BR] version: 10.6.1.0 - (938214) Found support for locale: [ru] version: 10.6.1.0 - (938214) Found support for locale: [zh_CN] version: 10.6.1.0 - (938214) Found support for locale: [zh_TW] version: 10.6.1.0 - (938214) -- Reporter: Brett Mason If Derby is terminated while SYSCS_DISABLE_LOG_ARCHIVE_MODE is being called
[jira] [Commented] (DERBY-5359) Missing xmlns attribute for html element in docs
[ https://issues.apache.org/jira/browse/DERBY-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094511#comment-13094511 ] Knut Anders Hatlen commented on DERBY-5359: --- I found a good explanation here: http://www.xmlplease.com/xhtmlxhtml Following those steps and adding both an xmlns and an xmlns:xhtml attribute to the xsl:stylesheet element made the xmlns attribute appear at the right place (and only there) in the generated documents. However, I had to do that both in the xsl files in the lib directory and in all the xsl files under DITA-OT1.1.2.1/xsl/xslhtml. So it looks like we'd either need to check in modified versions of more xsl files, or add a rewrite rule in the build script to modify the toolkit at build-time. Unless someone knows a better way to do the html generation, of course. Missing xmlns attribute for html element in docs Key: DERBY-5359 URL: https://issues.apache.org/jira/browse/DERBY-5359 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Jayaram Subramanian Attachments: derby5359.diff, html.zip The html files in the documentation that are declared as XHTML don't pass as valid XHTML because the html elements lack the xmlns attribute. Examples: http://db.apache.org/derby/docs/dev/ref/index.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Findex.html http://db.apache.org/derby/docs/dev/ref/toc.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Ftoc.html http://db.apache.org/derby/docs/dev/ref/rrefcallprocedure.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Frrefcallprocedure.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-5396) DRDAStatement and DRDAConnThread swallow IOExceptions
[
https://issues.apache.org/jira/browse/DERBY-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen resolved DERBY-5396.
---
Resolution: Fixed
Fix Version/s: 10.9.0.0
Thanks, Kathey, the DRDAConnThread part of this issue is the same as
DERBY-4350. I'll resolve that issue.
All the regression tests passed. Committed revision 1163616.
DRDAStatement and DRDAConnThread swallow IOExceptions
-
Key: DERBY-5396
URL: https://issues.apache.org/jira/browse/DERBY-5396
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.8.1.2
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Fix For: 10.9.0.0
Attachments: d5396.diff
DRDAConnThread.closeStream():
} catch (IOException e) {
Util.javaException(e);
}
DRDAStatement.execute():
} catch (IOException e) {
Util.javaException(e);
}
Since Util.javaException() only returns an exception, this code doesn't work
as intended. The returned exception should also be thrown.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-4350) javaException is created but not thrown or logged in DRDAConnThread.closeStream(InputStream stream)
[
https://issues.apache.org/jira/browse/DERBY-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen resolved DERBY-4350.
---
Resolution: Duplicate
Resolving as duplicate of DERBY-5396, which fixed the issue reported here
(except the logging part, which is tracked in DERBY-1191), and also a similar
occurrence in DRDAStatement.
javaException is created but not thrown or logged in
DRDAConnThread.closeStream(InputStream stream)
Key: DERBY-4350
URL: https://issues.apache.org/jira/browse/DERBY-4350
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.5.3.1, 10.6.1.0
Reporter: Kathey Marsden
Priority: Minor
Labels: derby_triage10_8
I noticed this code in DRDAConnThread.closesStream(InputStream stream)
private static void closeStream(InputStream stream){
try{
if (stream != null)
stream.close();
} catch (IOException e) {
Util.javaException(e);
}
}
I think the javaException won't be thrown or logged and the underlying
IOException will be lost. I have not investigated whether it should be
thrown or just logged, but should be addressed with the DERBY-1191 fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Performance problem with derby
Thanks a lot for your answer.
But after few tries to use XPLAIN I did not succeed to learn any thing, I
always get an error message when I run :
CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1);
CALL SYSCS_UTIL.SYSCS_SET_STATISTICS_TIMING(1);
CALL SYSCS_UTIL.SYSCS_SET_XPLAIN_SCHEMA('MYAPP');
I did not succeed to run the 3rd command I always get a :
Error: 'SYSCS_UTIL.SYSCS_SET_XPLAIN_SCHEMA' is not recognized as a function
or procedure.
SQLState: 42Y03
ErrorCode: -1
Error occured in:
CALL SYSCS_UTIL.SYSCS_SET_XPLAIN_SCHEMA('MYAPP')
My derby version is 10.8.1.2.
Does any one have an idea ?
Thanks again.
--
View this message in context:
http://old.nabble.com/Performance-problem-with-derby-tp32364853p32372414.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.
RE: Performance problem with derby
Do it this way:
CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1);
SELECT * FROM ;
VALUES SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(0);
Replace the SELECT * FROM ... with your query. The VALUES SYS... will
return one row, one column that contains the statement execution plan.
I use SquirrelSQL client and run the first statement, run the query, run the
values. Look at the query plan, and then turn the statistics off.
-Original Message-
From: mogoye [mailto:sylvain.rou...@eloquant.com]
Sent: Wednesday, August 31, 2011 10:10 AM
To: derby-dev@db.apache.org
Subject: RE: Performance problem with derby
Thanks a lot for your answer.
But after few tries to use XPLAIN I did not succeed to learn any thing, I
always get an error message when I run :
CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1);
CALL SYSCS_UTIL.SYSCS_SET_STATISTICS_TIMING(1);
CALL SYSCS_UTIL.SYSCS_SET_XPLAIN_SCHEMA('MYAPP');
I did not succeed to run the 3rd command I always get a :
Error: 'SYSCS_UTIL.SYSCS_SET_XPLAIN_SCHEMA' is not recognized as a function
or procedure.
SQLState: 42Y03
ErrorCode: -1
Error occured in:
CALL SYSCS_UTIL.SYSCS_SET_XPLAIN_SCHEMA('MYAPP')
My derby version is 10.8.1.2.
Does any one have an idea ?
Thanks again.
--
View this message in context:
http://old.nabble.com/Performance-problem-with-derby-tp32364853p32372414.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.
[jira] [Commented] (DERBY-5301) Convert store/TableLockBasic.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094608#comment-13094608 ] Bryan Pendleton commented on DERBY-5301: The most recent patch looks great to me. Both the old and new test suites pass in my configuration, and the new test program looks thorough and complete. I'm intending to commit this patch. Convert store/TableLockBasic.sql to junit -- Key: DERBY-5301 URL: https://issues.apache.org/jira/browse/DERBY-5301 Project: Derby Issue Type: Sub-task Components: Test Reporter: Houx Zhang Assignee: Houx Zhang Labels: gsoc2011 Attachments: 5301-1-part.patch, 5301-2-part.patch, 5301-3.patch, 5301-3.stat, TableLockBasicTest.java, TableLockBasicTest.java, junit.out -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Report - Daily 1161617 - Sun DBTG
[Auto-generated mail] *Daily* 1161617/2011-08-25 18:00:33 MEST Failed TestsOK Skip Duration Suite --- *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 01421914219 0 1076.70% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 040.21% derbyall UNKNOWNUNKNOWNUNKNOWN UNKNOWN 0.00% compatibility 022 0 .% demoSuite sol 01420714207 0 1221.19% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 035.21% derbyall 022 0 159.91% compatibility 022 0 .% demoSuite sol32 01420714207 0 .% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 0 .% derbyall 022 0 .% compatibility 022 0 .% demoSuite solN+1 01420714207 0 230.39% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 054.27% derbyall 022 0 160.33% compatibility 022 0 .% demoSuite sparc 01420714207 0 621.33% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 026.48% derbyall 022 0 134.07% compatibility 022 0 .% demoSuite vista 01421714217 0 196.83% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 048.68% derbyall NA NA NANA compatibility 022 0 .% demoSuite vista-64 01421714217 0 281.72% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 047.81% derbyall NA NA NANA compatibility 022 0 .% demoSuite w2003 01421714217 0 386.41% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 059.61% derbyall NA NA NANA compatibility 022 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1161617.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/1161617_bySig.html *Jvm: 1.5* lin NA NA NANA derbyall NA NA NANA suitesAll sles NA NA NANA derbyall 01224312243 0 1636.56% suitesAll sol 0182182 036.97% derbyall 01223112231 0 2242.97% suitesAll sol32 1182181 0 .% derbyall 01223112231 0 .% suitesAll solN+1 0182182 049.42% derbyall 01223112231 0 2318.13% suitesAll sparc 0182182 026.85% derbyall 01223112231 0 1454.70% suitesAll vista 0182182 036.81% derbyall F:1,E:11224112239 0 1383.98% suitesAll vista-64 0182182 048.27% derbyall 01224112241 0 317.36% suitesAll
RE: Performance problem with derby
Thanks a lot. Now I've got the following result : Statement Name: SQL_CURLH000C7 Statement Text: SELECT * FROM CALLCDRACD WHERE clientId='' ORDER BY CALLSTART OFFSET 10 ROWS FETCH NEXT 50 ROWS ONLY Parse Time: 0 Bind Time: 0 Optimize Time: 0 Generate Time: 0 Compile Time: 0 Execute Time: 0 Begin Compilation Timestamp : null End Compilation Timestamp : null Begin Execution Timestamp : null End Execution Timestamp : null Statement Execution Plan Text: Row Count (1): Number of opens = 1 Rows seen = 50 Rows filtered = 10 constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 optimizer estimated row count:45816.40 optimizer estimated cost: 873660.23 Source result set: Sort ResultSet: Number of opens = 1 Rows input = 460886 Rows returned = 60 Eliminate duplicates = false In sorted order = false Sort information: Number of merge runs=50 Number of rows input=460886 Number of rows output=460886 Size of merge runs=[9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055] Sort type=external constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 optimizer estimated row count:45816.40 optimizer estimated cost: 873660.23 Source result set: Table Scan ResultSet for CALLCDRACD at read committed isolation level using instantaneous share row locking chosen by the optimizer Number of opens = 1 Rows seen = 460886 Rows filtered = 0 Fetch Size = 16 constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 next time in milliseconds/row = 0 scan information: Bit set of columns fetched=All Number of columns fetched=28 Number of pages visited=46106 Number of rows qualified=460886 Number of rows visited=460886 Scan type=heap start position: null stop position: null qualifiers: Column[0][0] Id: 0 Operator: = Ordered nulls: false Unknown return value: false Negate comparison result: false optimizer estimated row count:45816.40 optimizer estimated cost: 873660.23 I'm pretty sure that my index is not used. But I wonder if my index and its usage is correct. In fact this DB is filled with a special use case : All 460 000 entries have the same ClientId. (This customer is deployed on a dedicated server, while smaller customers are shared in an other DB = ClientId field used to identify them) I was expecting that index would be usefull to avoid sorting results with the request : SELECT * FROM CALLCDRACD WHERE clientId='' ORDER BY CALLSTART OFFSET 10 ROWS FETCH NEXT 50 ROWS ONLY but it seems that I'm wrong. Can you confirm me if my index can be used in that way, or if there is a way to have better performance ? bbergquist wrote: Do it this way: CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1); SELECT * FROM ; VALUES SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS(); CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(0); Replace the SELECT * FROM ... with your query. The VALUES SYS... will return one row, one column that contains the statement execution plan. I use SquirrelSQL client and run the first statement, run the query, run the values. Look at the query plan, and then turn the statistics off. -- View this message in context: http://old.nabble.com/Performance-problem-with-derby-tp32364853p32373385.html Sent from the Apache Derby Developers mailing list archive at Nabble.com.
[jira] [Updated] (DERBY-4647) BaseTestCase.execJavaCmd() does not work with weme 6.2
[ https://issues.apache.org/jira/browse/DERBY-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-4647: -- Fix Version/s: 10.8.1.6 BaseTestCase.execJavaCmd() does not work with weme 6.2 -- Key: DERBY-4647 URL: https://issues.apache.org/jira/browse/DERBY-4647 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.1.0 Environment: IBM J9 2.4 Windows XP x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA JCL - 20080918_2026,foun11 Licensed Materials - Property of IBM J9 - VM for the Java(TM) platform, Version 2.4 (c) Copyright IBM Corp. 1991, 2008 All Rights Reserved Target: 20080919_023055_lHdFGQ (Windows XP 5.1 build 2600 Service Pack 3 x86) IBM is a registered trademark of IBM Corp. Java and all Java-based marks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Labels: derby_triage10_8 Fix For: 10.8.1.6, 10.9.0.0 Attachments: derby-4667_diff.txt Spawning a java process with BaseTestCase.execJavaCmd() does not work with weme 6.2, I think because the boot classpath does not get passed. This issue came up in DERBY-4179. After this issue is fixed, BootLockTest should be enabled for weme. The error is actually .JVMJ9VM011W Unable to load jclfoun10_24: The specified module could not be foun d. JVMEXEX013E Internal VM error: Failed to create Java VM JVMEXEX014I Run C:\cygwin\ibmsvn\ntsoftware\weme6.2\bin\j9.exe -help for usage execJavaProcess does pick up the j9 executable but does not pass on the other settings. This is how my script invokes the test with j9. It probably has a lot of legacy system properties not needed, but I suppose execJavaCmd should just pass along all system properties, but I don't know how it would get the bootclasspath. Perhaps -Dbootcp was a way to pass it on in the old harness. c:/cygwin/ibmsvn/ntsoftware/weme6.2/bin/j9 -jcl:foun11 -DderbyTesting.serverho st=localhost -DderbyTesting.clienthost=localhost -Demma.active= -Xbootclasspath/ a:c:/cygwin/ibmsvn/ntsoftware/weme6.2/lib/jdbc.jar -Dbootcp=c:/cygwin/ibmsvn/nts oftware/weme6.2/lib/jdbc.jar junit.textui.TestRunner org.apache.derbyTesting.fun ctionTests.tests.store.BootLockTest Otherwise, currently I think the method is only used in replication and network server, but am not sure. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094668#comment-13094668 ] Rick Hillegas commented on DERBY-5363: -- I think that the default embedded behavior should also be to use the tighter file permissions. From the release notes, embedded users, like client/server users, can figure out how to disable the tighter permissions if necessary. We have a significant security hole here: Broad permission is currently given to other users to type out conglomerates which contain sensitive information and to type out derby.log, which can contain SQL text. Backward compatibility is important but I believe it must be trumped by security fixes. I think that the security hole here is big enough to warrant breaking compatibility, particularly since a simple remedy removes the compatibility problem. Thanks. Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5347) Derby loops filling logs and consuming all CPU with repeated error: java.net.SocketException: EDC5122I Input/output error.
[ https://issues.apache.org/jira/browse/DERBY-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094675#comment-13094675 ] Kathey Marsden commented on DERBY-5347: --- Are there thoughts on whether we should retry if an IOException occurs on accept() or just log and shutdown the server on the first occurrence? Derby loops filling logs and consuming all CPU with repeated error: java.net.SocketException: EDC5122I Input/output error. -- Key: DERBY-5347 URL: https://issues.apache.org/jira/browse/DERBY-5347 Project: Derby Issue Type: Bug Affects Versions: 10.7.1.1 Environment: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-20100215 (SR11 FP1 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-20100127a (JIT enabled) J9VM - 20100122_52103_bHdSMr JIT - 20091016_1845ifx1_r8 GC - 20091026_AA) JCL - 20100215 Reporter: Force Rs Assignee: Kathey Marsden When a TCP/IP Stack on a z/OS system running Derby is stopped and started, Derby loops with the following stack trace repeated until disk space is exhausted on the logging file system: Wed Jul 20 07:49:51 CDT 2011 : EDC5122I Input/output error. java.net.SocketException: EDC5122I Input/output error. at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:457) at java.net.ServerSocket.implAccept(ServerSocket.java:473) at java.net.ServerSocket.accept(ServerSocket.java:444) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:241) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source) The derby log we generated was 498 megabytes and had 1,883,750 of these stack traces. Since Derby originated from IBM, the following link may provide a valuable clue as to how to fix the defect in Derby: http://www-01.ibm.com/support/docview.wss?uid=swg1PQ93090 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Performance problem with derby
Given the Sort it looks like index is not being used to avoid sorts. I am not sure why that is the case. Does adding an index on just CALLSTART help or not? The OFFSET feature is relatively new to derby and I am not sure if the optimizer has been fully updated to understand it. Maybe someone who knows more about the OFFSET feature can comment if the optimizer has been updated to know that this query is only going to look at 50 rows rather than all of them? Another option that might help is you can give derby hints in your query to force it to use the index. So in summary I would suggest doing the following in order: 1) run compress on the base table, this will make sure all the optimizer statistics are up to date, and retry to see if that helps. 2) create index on just CALLSTART and retry query to see if that helps. 3) drop new index and add hint to force your existing (clientid, callstart) index and see if that helps. In all cases if you want feedback on the above, including the queryplan as you have done below will help. mogoye wrote: Thanks a lot. Now I've got the following result : Statement Name: SQL_CURLH000C7 Statement Text: SELECT * FROM CALLCDRACD WHERE clientId='' ORDER BY CALLSTART OFFSET 10 ROWS FETCH NEXT 50 ROWS ONLY Parse Time: 0 Bind Time: 0 Optimize Time: 0 Generate Time: 0 Compile Time: 0 Execute Time: 0 Begin Compilation Timestamp : null End Compilation Timestamp : null Begin Execution Timestamp : null End Execution Timestamp : null Statement Execution Plan Text: Row Count (1): Number of opens = 1 Rows seen = 50 Rows filtered = 10 constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 optimizer estimated row count:45816.40 optimizer estimated cost: 873660.23 Source result set: Sort ResultSet: Number of opens = 1 Rows input = 460886 Rows returned = 60 Eliminate duplicates = false In sorted order = false Sort information: Number of merge runs=50 Number of rows input=460886 Number of rows output=460886 Size of merge runs=[9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055, 9055] Sort type=external constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 optimizer estimated row count:45816.40 optimizer estimated cost: 873660.23 Source result set: Table Scan ResultSet for CALLCDRACD at read committed isolation level using instantaneous share row locking chosen by the optimizer Number of opens = 1 Rows seen = 460886 Rows filtered = 0 Fetch Size = 16 constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 next time in milliseconds/row = 0 scan information: Bit set of columns fetched=All Number of columns fetched=28 Number of pages visited=46106 Number of rows qualified=460886 Number of rows visited=460886 Scan type=heap start position: null stop position: null qualifiers: Column[0][0] Id: 0 Operator: = Ordered nulls: false Unknown return value: false Negate comparison result: false optimizer estimated row count:45816.40 optimizer estimated cost: 873660.23 I'm pretty sure that my index is not used. But I wonder if my index and its usage is correct. In fact this DB is filled with a special use case : All 460 000 entries have the same ClientId. (This customer is deployed on a dedicated server, while smaller customers are shared in an other DB = ClientId field used to identify them) I was expecting that index would be usefull to avoid sorting results with the request : SELECT * FROM CALLCDRACD WHERE clientId='' ORDER BY CALLSTART OFFSET 10 ROWS FETCH NEXT 50 ROWS ONLY but it seems that I'm wrong. Can you confirm me
query for backports to 10.8 missing some bugs...
Hi, I've backported most of the issues for which I thought a backport was reasonable and marked others with the reject_backport label. I've been looking at this list based on a query Kathey set up in JIRA (also referenced off the DerbyTenEightTwoRelease wiki page): https://issues.apache.org/jira/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?jqlQuery=project=derby+and+type+not+in+%28Improvement,%22New+Feature%22%29+and+fixVersion+=+%2210.9.0.0%22++and+fixVersion+not+in+%28%2210.8.1.2%22,%2210.8.1.6%22%29+and+resolution+=+Fixed+AND+labels+not+in+%28derby_backport_reject_10_8%29tempMax=1000] But I've been also somewhat track of the actual commits, and for the second time I noticed a bug which as far as I can see should've shown up on the list, but hasn't: DERBY-5396. Can anyone figure out why it doesn't match the query? I've stared at it but fail to see. (for the other bug I backported or rejected the fix, so it's not a good test case for this anymore) Thx, Myrna
10.8.2 coming closer
Hi, We're about 12 days away from the date I picked to produce the 10.8.2.0 release candidate. I finished backported fixes for a number of bugs (I don't intend to backport a number of sql-to-junit conversions). I am watching the following issues (some critical), hoping they'll get fixed in time for a backport: DERBY-5367 (Stale data retrieved when using new collation=TERRITORY_BASED:PRIMARY feature - assignee: Kristian) DERBY-5363 (Tighten default permissions of DB files with = JDK6 - assignee: none) DERBY-5236? (Client driver silently truncates strings that exceed 32KB - assignee: Knut) DERBY-5395 (By default, only the DBO should be allowed to run several of the diagnostic VTIs - assignee: Rick) DERBY-5387 (Memory leak or unbounded consumption problem when running a utility to copy one database to another using SYSCS_EXPORT_TABLE and SYSCS_IMPORT_TABLE - assignee: none) I don't intend to hold up the release for any of these. Please let me know if my assessment of this list is wrong, i.e. if there are any issues which I've missed. Please let me know if you feel strongly that one of these (or another issue) needs to be fixed in 10.8.2. Is the latest change for DERBY-4275 (Query executions fail when compressing a table using SYSCS_UTIL.SYSCS_COMPRESS_TABLE - assignee: Knut) backportable? I think I'll backport the fix for DERBY-5396 unless someone else wants to do it. Thanks, Myrna
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094750#comment-13094750 ] Kathey Marsden commented on DERBY-5363: --- I think it would be good to get feedback from the user community. Some response that I got this week when I approached a group about the change was: ... that seems backward. Why not keep the current behavior and have a derby.storage.useSecureFilePermissions=true property? I know there are times when a component *really* needs to change default behavior, but it should only be after a lot of consideration and adopter buy-in Can you ask for more input on the user list? Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: query for backports to 10.8 missing some bugs...
On 8/31/2011 10:32 AM, Myrna van Lunteren wrote: But I've been also somewhat track of the actual commits, and for the second time I noticed a bug which as far as I can see should've shown up on the list, but hasn't: DERBY-5396. Can anyone figure out why it doesn't match the query? I've stared at it but fail to see. Hi Myrna, I think I located the problem with the query. It needs to include the possibility that labels is null. It is included with this query. project=derby and type not in (Improvement,New Feature) and fixVersion = 10.9.0.0 and fixVersion not in (10.8.1.2,10.8.1.6) AND resolution = Fixed AND (labels = null or labels not in (derby_backport_reject_10_8)) I'll changed it on the wiki page. That brings us from 12 to 21 issues. Folks might want to take another look at this list. https://issues.apache.org/jira/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?jqlQuery=project%3Dderby+and+type+not+in+%28Improvement%2C%22New+Feature%22%29+and+fixVersion+%3D+%2210.9.0.0%22++and+fixVersion+not+in+%28%2210.8.1.2%22%2C%2210.8.1.6%22%29++AND++resolution+%3D+Fixed+AND+%28labels+%3D+null+or+++labels+not+in+%28derby_backport_reject_10_8%29%29tempMax=1000 Thank you Myrna for catching this bug and sorry for the inconvenience. Kathey
[jira] [Commented] (DERBY-5010) [patch] bad equivalence check
[ https://issues.apache.org/jira/browse/DERBY-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094760#comment-13094760 ] Kathey Marsden commented on DERBY-5010: --- It seems the code may not be reachable so no need to backport. [patch] bad equivalence check - Key: DERBY-5010 URL: https://issues.apache.org/jira/browse/DERBY-5010 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.7.1.1 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Labels: derby_backport_reject_10_8 Fix For: 10.9.0.0 Attachments: IsEquivalent_DoNotCommit_June11.txt, IsEquivalent_Donotcommit_june14.txt, bad_equivalence_check.diff, derby.log, derby.log, june15.out, runoutputJune14.out, runoutputJune2.out Original Estimate: 1h Remaining Estimate: 1h code attempts to compare two BaseColumnNodes but doesn't compare the tableName correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (DERBY-5378) Update Derby web site copyright notice (2011)
[ https://issues.apache.org/jira/browse/DERBY-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reopened DERBY-5378: --- reopen to add backport reject label. Only relevant to trunk Update Derby web site copyright notice (2011) - Key: DERBY-5378 URL: https://issues.apache.org/jira/browse/DERBY-5378 Project: Derby Issue Type: Task Components: Web Site Reporter: Kristian Waagan Assignee: Kristian Waagan Labels: derby_backport_reject_10_8 Fix For: 10.9.0.0 Attachments: derby-5378-1a-copyright_2011_xdocs.diff The copyright notice on the Derby web site should be changed to claim copyright up through 2011. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5378) Update Derby web site copyright notice (2011)
[ https://issues.apache.org/jira/browse/DERBY-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-5378. - Resolution: Fixed Update Derby web site copyright notice (2011) - Key: DERBY-5378 URL: https://issues.apache.org/jira/browse/DERBY-5378 Project: Derby Issue Type: Task Components: Web Site Reporter: Kristian Waagan Assignee: Kristian Waagan Labels: derby_backport_reject_10_8 Fix For: 10.9.0.0 Attachments: derby-5378-1a-copyright_2011_xdocs.diff The copyright notice on the Derby web site should be changed to claim copyright up through 2011. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (DERBY-4533) Delete old releases from http://www.apache.org/dist
[ https://issues.apache.org/jira/browse/DERBY-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reopened DERBY-4533: --- reopen to add backport reject label. Only relevant to trunk Delete old releases from http://www.apache.org/dist --- Key: DERBY-4533 URL: https://issues.apache.org/jira/browse/DERBY-4533 Project: Derby Issue Type: Task Components: Web Site Reporter: Sebb Assignee: Kristian Waagan Labels: derby_backport_reject_10_8 Fix For: 10.9.0.0 The following old releases should be deleted from the main distribution folder: db-derby-10.3.3.0/ 19-May-2008 23:36- db-derby-10.4.2.0/ 08-Sep-2008 13:18- db-derby-10.5.1.1/ 29-Apr-2009 18:03- db-derby-10.5.2.0/ 31-Jul-2009 20:18- They are all available via the archives, so should be removed to free up space on the mirrors (and the ASF mirror masters). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-4533) Delete old releases from http://www.apache.org/dist
[ https://issues.apache.org/jira/browse/DERBY-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-4533. - Resolution: Fixed Delete old releases from http://www.apache.org/dist --- Key: DERBY-4533 URL: https://issues.apache.org/jira/browse/DERBY-4533 Project: Derby Issue Type: Task Components: Web Site Reporter: Sebb Assignee: Kristian Waagan Labels: derby_backport_reject_10_8 Fix For: 10.9.0.0 The following old releases should be deleted from the main distribution folder: db-derby-10.3.3.0/ 19-May-2008 23:36- db-derby-10.4.2.0/ 08-Sep-2008 13:18- db-derby-10.5.1.1/ 29-Apr-2009 18:03- db-derby-10.5.2.0/ 31-Jul-2009 20:18- They are all available via the archives, so should be removed to free up space on the mirrors (and the ASF mirror masters). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5395) By default, only the DBO should be allowed to run several of the diagnostic VTIs.
[ https://issues.apache.org/jira/browse/DERBY-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5395: - Attachment: SafeCacheViewer.java Attaching SafeCacheViewer.java. This is a table function which selects the safe columns from the statement cache vti. If the DBO registers this table function with definer's rights and grants EXECUTE privilege to PUBLIC, then anyone can view the safe columns of the statement cache. This technique can be used to grant other users privilege to view the safe bits of the diagnostic vtis whose access will be controlled when the patch is committed. Here's a script which shows this technique in action: ij version 10.9 ij connect 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword' as admin_conn; ij create function safeCacheViewer() returns table ( id char( 36 ), schemaName varchar( 128 ), valid boolean, compiled_at timestamp ) language java parameter style derby_jdbc_result_set reads sql data external security definer external name 'SafeCacheViewer.safeCacheViewer'; 0 rows inserted/updated/deleted ij grant execute on function safeCacheViewer to public; 0 rows inserted/updated/deleted ij connect 'jdbc:derby:memory:db;user=ruth;password=ruthpassword' as ruth_conn; ij(RUTH_CONN) -- fails permissions hurdle select * from syscs_diag.statement_cache; ERROR 4251D: Only the database owner can view this data. ij(RUTH_CONN) -- succeeds select * from table( test_dbo.safeCacheViewer() ) s; ID |SCHEMANAME |VALID|COMPILED_AT - ace4c0a3-0132-211b-dc8c-042be988|RUTH |true |NULL 4d3680a5-0132-211b-dc8c-042be988|TEST_DBO |true |NULL 341cc09e-0132-211b-dc8c-042be988|TEST_DBO |true |NULL 0b5b0099-0132-211b-dc8c-042be988|TEST_DBO |true |NULL 4 rows selected By default, only the DBO should be allowed to run several of the diagnostic VTIs. - Key: DERBY-5395 URL: https://issues.apache.org/jira/browse/DERBY-5395 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: SafeCacheViewer.java, derby-5395-01-ac-protectVTIs.diff Only the DBO should be allowed to run the following VTIs: syscs_diag.statement_cache syscs_diag.transaction_table syscs_diag.error_log_reader( ) syscs_diag.statement_duration() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (DERBY-5277) Intermittent OutOfMemoryErrors in BasicSetup.testTriggersWithLOBcolumns()
[ https://issues.apache.org/jira/browse/DERBY-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reopened DERBY-5277: --- reopen to add backport reject label as this only affects trunk Intermittent OutOfMemoryErrors in BasicSetup.testTriggersWithLOBcolumns() - Key: DERBY-5277 URL: https://issues.apache.org/jira/browse/DERBY-5277 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Labels: derby_backport_reject_10_8 Fix For: 10.9.0.0 Seen many times in the JDK 7 tests lately, and also in the Tinderbox. First occurrence was here: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/testlog/sol32/1134678-suitesAll_diff.txt (There had been no commits in the last two days before this test run, so it's difficult to say if a recent change caused it.) The test case has a comment that says that it should never read the LOB into memory, but according to the stack trace, that's exactly what's happening: Caused by: java.lang.OutOfMemoryError: Java heap space at org.apache.derby.iapi.types.SQLBinary.readFromStream(Unknown Source) at org.apache.derby.iapi.types.SQLBinary.readExternal(Unknown Source) at org.apache.derby.iapi.types.SQLBinary.getValue(Unknown Source) at org.apache.derby.iapi.types.SQLBinary.loadStream(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.objectifyStream(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.testTriggersWithLOBcolumns(BasicSetup.java:854) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5395) By default, only the DBO should be allowed to run several of the diagnostic VTIs.
[ https://issues.apache.org/jira/browse/DERBY-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094777#comment-13094777 ] Rick Hillegas commented on DERBY-5395: -- Regression tests passed cleanly for me on derby-5395-01-ac-protectVTIs.diff. Committed at subversion revision 1163740. By default, only the DBO should be allowed to run several of the diagnostic VTIs. - Key: DERBY-5395 URL: https://issues.apache.org/jira/browse/DERBY-5395 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: SafeCacheViewer.java, derby-5395-01-ac-protectVTIs.diff Only the DBO should be allowed to run the following VTIs: syscs_diag.statement_cache syscs_diag.transaction_table syscs_diag.error_log_reader( ) syscs_diag.statement_duration() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5277) Intermittent OutOfMemoryErrors in BasicSetup.testTriggersWithLOBcolumns()
[ https://issues.apache.org/jira/browse/DERBY-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-5277. - Resolution: Fixed Intermittent OutOfMemoryErrors in BasicSetup.testTriggersWithLOBcolumns() - Key: DERBY-5277 URL: https://issues.apache.org/jira/browse/DERBY-5277 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Labels: derby_backport_reject_10_8 Fix For: 10.9.0.0 Seen many times in the JDK 7 tests lately, and also in the Tinderbox. First occurrence was here: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/testlog/sol32/1134678-suitesAll_diff.txt (There had been no commits in the last two days before this test run, so it's difficult to say if a recent change caused it.) The test case has a comment that says that it should never read the LOB into memory, but according to the stack trace, that's exactly what's happening: Caused by: java.lang.OutOfMemoryError: Java heap space at org.apache.derby.iapi.types.SQLBinary.readFromStream(Unknown Source) at org.apache.derby.iapi.types.SQLBinary.readExternal(Unknown Source) at org.apache.derby.iapi.types.SQLBinary.getValue(Unknown Source) at org.apache.derby.iapi.types.SQLBinary.loadStream(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.objectifyStream(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.testTriggersWithLOBcolumns(BasicSetup.java:854) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094781#comment-13094781 ] Kathey Marsden commented on DERBY-5363: --- I personally don't think we have a security hole in Derby, but rather users might have a security hole if they do not set their umask appropriately to their situation. The proposed changes would help protect users from themselves and that may be the right thing to do, especially for network server, but I don't think it is a inherent hole in Derby. Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5347) Derby loops filling logs and consuming all CPU with repeated error: java.net.SocketException: EDC5122I Input/output error.
[ https://issues.apache.org/jira/browse/DERBY-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094826#comment-13094826 ] Force Rs commented on DERBY-5347: - I am not a Derby expert, but I do have significant programming experience. I would not kill the server immediately. At least 2 consecutive failures. I recently fixed our DB server. We had a watchdog thread that was pinging the DB and, when the ping failed, was killing the server. I had to change this to fail 3 consecutive times before killing the server. Having one ping fail was merely a hiccup (or separate Derby bug). Just my two cents. Derby loops filling logs and consuming all CPU with repeated error: java.net.SocketException: EDC5122I Input/output error. -- Key: DERBY-5347 URL: https://issues.apache.org/jira/browse/DERBY-5347 Project: Derby Issue Type: Bug Affects Versions: 10.7.1.1 Environment: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-20100215 (SR11 FP1 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-20100127a (JIT enabled) J9VM - 20100122_52103_bHdSMr JIT - 20091016_1845ifx1_r8 GC - 20091026_AA) JCL - 20100215 Reporter: Force Rs Assignee: Kathey Marsden When a TCP/IP Stack on a z/OS system running Derby is stopped and started, Derby loops with the following stack trace repeated until disk space is exhausted on the logging file system: Wed Jul 20 07:49:51 CDT 2011 : EDC5122I Input/output error. java.net.SocketException: EDC5122I Input/output error. at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:457) at java.net.ServerSocket.implAccept(ServerSocket.java:473) at java.net.ServerSocket.accept(ServerSocket.java:444) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:241) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source) The derby log we generated was 498 megabytes and had 1,883,750 of these stack traces. Since Derby originated from IBM, the following link may provide a valuable clue as to how to fix the defect in Derby: http://www-01.ibm.com/support/docview.wss?uid=swg1PQ93090 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5395) By default, only the DBO should be allowed to run several of the diagnostic VTIs.
[ https://issues.apache.org/jira/browse/DERBY-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5395: - Attachment: releaseNote.html Attaching the first rev of a release note for this issue. By default, only the DBO should be allowed to run several of the diagnostic VTIs. - Key: DERBY-5395 URL: https://issues.apache.org/jira/browse/DERBY-5395 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: SafeCacheViewer.java, derby-5395-01-ac-protectVTIs.diff, releaseNote.html Only the DBO should be allowed to run the following VTIs: syscs_diag.statement_cache syscs_diag.transaction_table syscs_diag.error_log_reader( ) syscs_diag.statement_duration() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5347) Derby loops filling logs and consuming all CPU with repeated error: java.net.SocketException: EDC5122I Input/output error.
[ https://issues.apache.org/jira/browse/DERBY-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094880#comment-13094880 ] Kathey Marsden commented on DERBY-5347: --- Thank you for the input. I'll have it retry three times then with a 1 sec wait between each and log a warning to the log for each failure. Derby loops filling logs and consuming all CPU with repeated error: java.net.SocketException: EDC5122I Input/output error. -- Key: DERBY-5347 URL: https://issues.apache.org/jira/browse/DERBY-5347 Project: Derby Issue Type: Bug Affects Versions: 10.7.1.1 Environment: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pmz31devifx-20100215 (SR11 FP1 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 z/OS s390-31 j9vmmz3123ifx-20100127a (JIT enabled) J9VM - 20100122_52103_bHdSMr JIT - 20091016_1845ifx1_r8 GC - 20091026_AA) JCL - 20100215 Reporter: Force Rs Assignee: Kathey Marsden When a TCP/IP Stack on a z/OS system running Derby is stopped and started, Derby loops with the following stack trace repeated until disk space is exhausted on the logging file system: Wed Jul 20 07:49:51 CDT 2011 : EDC5122I Input/output error. java.net.SocketException: EDC5122I Input/output error. at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:457) at java.net.ServerSocket.implAccept(ServerSocket.java:473) at java.net.ServerSocket.accept(ServerSocket.java:444) at org.apache.derby.impl.drda.ClientThread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(AccessController.java:241) at org.apache.derby.impl.drda.ClientThread.run(Unknown Source) The derby log we generated was 498 megabytes and had 1,883,750 of these stack traces. Since Derby originated from IBM, the following link may provide a valuable clue as to how to fix the defect in Derby: http://www-01.ibm.com/support/docview.wss?uid=swg1PQ93090 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-5301) Convert store/TableLockBasic.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton resolved DERBY-5301. Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: [Patch Available]) Committed patch 3 to the trunk as revision 1163880. Thank you for the contribution to Derby! Convert store/TableLockBasic.sql to junit -- Key: DERBY-5301 URL: https://issues.apache.org/jira/browse/DERBY-5301 Project: Derby Issue Type: Sub-task Components: Test Reporter: Houx Zhang Assignee: Houx Zhang Labels: gsoc2011 Fix For: 10.9.0.0 Attachments: 5301-1-part.patch, 5301-2-part.patch, 5301-3.patch, 5301-3.stat, TableLockBasicTest.java, TableLockBasicTest.java, junit.out -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-5363: - Attachment: derby-5363-basic-2.stat derby-5363-basic-2.diff Uploading derby-5363-basic-2, which removes the dependency on Java 7 for compiling Derby. The code in FileUtil7.java has been recoded with reflection and moved into FileUtil.java. Rerunning regressions. Any treatment of the property default, whichever way we choose to go, is yet pending. Apart from that, the patch is complete and ready for review. I do plan to go over the exception handling a bit more: although I have made pains to try to make any exception due to missing security permission propagate all the way up there are still locations in the code where I ignore them due to the fan-out if we introduce checked exception in low level utility classes, the theory being that the missing permissions would be detected elsewhere. I'll have a look to see if we could use unchecked exception and catch those at the top/boot level, cf. iapi.error.PassThroughException, since I don't like ignoring exceptions... Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, derby-5363-basic-2.diff, derby-5363-basic-2.stat, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5359) Missing xmlns attribute for html element in docs
[ https://issues.apache.org/jira/browse/DERBY-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095094#comment-13095094 ] Jayaram Subramanian commented on DERBY-5359: I also agree that we need to change the lib as well as xslhtml.. But 1 more thing i was curious was the only file under the xslhtml folder having the html attribute was ditat2htmlimpl.xsl. Also regarding second option to rewrite rule buildscript, does that mean elimination of xmlns= from html files post html file generation ? Missing xmlns attribute for html element in docs Key: DERBY-5359 URL: https://issues.apache.org/jira/browse/DERBY-5359 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Jayaram Subramanian Attachments: derby5359.diff, html.zip The html files in the documentation that are declared as XHTML don't pass as valid XHTML because the html elements lack the xmlns attribute. Examples: http://db.apache.org/derby/docs/dev/ref/index.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Findex.html http://db.apache.org/derby/docs/dev/ref/toc.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Ftoc.html http://db.apache.org/derby/docs/dev/ref/rrefcallprocedure.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Frrefcallprocedure.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095095#comment-13095095 ] Dag H. Wanvik commented on DERBY-5363: -- I am not sure that the property is backward, as suggested by Kathey's users: if people remember to explicitly use useSecureFilePermissions, they would probably remember to set the correct umask/Windows directory permissions too. The whole point of doing this is to protect users against themselves, i.e. provide a default that is secure rather than insecure. The question then becomes, in what use cases, in what deployment modes, is this protection a net benefit, and in which cases/deployment modes is the benefit outweighed by inconvenience (upgrade hassle, need to use a property to get sharing behavior). I do think that in the server case, the argument is stronger for a secure default, especially if authentication/authorization is enabled. Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, derby-5363-basic-2.diff, derby-5363-basic-2.stat, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Performance problem with derby
On 8/31/2011 7:19 PM, Mike Matrigali wrote: The OFFSET feature is relatively new to derby and I am not sure if the optimizer has been fully updated to understand it. Maybe someone who knows more about the OFFSET feature can comment if the optimizer has been updated to know that this query is only going to look at 50 rows rather than all of them? It hasn't been updated to understand this yet. Dag
[jira] [Assigned] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik reassigned DERBY-5363: Assignee: Dag H. Wanvik Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, derby-5363-basic-2.diff, derby-5363-basic-2.stat, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-5363: - Issue fix info: [Patch Available, Release Note Needed] (was: [Release Note Needed]) Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, derby-5363-basic-2.diff, derby-5363-basic-2.stat, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
