[jira] Commented: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
[ http://issues.apache.org/jira/browse/DERBY-815?page=comments#action_12364778 ] Dyre Tjeldvoll commented on DERBY-815: -- Yes, we should go ahead and revert the issue. Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() - Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Type: Sub-task Components: Network Server, Performance Versions: 10.0.2.2, 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2 Reporter: Knut Anders Hatlen Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.2.0.0 Attachments: d815_regress.diff, d815_regress.java, d815_regress.stat, d815_regress_derbyall_report.txt, derby-815.diff, derby-815.stat, derbyall_report.txt Reported by Kathey Marsden in DERBY-212: In reviewing the Network Server Code and profiling there were several areas that showed potential for providing performance improvement. Functions that need optimizing to prevent unneeded object creation and excessive decoding: parseSQLDTA_work() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
[ http://issues.apache.org/jira/browse/DERBY-815?page=all ] Dyre Tjeldvoll updated DERBY-815: - Other Info: (was: [Patch available]) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() - Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Type: Sub-task Components: Network Server, Performance Versions: 10.0.2.2, 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2 Reporter: Knut Anders Hatlen Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.2.0.0 Attachments: d815_regress.diff, d815_regress.java, d815_regress.stat, d815_regress_derbyall_report.txt, derby-815.diff, derby-815.stat, derbyall_report.txt Reported by Kathey Marsden in DERBY-212: In reviewing the Network Server Code and profiling there were several areas that showed potential for providing performance improvement. Functions that need optimizing to prevent unneeded object creation and excessive decoding: parseSQLDTA_work() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
[ http://issues.apache.org/jira/browse/DERBY-815?page=all ] Dyre Tjeldvoll updated DERBY-815: - Assign To: (was: Dyre Tjeldvoll) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() - Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Type: Sub-task Components: Network Server, Performance Versions: 10.0.2.2, 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2 Reporter: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: d815_regress.diff, d815_regress.java, d815_regress.stat, d815_regress_derbyall_report.txt, derby-815.diff, derby-815.stat, derbyall_report.txt Reported by Kathey Marsden in DERBY-212: In reviewing the Network Server Code and profiling there were several areas that showed potential for providing performance improvement. Functions that need optimizing to prevent unneeded object creation and excessive decoding: parseSQLDTA_work() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New SQL JIRA components (was Re: setting component's on jira items.)
On Jan 30, 2006, at 9:33 AM, Kathey Marsden wrote:On Jan 23, 2006, at 10:25 PM, Satheesh Bandaram wrote:This sounds good, balancing what is good for users and developersworking with JIRA's limitations. So, I would suggest:SQLSQL-parserSQL-optimizerSQL-compilerSQL-datatypeSQL-execute or SQL-executor (First one matches 'execute' package name)Should issues in the subcategories also be marked as SQL? I personally am not so keen on it because - makes it all the more liikely that issues will be assigned the wrong components - adds more maintenance - I am guessing we will gets lots of questions about where to put issues. Perhaps a better breakout, based on the current organization of the code, would be:SQL (== parser/datatypes/standards compliance)Optimizer (== reorg of query tree)Compile/Execute (== java representation of optimizer-selected query)Based on a quick review of the issues filed in JIRA, this makes sense to me. If I were to reclassify some of the current issues assigned to the SQL component, I would assign them as follows (by JIRA number):SQL - 20, 69, 277, 396, 464Optimizer - 269, 713, 781, 837, 890Compile/Execute - 28, 176, 338, 438, 759, 887And anything that crosses these boundaries should be assigned multiple components, such as SQL and JDBC, with DERBY-215. Or Store and Optimizer with DERBY-886.But, I'm sure there will be other opinions on the list. I won't make any changes until there's something resembling consensus. :-)andrew
[jira] Updated: (DERBY-840) International messages DatabaseMetaData to GetFileInputStreamAction in org.apache.derby.client.am
[ http://issues.apache.org/jira/browse/DERBY-840?page=all ] V.Narayanan updated DERBY-840: -- Attachment: internationalization_840.diff internationalization_840.stat Have used message id's XN100-XN150 in the patch. thanx Narayanan International messages DatabaseMetaData to GetFileInputStreamAction in org.apache.derby.client.am - Key: DERBY-840 URL: http://issues.apache.org/jira/browse/DERBY-840 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering Assignee: V.Narayanan Attachments: internationalization_840.diff, internationalization_840.stat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Features of the JUnit test execution harness
On 1/31/06, Kristian Waagan [EMAIL PROTECTED] wrote: Differences in output should be irrelevant. Although not what youmentioned above, the issue of (execution) control is very relevant. The logic for running the tests multiple times, each time with a differentsetup/environment must be located somewhere. I think Andreas' proposalof introducing a separate JUnit test type (see http://www.nabble.com/running-JUnit-tests-t887682.html#a2300670) makessense, as it gives us more freedom w.r.t. handling of JUnit tests. Yes, that proposal made sense to me. Ipersonallylike the approach of having a class for various/different configurations. Although that could get out of hand. Does this 'throw away' the work that Rick is doing on DERBY-874? Following Andreas' approach we'd still be able to run the individual tests separately, yes? Thanks for the answer Myrna. And good work on the readme! credit due: many people have reviewed, and improved it... snipRight now I feel that it is very hard to start writing a new JUnitharness, since the old harness seem to contain a lot of functionality and magic. I wonder if it would be best to just startconverting/writing some tests and create a framework along the way. Yes, a new harness is hard, and yes, the old harness hasbeen made to adapt to many different needs...and we should take those into account. (I'll add some thoughts on that wiki soon). But the old harness has grownunwieldy and hard to maintain and is slow.To take what we learnedandcraft it ontosomething new will be better, though daunting. Some ideas of Dan's are in this thread from about a year ago: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200503.mbox/[EMAIL PROTECTED] The above approach would probably result in several major rewritings ofthe new framework and the existing JUnit tests, but it might be better than thinking out everything at once (that's hard!). Perhaps I willrewrite an old test I have been working a little on, and put it out forreview and comments, unless someone else beats me to it ;) --Kristian Personally, I do betterwhen I have code to prod and modify through iterations... I'd be interested to review. Myrna
[jira] Commented: (DERBY-821) Client driver: Implicitly close exhausted result sets on the server
[ http://issues.apache.org/jira/browse/DERBY-821?page=comments#action_12364799 ] Knut Anders Hatlen commented on DERBY-821: -- Thanks for commenting on this issue, Philip. From my reading of DERBY-213 and DERBY-545, it seems like the term implicit closing has a different meaning in those issues. Before the DERBY-213 fix, forward-only result sets on the client were closed when the cursor was positioned after the last row. DERBY-213 and DERBY-545 call this behaviour implicit closing. The implicit closing I am talking about, happens only on the network server. The result set will be open on the client until close() is called explicitly, hence the application won't see any changes in behaviour. None of the test cases you added in DERBY-213 fail, e.g., next() still returns false instead of throwing an exception after last row. Client driver: Implicitly close exhausted result sets on the server --- Key: DERBY-821 URL: http://issues.apache.org/jira/browse/DERBY-821 Project: Derby Type: Improvement Components: Network Client, Network Server, Performance Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-821.diff, DERBY-821.stat, changes.html Forward-only result sets that are exhausted should be implicitly closed on the server. This way, ResultSet.close() does not have to send an explicit close message generating unnecessary network traffic. The DRDA protocol supports this. From the description of OPNQRY (open query): The qryclsimp parameter controls whether the target server implicitly closes a non-scrollable query upon end of data (SQLSTATE 02000) in association with the cursor type. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Server and client compatibility test for 10.2 and 10.1
Hi, Kathey == Kathey Marsden [EMAIL PROTECTED] wrote: Kathey Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1 Kathey - Kathey jvms: jdk15, ibm142 Kathey Kathey Test failures: Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java I have run this mixed release scenario (details below) and checked the results for: lang/forupdate.sql lang/updatableResultSet.java. In both cases, the differences are due to changes in the client, and thus expected. The changes are reflected in the current (10.2) client masters. Mostly, the diffs are changed exception messages, and in some cases, SQLStates. Dag *** Start Suite: derbynetclientmats 2006-02-01 02:41:16 *** -- Java Information -- Java Version:1.5.0_04 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.5.0_04/jre Java classpath: /home/dw136774/derby/trunk/jars/sane/derbyclient.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derby.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbytools.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbynet.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyTesting.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_de_DE.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_es.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_fr.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_it.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_ja_JP.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_ko_KR.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_pt_BR.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_zh_CN.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_zh_TW.jar:/home/dw136774/derby/trunk/tools/java/jakarta-oro-2.0.8.jar OS name: SunOS OS architecture: x86 OS version: 5.10 Java user name: dw136774 Java user home: /home/dw136774 Java user dir: /home/dw136774/derbytests/compat2 java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [/home/dw136774/derby/trunk/jars/sane/derbyclient.jar] 10.2.0.0 alpha - (371922M) [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derby.jar] 10.1.2.1 - (330608) [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbytools.jar] 10.1.2.1 - (330608) [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbynet.jar] 10.1.2.1 - (330608)
[jira] Updated: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
[ http://issues.apache.org/jira/browse/DERBY-815?page=all ] Dyre Tjeldvoll updated DERBY-815: - Attachment: derby.log While converting AB's repro for the regression into a test (in the test harness) I discovered that the last execute triggers an unexpected exception in embedded mode (see the attached derby.log for details). I realize that to test the regression it is only necessary to run the test against the NetworkServer, but it shouldn't fail in embedded mode, should it? Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() - Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Type: Sub-task Components: Network Server, Performance Versions: 10.0.2.2, 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2 Reporter: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: d815_regress.diff, d815_regress.java, d815_regress.stat, d815_regress_derbyall_report.txt, derby-815.diff, derby-815.stat, derby.log, derbyall_report.txt Reported by Kathey Marsden in DERBY-212: In reviewing the Network Server Code and profiling there were several areas that showed potential for providing performance improvement. Functions that need optimizing to prevent unneeded object creation and excessive decoding: parseSQLDTA_work() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
paging Sunitha
Hi Sunitha, I have fixed Derby - 856 (patch related to setCharacterStreamInternal). I have modified it to use newSqlException like EmbedPreparedStatement. I have fixed the tests too. Can you please see if these changes concur with the fix for setBinaryStreamInternal (DERBY-599). Thanx, Narayanan
Re: [jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
In other words, the patch seems to provide significant improvement to Derby robustness with regards to cases where statements are not always explicitly closed by the application using the Derby client. The garbage collector is able to collect much more garbage with the patch than without. This is *excellent* news! Can you tell, at this point, whether there is a secondary leak that we must additionally pursue? That is, does it seem as though, if we are able to incorporate the DERBY-210 fixes into the base product, we will be able to run DOTS without memory exhaustion errors? I guess what I'm asking is: what duration of test, with the patch applied, would be enough to satisfy us that there are no additional memory leaks exposed by this test? thanks, bryan
Defining compatibility stability (was Re: Server and client compatibility test for 10.2 and 10.1)
Thanks for trackin these down, Dag. So, I'm not sure how this works. We have made compatible changes in terms of the API, but incompatible in terms of the output, particularly of message strings. Is this considered a failure, and we are no longer backward-compatible? I agree we want to be backward-compatible, but do we need to apply the same level of rigor to ij output format and error message strings as we do to APIs? At Sun we have a mechanism for declaring the stability of each interface we present to users, where interfaces include but are not limited to: - APIs - command-line interface name and syntax - stdout - stderr - error codes from command-line interfaces - jar file names - package names - directory structure - install location - configuration file names - configuration file syntax and format - database file format - transaction log file format - error log file format Each stability level implies a contract as to how and when an interface can change (generally: it can change at a major release, at a minor release, or at any time). Generally things like the API and CLI syntax have a higher stability guarantee than say stderr or the error log format. I think it might be worth our while to put up a Wiki page and identify all our interfaces and the level of stability we want to have for them, so we know what we should be testing for in terms of compatibility between releases... David Dag H. Wanvik wrote: Hi, Kathey == Kathey Marsden [EMAIL PROTECTED] wrote: Kathey Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1 Kathey - Kathey jvms: jdk15, ibm142 Kathey Kathey Test failures: Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java I have run this mixed release scenario (details below) and checked the results for: lang/forupdate.sql lang/updatableResultSet.java. In both cases, the differences are due to changes in the client, and thus expected. The changes are reflected in the current (10.2) client masters. Mostly, the diffs are changed exception messages, and in some cases, SQLStates. Dag *** Start Suite: derbynetclientmats 2006-02-01 02:41:16 *** -- Java Information -- Java Version:1.5.0_04 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.5.0_04/jre Java classpath: /home/dw136774/derby/trunk/jars/sane/derbyclient.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derby.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbytools.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbynet.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyTesting.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_de_DE.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_es.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_fr.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_it.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_ja_JP.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_ko_KR.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_pt_BR.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_zh_CN.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_zh_TW.j ar:/home/dw136774/derby/trunk/tools/java/jakarta-oro-2.0.8.jar OS name: SunOS OS architecture: x86 OS version: 5.10 Java user name: dw136774 Java user home: /home/dw136774 Java user dir: /home/dw136774/derbytests/compat2 java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [/home/dw136774/derby/trunk/jars/sane/derbyclient.jar] 10.2.0.0 alpha - (371922M) [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derby.jar] 10.1.2.1 - (330608) [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbytools.jar] 10.1.2.1 - (330608) [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbynet.jar] 10.1.2.1 - (330608) begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software
Anyone knows how I can read the content of derby log control file and log file??
Hi, is there anyone happens to know how I can read the content of derby log control and log files? I know they are binary files. I need to know the content of those files. Anyone can help me? Thanks. Raymond _ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
Re: paging Sunitha
V.Narayanan wrote: Hi Sunitha, I have fixed Derby - 856 (patch related to setCharacterStreamInternal). I have modified it to use newSqlException like EmbedPreparedStatement. I have fixed the tests too. Can you please see if these changes concur with the fix for setBinaryStreamInternal (DERBY-599). Hi Narayanan, Thanks for posting the patch. Yes, I will look at it today. Sunitha.
Re: [jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
I hope this patch gets (re-)committed once the current issues are resolved. Thanks John for running tests with the patch and posting results. I have been trying to create a repro for the sporadic problem which occured after commiting this patch. After few unsuccessful attempts, I put it on hold and got side-tracked into working on another bug. I plan to continue work on it this week. If tests pass, I will submit an updated patch for review in couple of days. Thanks, Deepa
[jira] Commented: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
[ http://issues.apache.org/jira/browse/DERBY-815?page=comments#action_12364831 ] A B commented on DERBY-815: --- Good catch. Actually, I think the error in embedded mode is probably correct, given the repro I posted. When we insert the 3rd row, we do two setBlobs and two setClobs; for the fourth row, we do a setNull for one of the blobs and for one of the clobs (params 7 and 9) but do not re-set the others (params 6 and 8), and hence this error occurs because we're trying to re-use the lob streams. If you add the following two lines to the block for the 4th row: pSt.setBlob(6, rs.getBlob(6)); pSt.setClob(8, rs.getClob(8)); then the test case will pass with embedded and still show the regression hang against the client. As for why the client didn't throw an error, I think it's because materialization of the lobs occurs on the client/server, so we're not reusing a stream per se, we're just reusing the materialized versions of the lobs. I believe this is related to DERBY-326 and DERBY-550... (thanks to Sunitha for the pointers!). Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() - Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Type: Sub-task Components: Network Server, Performance Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.0.2.2 Reporter: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: d815_regress.diff, d815_regress.java, d815_regress.stat, d815_regress_derbyall_report.txt, derby-815.diff, derby-815.stat, derby.log, derbyall_report.txt Reported by Kathey Marsden in DERBY-212: In reviewing the Network Server Code and profiling there were several areas that showed potential for providing performance improvement. Functions that need optimizing to prevent unneeded object creation and excessive decoding: parseSQLDTA_work() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-800) derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout
[ http://issues.apache.org/jira/browse/DERBY-800?page=all ] Mike Matrigali updated DERBY-800: - Component: Regression Test Failure Priority: Critical (was: Minor) adding to regression suite and raising priority as discussed for regression suite bugs. derbylang/ConcurrentImplicitCreateSchema.java fails intermittently with a lock timeout -- Key: DERBY-800 URL: http://issues.apache.org/jira/browse/DERBY-800 Project: Derby Type: Bug Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Øystein Grøvlen Priority: Critical I have seen ConcurrentImplicitCreateSchema.java get a lock timeout periodically and it occurred in the posted sun tests for build 365391 http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/365391-derbylang_diff.txt (I don't know how long this link will last. Below is the diff) * Diff file derbylang/derbylang/ConcurrentImplicitCreateSchema.diff *** Start: ConcurrentImplicitCreateSchema jdk1.5.0_04 derbylang:derbylang 2006-01-02 20:03:09 *** 2 del Closed connection 3 del Test ConcurrentImplicitCreateSchema PASSED 3 add ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:550)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScan(B2IRowLocking3.java:135)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requestedSQL Exception: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301)SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested SQL Exception: A lock could not be obtained within the time requested ERROR 40XL1: A lock could not be obtained within the time requested
[jira] Assigned: (DERBY-899) Cannot rollback to savepoint when using ClientXADataSource
[ http://issues.apache.org/jira/browse/DERBY-899?page=all ]
Kathey Marsden reassigned DERBY-899:
Assign To: Kathey Marsden
Cannot rollback to savepoint when using ClientXADataSource
--
Key: DERBY-899
URL: http://issues.apache.org/jira/browse/DERBY-899
Project: Derby
Type: Bug
Components: Network Client, Network Server
Versions: 10.1.1.0, 10.1.1.1
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.3
From a user using client XA.
save points don't seem to be working with DerbyClient using
XA.
levels i am on:
10.1.2.2
Apache Derby
Exception thrown is:
Exception in thread main
org.apache.derby.client.am.SqlException: SAVEPOINT, MyPoint
does not exist or is not active in the current transaction.
at org.apache.derby.client.am.Statement.completeSqlca(Unknown
Source)
at
org.apache.derby.client.am.Statement.completeExecuteImmediate(Un
known Source)
at
org.apache.derby.client.net.NetStatementReply.parseEXCSQLIMMrepl
y(Unknown Source)
at
org.apache.derby.client.net.NetStatementReply.readExecuteImmedia
te(Unknown Source)
at
org.apache.derby.client.net.StatementReply.readExecuteImmediate(
Unknown Source)
at
org.apache.derby.client.net.NetStatement.readExecuteImmediate_(U
nknown Source)
at
org.apache.derby.client.am.Statement.readExecuteImmediate(Unknow
n Source)
at org.apache.derby.client.am.Statement.flowExecute(Unknown
Source)
at org.apache.derby.client.am.Statement.executeX(Unknown
Source)
at org.apache.derby.client.am.Connection.rollback(Unknown
Source)
at
org.apache.derby.client.am.LogicalConnection.rollback(Unknown
Source)
at
Derby.networkServer.NSConnection.main(NSConnection.java:103)
Test case below
class SavePointProblem337977
{
public static void main (String args [])throws Exception {
//org.apache.derby.jdbc.ClientConnectionPoolDataSource ds
= new org.apache.derby.jdbc.ClientConnectionPoolDataSource();
org.apache.derby.jdbc.ClientXADataSource ds = new
org.apache.derby.jdbc.ClientXADataSource();
Connection conn = null;
ds.setDatabaseName(e:\\temp\\sampl127;create=true);
XAConnection xaCon = ds.getXAConnection() ;
//PooledConnection xaCon = ds.getPooledConnection() ;
conn = xaCon.getConnection();
DatabaseMetaData md = conn.getMetaData() ;
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());
Statement st = null;
PreparedStatement ps1 = null;
try
{
st = conn.createStatement ();
try
{
st.executeUpdate (drop table TAB1);
}catch (SQLException x)
{
System.out.println (no table exists);
}
ps1 = conn.prepareStatement(CREATE TABLE
TAB1(COL1 INT NOT NULL));
ps1.executeUpdate();
conn.commit ();
} catch (SQLException x)
{
System.out.println (table already exists);
}
conn.setAutoCommit(false);
conn.createStatement().execute(update tab1 set col1 =
-1 where col1 = 9);
Savepoint savepoint1 = conn.setSavepoint(MyPoint);
conn.rollback(savepoint1);
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-273) The derbynet/dataSourcePermissions_net.java test fails intermittently
[ http://issues.apache.org/jira/browse/DERBY-273?page=all ] Mike Matrigali updated DERBY-273: - Environment: 1.4.2 JVM (both Sun and IBM) 1.5.0_02 JVM (sun) was:1.4.2 JVM (both Sun and IBM) The derbynet/dataSourcePermissions_net.java test fails intermittently - Key: DERBY-273 URL: http://issues.apache.org/jira/browse/DERBY-273 Project: Derby Type: Bug Components: Network Server, Regression Test Failure Environment: 1.4.2 JVM (both Sun and IBM) 1.5.0_02 JVM (sun) Reporter: Jack Klebanoff Assignee: Tomohito Nakayama The test fails in the derbyall/derbynetclientmats/derbynetmats suite stack with the following diff: *** Start: dataSourcePermissions_net jdk1.4.2 DerbyNetClient derbynetmats:derbynetmats 2005-05-11 04:24:11 *** 17a18,19 org.apache.derby.iapi.services.context.ShutdownException: agentThread[DRDAConnThread_2,5,derby.daemons] Test Failed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Keeping derby.properties and the database files in different directories
Afkham Azeez wrote: Hi Folks, I have my derby.properties file in $MY_PROJECT/conf directory. This is the directory pointed to by the derby.system.home System property. But no my database is getting created under $MY_PROJECT/conf e.g. as $MY_PROJECT/conf/DATABASE. I need my database to be created as $MY_PROJECT/DATABASE. Is there a property I can specify in the derby.properties file which will specify the physical location of the Database? -- Thanks in Advance Afkham Azeez You have a couple of options. 1) If the URL is being specified in a program you can expand $MY_PROJECT and use it to construct a fullpath database URL (e.g. DriverManager.getConnection(jdbc:derby:/var/myProjDir/theDB) 2) Otherwise you need to set the properties someway other than using a derby.properties file. Set derby.system.home to the location where you want your databases created and set the properties as JVM arguments (e.g. java -Dproperty=value) in a way similar to how you are setting derby.system.home. the properties. If you are using a Server there is often a .properties file that the server loads when it starts. HTH
[jira] Commented: (DERBY-855) Document optimizer overrides which were introduced in 10.2
[
http://issues.apache.org/jira/browse/DERBY-855?page=comments#action_12364849 ]
Eric Radzinski commented on DERBY-855:
--
There's three open issues on derby-855. I've summarized them here:
--- Does this text adequately address your concern about the description of the
constraint property:
constraint
To force the use of the index that enforces a primary key, a foreign key, or
unique constraint, use the constraint property and specify the
unqualified name of the constraint. The constraint property can be used only
within a TableExpression, and it
can be specified only on base tables; it cannot be specified on views or
derived tables.
--- I haven't seen a response about my proposal to modify the syntax to include
the properties in the syntax. Here's what I proposed on 1/27:
The syntax for FROM clause properties is:
FROM [ -- DERBY-PROPERTIES joinOrder = FIXED | UNFIXED ]
TableExpression [,TableExpression]*
The syntax for table optimizer override properties, which must be included at
the end of a TableExpression, is:
{TableName | ViewName }
[ [ AS ] CorrelationName
[ (SimpleColumnName [ , SimpleColumnName]* ) ] ]
[ -- DERBY-PROPERTIES constraint=constraint-name |
index=index-name | joinStrategy = NESTEDLOOP | HASH ]
--- Regarding the comment about runstats output, is there a doc to-do in this
comment? or does this apply only to the output when a foreign key is
specified? If there is a doc to-do, can you provide me some details about what
it should include?
Document optimizer overrides which were introduced in 10.2
--
Key: DERBY-855
URL: http://issues.apache.org/jira/browse/DERBY-855
Project: Derby
Type: Sub-task
Components: Documentation
Versions: 10.2.0.0
Reporter: Mamta A. Satoor
Assignee: Eric Radzinski
Fix For: 10.2.0.0
Attachments: ctundepthoptover.html, ctunoptimzoverride.html,
ctunoptimzoverride.html
Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric
Radzinski is working on the documentation part of the feature. This issue is
to keep track of documentation changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (DERBY-909) Improve performance of String literals in statements
Improve performance of String literals in statements Key: DERBY-909 URL: http://issues.apache.org/jira/browse/DERBY-909 Project: Derby Type: Improvement Components: Newcomer, SQL Reporter: Daniel John Debrunner Priority: Minor String literals (constants) go through this process currently Create String object from within parser Serialized String into generated class file as UTF-8 (taking up two constant pool entries) Unserialize and intern String from generated class at class load time The serialize into the class file and un-serialize can be avoided by saving the String in the saved object pool (see CompilerContext) This would benefit the common pattern we see in SQL scripts that load data like: insert into customer values (1, 'Fred', 'Flintstone'); insert into customer values (2, 'Wilma'', 'Flintstone'); etc. etc. Note these are poor performing in Derby compared to other databases. It would also be a step on the way to having a single compiled plan for such statements that don't use parameter markers. Most likely the performance benefit with inserts will be small until DERBY-888 is fixed, because with inserts the sync of the allocated pages dominates the cost. Possible newcomer task with guideance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-680) In ij, executing a prepared statement with numeric/decimal parameter fails with NullPointerException in J2ME/CDC/FP
[
http://issues.apache.org/jira/browse/DERBY-680?page=comments#action_12364854 ]
Daniel John Debrunner commented on DERBY-680:
-
Submitted changes to ejbql test from patch derby-680_v2.diff , as they are
separate from the code change to ij.
In ij, executing a prepared statement with numeric/decimal parameter fails
with NullPointerException in J2ME/CDC/FP
---
Key: DERBY-680
URL: http://issues.apache.org/jira/browse/DERBY-680
Project: Derby
Type: Bug
Components: Tools
Versions: 10.2.0.0
Environment: j9_foundation VM in IBM WCTME 5.7
Reporter: Deepa Remesh
Assignee: Deepa Remesh
Attachments: derby-680_v2.diff, derby-680_v2.status
NPE is thrown in ij when executing prepared statement which
- has numeric/decimal parameters
- does not return any result set
Repro for this problem is the test lang/cast.sql. This test currently fails
in CDC/FP.
The following lines in the test throw NPE:
execute q10 using 'values 123456.78';
execute q11 using 'values 123456.78';
where q10 is prepare q10 as 'insert into t1 (num) values cast(? as
numeric(18))';
and q11 is prepare q11 as 'insert into t1 (dc) values cast(? as
decimal(18))';
The stack trace for failure is:
java.lang.NullPointerException
at org.apache.derby.impl.tools.ij.util.DisplayMulti(util.java:666)
at
org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:398)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:290)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:203)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169)
at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
at org.apache.derby.tools.ij.main(ij.java:56)
This happens in the following code. Since the above prepared statements do
not return result sets, call to getMetaData() will return null. But in the
code, no check is done to see if getMetaData() returns null before calling
getColumnType.
---
// In J2ME there is no object
that represents
// a DECIMAL value. By default
use String to
// pass values around, but for
integral types
// first convert to a integral
type from the DECIMAL
// because strings like 3.4 are
not convertible to
// an integral type.
switch
(ps.getMetaData().getColumnType(c))
{
case Types.BIGINT:
ps.setLong(c,
rs.getLong(c));
break;
case Types.INTEGER:
case Types.SMALLINT:
case Types.TINYINT:
ps.setInt(c,
rs.getInt(c));
break;
default:
ps.setString(c,rs.getString(c));
break;
}
---
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (DERBY-910) RunTimeStatistics shows system generated backing index name rather than the constraint name when optimizer overrides is used for constraint
RunTimeStatistics shows system generated backing index name rather than the
constraint name when optimizer overrides is used for constraint
---
Key: DERBY-910
URL: http://issues.apache.org/jira/browse/DERBY-910
Project: Derby
Type: Bug
Components: SQL
Versions: 10.2.0.0
Reporter: Mamta A. Satoor
Priority: Minor
When user specifies a constraint name in optimizer overrides for a query, the
runtime statistics info on that query shows the backing index name rather than
the constraint name. eg
create table prim ( i int not null primary key, j int);
create table sec (i int, constraint fk foreign key(i) references prim(i), j
int);
select * from sec --derby-properties constraint=fk
;
...
optimizer estimated cost: 136.34
User supplied optimizer overrides on SEC are { index=SQL060131012414010}
=
Index Scan ResultSet for SEC using constraint FK at read committed
isolation level using instantaneous share row locking chosen by the optimizer
Number of opens = 1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-869) documentation to address Derby-783
[ http://issues.apache.org/jira/browse/DERBY-869?page=all ] Jean T. Anderson resolved DERBY-869: Fix Version: 10.2.0.0 Resolution: Fixed Applied the patch derby869.diff that was uploaded on Jan 27, 2006, to the trunk and committed revision 374145. Modified file: $ svn status M src/ref/rrefsqlj81859.dita documentation to address Derby-783 -- Key: DERBY-869 URL: http://issues.apache.org/jira/browse/DERBY-869 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.0 Reporter: Eric Radzinski Assignee: Eric Radzinski Fix For: 10.2.0.0 Attachments: derby869.diff, derby869.diff, rrefsqlj81859.html, rrefsqlj81859.html document changes to ALTER TABLE syntax to address Derby-783 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Discussion of how to map the recovery time into Xmb of log --Checkpoint issue
I think this is the right path, though would need more details: o does boot mean first time boot for each db? o how to determine this machine o and the total time to run such a test. There are some very quick and useful tests that would be fine to add to the default system and do one time per databaseMeasureing how long to do a commit and how long to do a single database read from disk would be fine. Seems like just these 2 numbers could be used to come up with a very good default estimate of log recovery time per log record. Then as you propose the actual estimate can be improved by meauring real recovery time in the future. I am not convinced of the need for the bigger test, but if the default is not to run it automatically and it is your itch to have such a configuration option then I would not oppose. I do see great value in coming up with a very good default estimate of recovery time estimate based on outstanding number of log records. And I even envision a framework in the future where derby would schedule other non-essential background tasks that have been discussed in the On a different track I am still unclear on the checkpoint dirty page lru list. Rather than talk about implementation details, I would like to understand the problem you are trying to solve. For instance I well understand the goal to configure checkpoints such that they map to user understandable concept of the tradeoff of current runtime performance vs. how long am I willing to wait the next time I boot the database after a crash. What is the other problem you are looking at. Raymond Raymond wrote: Mike, Last time we discussed about how to map the recovery time into Xmb of log. I have been thinking on it recently and have a proposal. How about when the very first time derby boots (not every time) on a certain machine, we let the user to chose whether he (or she) want to do some statistic collection about the system performance. If he (or she) want to do, derby runs some test, if not, derby doesn't run test. Later, just as what you said, we let derby collect information every time it does recovery to refine the former information. Thanks. Raymond _ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
[jira] Updated: (DERBY-683) Use correct encoding for ClobOutputStream on client
[ http://issues.apache.org/jira/browse/DERBY-683?page=all ] Deepa Remesh updated DERBY-683: --- Attachment: (was: clob.java) Use correct encoding for ClobOutputStream on client --- Key: DERBY-683 URL: http://issues.apache.org/jira/browse/DERBY-683 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.1, 10.1.1.0 Environment: all Reporter: Sunitha Kambhampati Assignee: Deepa Remesh Fix For: 10.2.0.0 Attachments: ascii.txt In client, there is code in ClobOutputStream which uses this api - new String(byte[]). Per the java api http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#String(byte[]) ,this will construct a string by decoding the array of bytes using the platform's default character set. org.apache.derby.client.am.ClobOutputStream is used for Clob.setAsciiStream and the write methods use the String(byte[]) which is incorrect because it will use the default platform encoding. Per the jdbcapi , this should use ascii encoding. In areas related to Clobs, also check for other places where String(byte[]) is used,as it may not be the desired behavior. Dan pointed this problem here : http://issues.apache.org/jira/browse/DERBY-463?page=comments#action_12356742 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-683) Use correct encoding for ClobOutputStream on client
[ http://issues.apache.org/jira/browse/DERBY-683?page=all ] Deepa Remesh updated DERBY-683: --- Attachment: (was: derby-683-for-review.diff) Use correct encoding for ClobOutputStream on client --- Key: DERBY-683 URL: http://issues.apache.org/jira/browse/DERBY-683 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.1, 10.1.1.0 Environment: all Reporter: Sunitha Kambhampati Assignee: Deepa Remesh Fix For: 10.2.0.0 Attachments: ascii.txt In client, there is code in ClobOutputStream which uses this api - new String(byte[]). Per the java api http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#String(byte[]) ,this will construct a string by decoding the array of bytes using the platform's default character set. org.apache.derby.client.am.ClobOutputStream is used for Clob.setAsciiStream and the write methods use the String(byte[]) which is incorrect because it will use the default platform encoding. Per the jdbcapi , this should use ascii encoding. In areas related to Clobs, also check for other places where String(byte[]) is used,as it may not be the desired behavior. Dan pointed this problem here : http://issues.apache.org/jira/browse/DERBY-463?page=comments#action_12356742 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Anyone knows how I can read the content of derby log control file and log file??
Raymond Raymond [EMAIL PROTECTED] writes: Hi, is there anyone happens to know how I can read the content of derby log control and log files? I know they are binary files. I need to know the content of those files. Anyone can help me? The format of the log files is described here: http://db.apache.org/derby/papers/logformats.html All you need is a utility which gives you a hex dump and you're in action! :) -- Knut Anders
[jira] Updated: (DERBY-683) Use correct encoding for ClobOutputStream on client
[ http://issues.apache.org/jira/browse/DERBY-683?page=all ] Deepa Remesh updated DERBY-683: --- Attachment: derby-683.diff clob.java Attaching a patch 'derby-683.diff'. The write methods in ClobOutputStream were using default encoding when constructing a String from bytes. ClobOutputStream is the output stream returned by call to Clob.setAsciiStream. This is meant to be a stream to which ascii encoded characters can be written. So the writes to this stream should not be using default encoding. This patch changes the write methods to use String constructors with ascii encoding. Currently, I have a repro to test this. I am working on adding a test to the harness. This requires some changes to the test harness and I would like to submit this as a separate patch. To test this using the repro, run the following command on Windows with Sun JDK1.5: java -Dfile.encoding=UTF-16 -Doutput.encoding=Cp1252 clob With this patch, I have run derbyall on Windows with Sun JDK 1.4.2. No failures. It would be good if someone can look at this patch and commit the code changes if they are okay. I will submit the harness changes and a test in a separate patch. Use correct encoding for ClobOutputStream on client --- Key: DERBY-683 URL: http://issues.apache.org/jira/browse/DERBY-683 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.1, 10.1.1.0 Environment: all Reporter: Sunitha Kambhampati Assignee: Deepa Remesh Fix For: 10.2.0.0 Attachments: ascii.txt, clob.java, derby-683.diff In client, there is code in ClobOutputStream which uses this api - new String(byte[]). Per the java api http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#String(byte[]) ,this will construct a string by decoding the array of bytes using the platform's default character set. org.apache.derby.client.am.ClobOutputStream is used for Clob.setAsciiStream and the write methods use the String(byte[]) which is incorrect because it will use the default platform encoding. Per the jdbcapi , this should use ascii encoding. In areas related to Clobs, also check for other places where String(byte[]) is used,as it may not be the desired behavior. Dan pointed this problem here : http://issues.apache.org/jira/browse/DERBY-463?page=comments#action_12356742 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Anyone knows how I can read the content of derby log control file and log file??
Yes, I mean to know what kind of utilities I can use to dump them out as readable. Thanks. Raymond From: Knut Anders Hatlen [EMAIL PROTECTED] Reply-To: derby-dev@db.apache.org To: derby-dev@db.apache.org Subject: Re: Anyone knows how I can read the content of derby log control file and log file?? Date: Wed, 01 Feb 2006 21:05:48 +0100 Raymond Raymond [EMAIL PROTECTED] writes: Hi, is there anyone happens to know how I can read the content of derby log control and log files? I know they are binary files. I need to know the content of those files. Anyone can help me? The format of the log files is described here: http://db.apache.org/derby/papers/logformats.html All you need is a utility which gives you a hex dump and you're in action! :) -- Knut Anders _ Scan and help eliminate destructive viruses from your inbound and outbound e-mail and attachments. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
Re: [jira] Commented: (DERBY-874) Solidify JUnit test infrastructure
Thanks, David. I'd like to hold this issue open as a place to hang additional patches. Cheers, -Rick David Van Couvering (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-874?page=comments#action_12364864 ] David Van Couvering commented on DERBY-874: --- I committed this patch, revision 374146. I didn't resolve the issue because I wasn't sure if there was more work planned here. Rick, you can feel free to resolve/close if this is all you were planning on doing. Solidify JUnit test infrastructure -- Key: DERBY-874 URL: http://issues.apache.org/jira/browse/DERBY-874 Project: Derby Type: Improvement Components: Test Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: bug874.diff Build out the JUnit test infrastructure so that developers have a clear, standard model to follow.
Re: [jira] Commented: (DERBY-216) expand largeCodeGen.java test
I haven't followed the largeCodeGen test much, does it take an extremely long time or need a lot of memory? I am not sure what amount of time is the cutover from not being appropriate in the nightly suite. Otherwise we should just have add it somewhere else. I have run the large data test recently, and I think it took 6 hours and 17gb on a 1.8 laptop. So far I have not made it through a whole suite (basically I have only had overnight free on the machine and it has not finished). It would be nice if when this test succeeds if it dropped it's tables so you would not be left with 17gb in the test directory. If anyone has the resources to run the suite repeatedly, that would great. It now will catch some serious blob/clob regressions we have had in the past. Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-216?page=comments#action_12364516 ] Kathey Marsden commented on DERBY-216: -- I pulled the largeCodeGen test into the largeData suite. I suppressed the exception output for failed cases by default. It varies from run to run and jvm to jvm. There is a boolean PRINT_FAILURE_EXCEPTION that can be turned on for debugging. I am curious. Is there anyone out there that runs the largeData test from time to time? What are the system requirements? expand largeCodeGen.java test - Key: DERBY-216 URL: http://issues.apache.org/jira/browse/DERBY-216 Project: Derby Type: Sub-task Components: Test Reporter: Kathey Marsden the largeCodeGen test needs to be expanded to include other cases that genreate large amounts of byte code. For example: large in clause large insert statement that inserts many rows sql statements with large constant values It is best if the verious tests just use a variable that can be bumped higher and higher for testing and if individual cases are isolated. Possible approaches, think of ways to make sql statements really big that will take different code paths. Look in the code for instances of statementNumHitLimit and create cases that pass through that code. Those cases may pass but the hope is to get rid of these calls in favor of splitting the code in a centralized way, so add the tests to largeCodeGen even if they don't fail.
Re: [jira] Commented: (DERBY-216) expand largeCodeGen.java test
Mike Matrigali wrote: I haven't followed the largeCodeGen test much, does it take an extremely long time or need a lot of memory? I am not sure what amount of time is the cutover from not being appropriate in the nightly suite. Otherwise we should just have add it somewhere else. I have run the large data test recently, and I think it took 6 hours and 17gb on a 1.8 laptop. So far I have not made it through a whole suite (basically I have only had overnight free on the machine and it has not finished). It would be nice if when this test succeeds if it dropped it's tables so you would not be left with 17gb in the test directory. If anyone has the resources to run the suite repeatedly, that would great. It now will catch some serious blob/clob regressions we have had in the past. Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-216?page=comments#action_12364516 ] Kathey Marsden commented on DERBY-216: -- I pulled the largeCodeGen test into the largeData suite. I suppressed the exception output for failed cases by default. It varies from run to run and jvm to jvm. There is a boolean PRINT_FAILURE_EXCEPTION that can be turned on for debugging. I am curious. Is there anyone out there that runs the largeData test from time to time? What are the system requirements? expand largeCodeGen.java test - Key: DERBY-216 URL: http://issues.apache.org/jira/browse/DERBY-216 Project: Derby Type: Sub-task Components: Test Reporter: Kathey Marsden the largeCodeGen test needs to be expanded to include other cases that genreate large amounts of byte code. For example: large in clause large insert statement that inserts many rows sql statements with large constant values It is best if the verious tests just use a variable that can be bumped higher and higher for testing and if individual cases are isolated. Possible approaches, think of ways to make sql statements really big that will take different code paths. Look in the code for instances of statementNumHitLimit and create cases that pass through that code. Those cases may pass but the hope is to get rid of these calls in favor of splitting the code in a centralized way, so add the tests to largeCodeGen even if they don't fail. Hi Mike, I can run the test on one of my machines which is about 2G RAM and ~20GB disk space. Will let you know the results Thanks Manjula
Re: Anyone knows how I can read the content of derby log control file and log file??
There are really no provided utilities, and the current design does not envision user access to the log files. There is of course internal code that reads these log files. There are internal debugging routines that dumps some of the info but probably not going to help you. Note that what one finds in the logs is very low level and often will be hard to match up with a user's view, for instance an insert of a single row may be represented by many insert log records (to handle chained long rows and long columns). What are you trying to do? Raymond Raymond wrote: Hi, is there anyone happens to know how I can read the content of derby log control and log files? I know they are binary files. I need to know the content of those files. Anyone can help me? Thanks. Raymond _ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
Re: [jira] Commented: (DERBY-216) expand largeCodeGen.java test
Mike Matrigali wrote: I haven't followed the largeCodeGen test much, does it take an extremely long time or need a lot of memory? I am not sure what amount of time is the cutover from not being appropriate in the nightly suite. Otherwise we should just have add it somewhere else. It drags my latop with 1Gb of memory to a halt, due to large memory usage. I'm not sure how long it takes, at least 15mins, I usually kill it as I have already gathered what I need to know from the first portion of it. In fact it's the very last query that takes the time. It maybe that once I fix some of the code generation issues the test can be moved into the standard language suite. Dan.
Re: [jira] Commented: (DERBY-216) expand largeCodeGen.java test
Mike Matrigali wrote: I haven't followed the largeCodeGen test much, does it take an extremely long time or need a lot of memory? I am not sure what amount of time is the cutover from not being appropriate in the nightly suite. largeCodeGen takes about 5 minutes on my laptop, but I have heard reports that it has taken longer for others. I am not sure what the cutoff should be. Kathey
[jira] Resolved: (DERBY-862) Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-862?page=all ] David Van Couvering resolved DERBY-862: --- Fix Version: 10.2.0.0 Resolution: Fixed Committed, revision 374198 Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6 -- Key: DERBY-862 URL: http://issues.apache.org/jira/browse/DERBY-862 Project: Derby Type: Improvement Components: Javadoc Reporter: Rick Hillegas Assignee: Rick Hillegas Fix For: 10.2.0.0 Attachments: bug862.diff, bug862_rev2.diff, clean_javadoc.output, svn_status.bug862, svn_status_rev2.bug862 Right now, the derbydocs target produces a blizzard of warnings. In addition, javadoc fails under jdk1.6 because of illegal html in Property.java and ij.jj. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Discussion of how to map the recovery time into Xmb of log --Checkpoint issue
Long answer above, some comments inline below. I think runtime performance would be optimal in this case, runtime performance is in no way helped by having checkpoints - only either not affected or hindered. As has been noted checkpoints can cause drastic downward spikes in some disk bound applications, hopefully we will some changes into 10.2 to smooth those spikes down. But the reality is the more checkpoints on a system that is disk i/o bound the more the app is going to slow down, if you are not disk i/o bound then the checkpoints may have little affect. There are only 2 reasons for checkpoints: 1) decrease recovery time after a system crash. 2) make it possible to delete log file information (if you don't have rollforward recovery backups). Without a checkpoint derby must keep all log files, thus space needed in the log directory will always grow. The background writer thread should handle this, it should not consider this an extreme case. If there were no background writer and no checkpoints then the following would happen: 1) the page cache grows to whatever maximum size it has gotten to 2) requests for a new page then use clock to determine what page to throw out. 3) if the page picked to throw out is dirty, then it is first written to the OS with no sync requested. It is up to the OS whether this is handled async or not. Most modern OS's will make this be an async operation unless the OS cache is full and then it will turn into a wait for some i/o (maybe some other i/o to free OS resource). The downside is that a user select at this point may end up waiting on a synchronous write of some page. 4) if the page to throw out is not dirty, then it can just be thrown out without any possible I/O wait. 5) In both cases 3 and 4 the user thread of course has to wait on the I/O to read the page into the cache. Depending on the OS cache this may or may not be a real I/O. The job of the background writer is to make case 3 less likely, that's it. Note if you try to keep the whole cache clean then you may flood the I/O system unnecessarily if the app tends to write the same page over and over again, then it is better to leave it dirty in cache until needed. The clock tends to do this by throwing out less used pages vs. more used pages. Kristian Waagan wrote: Hi Mike, A question totally on the side of this discussion: Do you, or anyone else, have any opinion about how the runtime performance of Derby would be affected by not having checkpoints at all, say for a large database (around 20 GB) and 0.5 GB of page cache in a disk-bound application load? Is the Derby background-writer (and Clock.java) written/designed to handle such extreme cases without major performance degradation? Any information on the goal/function of the background-writer? What mechanisms would kick in when the page-cache is full and Derby needs slots for new pages? mechansism described above, it it particular to whether page to throw out is dirty vs. clean. There isn't really dependency on full. In a busy normal system the cache is always full and I don't think we do anything special about weights of dirty vs. clean. more work could be done in this area as has been discussed. I do know this is not a smart way to handle things, I'm just curious what people think about this! And I am not seeking answers about long recovery times and log disk space usage ;) Hey in my benchmark days with other db products, it was standard procedure to configure test system to either have no checkpoints or if required ONE checkpoint during the run. Derby is no different for this. I almost always try to separate the checkpoint affect from the performance throughput I am trying to measure (unless optimizing the checkpoint is what I am trying to measure). My guess is that default checkpoint interval is making WAY too many checkpoints for your throughput by default. -- Kristian Mike Matrigali wrote: I think this is the right path, though would need more details: o does boot mean first time boot for each db? o how to determine this machine o and the total time to run such a test. There are some very quick and useful tests that would be fine to add to the default system and do one time per databaseMeasureing how long to do a commit and how long to do a single database read from disk would be fine. Seems like just these 2 numbers could be used to come up with a very good default estimate of log recovery time per log record. Then as you propose the actual estimate can be improved by meauring real recovery time in the future. I am not convinced of the need for the bigger test, but if the default is not to run it automatically and it is your itch to have such a configuration option then I would not oppose. I do see great value in coming up with a very good default estimate of recovery time estimate based on outstanding number of log records. And I even
Re: [jira] Commented: (DERBY-216) expand largeCodeGen.java test
ok, looks like it belongs in that suite. I just wanted to make sure putting stuff in this suite is the exception. Even with this test it sounds like it would be nice if the 1st part was a standard test and the problem query was in this suite. Daniel John Debrunner wrote: Mike Matrigali wrote: I haven't followed the largeCodeGen test much, does it take an extremely long time or need a lot of memory? I am not sure what amount of time is the cutover from not being appropriate in the nightly suite. Otherwise we should just have add it somewhere else. It drags my latop with 1Gb of memory to a halt, due to large memory usage. I'm not sure how long it takes, at least 15mins, I usually kill it as I have already gathered what I need to know from the first portion of it. In fact it's the very last query that takes the time. It maybe that once I fix some of the code generation issues the test can be moved into the standard language suite. Dan.
Re: Code coverage results for trunk svn 366406
I am looking into setting up code coverage to run with j2me/cdc/foundation as well.-- Ramandeep Kaur[EMAIL PROTECTED]
Re: Code coverage results for trunk svn 366406
Ramandeep Kaur wrote: I am looking into setting up code coverage to run with j2me/cdc/foundation as well. Great, that will add a handful of classes into the coverage. Thanks for the other numbers. Dan.
[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
[ http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12364906 ] Sunitha Kambhampati commented on DERBY-856: --- Thanks Narayanan for addressing my earlier comments. I looked at the setCharacterStreamInternal_1.diff patch and the code changes look right to me. I have some minor comments. 1) In the below code, it would be good to update the comments to reflect the use of the intLength variable instead of the length. @@ -662,19 +669,19 @@ // usableLength is the length of the data from stream that can // be inserted which is min(colWidth,length) provided // length - colWidth has trailing blanks only -if (colWidth length) +if (colWidth intLength) usableLength = colWidth; Maybe also good to put in a comment in the code where we check for the value 2G-1 to indicate that the check is because currently Derby doesnt handle clob greater than 2G-1 chars. 2) There are some diffs that show up that are not related to this change, possibly because of change in indentation. It would be nice if this can be cleaned up. Also the indentation seems not quite right between the if(reader==null) block and the next block where you check for MAX_VALUE. Thanks for adding the testcase to test for the error message. I applied your patch and have started a run of the largedata/LobLimits.java test. I'll post here once it completes ok. Can you also mention if derbyall ran successfully or not. Sunitha. modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method -- Key: DERBY-856 URL: http://issues.apache.org/jira/browse/DERBY-856 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Environment: All Environments Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff A similar change to setBinaryStreamInternal is being handled as part of DERBY-599. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-887) Select statement returns wrong number of rows if you compare an integer column with a boolean expression in the where clause
Rick Hillegas wrote: I have trudged some way into this bug and would like to ask the community's advice. If we adopt the SQL spec's rules for casting to/from BOOLEAN, then we have to forbid the casting of BOOLEAN to integer types. Unfortunately, we have system procedures which do just this. Some of our system procedures cast the BOOLEAN columns in system tables to SMALLINT. In particular, SYSIBM.SQLGETTYPEINFO performs this cast when asked to retrieve ODBC type info. Thanks Rick for thinking about backward compatibility. For internal changes an adjustment like that seems ok but the *really* important thing is that we make sure that if metadata.properties is being changed that these calls still work on soft upgrade and particularly going back to an earlier version. I have always been an advocate of just dropping these all together when you go up or down in version, but got no traction with this idea when I mentioned it before. We have had some very unfortunate bugs in the past because of changes to the metadata file requiring time travel to fix. There may be an external impact to some users as well. It really bothers me to disable f functionality that users may be relying upon, but in this case I am really hoping it is not going to be a big problem, since that functionality looks pretty broken anyway and is not documented. You may wish to mention the change to derby-user and see if anyone has objections. It is important to document this risk in the release notes. I have on my list to start a Jira entry or Wiki to compile all of the changes that might affect existing users, but have not gotten to it yet. As for it being the tip of the iceburg, I don't know. Kathey
[jira] Commented: (DERBY-304) If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
[ http://issues.apache.org/jira/browse/DERBY-304?page=comments#action_12364909 ] Suresh Thalamati commented on DERBY-304: I tried the repro for this bug on my laptop with Windows XP , backup failed while copying the directories., with the error:ERROR XSRS5: Error copying file (during backup) from C:\maildb to c:\maildb\maildb. OS did not crash for me.. I think it is very rare any user will make mistake of giving backup path same as database home or one of its subdirectories. But I agree it might be nice to throw a better error message, but that might add some addtional restrictions or overhead. Some thought one possible way to fix this:: 1) Get absolute paths for both the database home directory and the backup directory then find if backup path is a subdirectory under the database directory. Problem with this approach is : a) Backup would always require read permission for user.dir when run under security manager. b) If there are symbolic links involved , this fix will not work. 2) Add a counter to keep track how many level of deep the directories are being created from the backup directory while doing the copy. If the directory level is deeper than the database normally has then throw error. This will work if user create backup under dbname/jar or dbname but if the given backup path is under log and seg0 then we can not identify this case becuase these directoties are not copied any more. 3) At the start of the backup create a uniue file using a UUID under the backup directory , then search for that file under the database home directory. If that file is not found then one can be sure backup path is not mapping to a subdirectiory of database directory. Delete the new file created and then proceed with the backup. I think this fix will work , but there is overhead of searching through all the files under the database directory for a error case. 4) Don't bother to fix it , No one is going hit this problem again :-) Any suggestions ? Thanks -suresht If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes! --- Key: DERBY-304 URL: http://issues.apache.org/jira/browse/DERBY-304 Project: Derby Type: Bug Components: Store Versions: 10.1.1.0 Environment: With JDK 142 on Windows XP Reporter: Manjula Kutty Priority: Minor If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes! Repro: CallableStatement cs = conn.prepareCall(CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)); cs.setString(1, c:/maildb); cs.setInt(2, 1); cs.execute(); cs.close(); result: C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\. Until windows can not show the path!!! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-304) If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
I think it is very rare any user will make mistake of giving backup path same as database home or one of its subdirectories. But I agree it might be nice to throw a better error message, but that might add some addtional restrictions or overhead. Some thought one possible way to fix this:: Here's an idea: Store a file with an obvious name into the backup path. Then search down from the database home and see if you find the file. If you do, there's an error. If you don't, things are fine. Either way, remove the file once you're done. I don't believe this requires any additional security permissions, because you already have to be able to write to the backup and read from the database in order to perform the backup. And I think this algorithm is pretty reliable in the face of symbolic links, etc., because you are working with a real file in a real location, not trying to interpret the paths abstractly. Just thought I'd throw this out there, in case it gave you some ideas of ways to work on the problem. thanks, bryan
[jira] Commented: (DERBY-304) If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
[ http://issues.apache.org/jira/browse/DERBY-304?page=comments#action_12364919 ] Rajesh Kartha commented on DERBY-304: - The (file.getCanonicalFile()) gives you the actual path for symbolic links. I am wondering if that could be used to compare the backup location and the actual database to be the same. Something like: f.getCanonicalFile().equals(f1.getCanonicalFile()) This will return true is'f1' is a symbolic link to 'f'. I know for sure this works on Linux. -Rajesh If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes! --- Key: DERBY-304 URL: http://issues.apache.org/jira/browse/DERBY-304 Project: Derby Type: Bug Components: Store Versions: 10.1.1.0 Environment: With JDK 142 on Windows XP Reporter: Manjula Kutty Priority: Minor If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes! Repro: CallableStatement cs = conn.prepareCall(CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)); cs.setString(1, c:/maildb); cs.setInt(2, 1); cs.execute(); cs.close(); result: C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\. Until windows can not show the path!!! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: paging Sunitha
Hi Sunitha, Thanks a ton for the comments and the review. I will make the changes and will post the patch again. thanx Narayanan Sunitha Kambhampati wrote On 02/01/06 23:04,: V.Narayanan wrote: Hi Sunitha, I have fixed Derby - 856 (patch related to setCharacterStreamInternal). I have modified it to use newSqlException like EmbedPreparedStatement. I have fixed the tests too. Can you please see if these changes concur with the fix for setBinaryStreamInternal (DERBY-599). Hi Narayanan, Thanks for posting the patch. Yes, I will look at it today. Sunitha.
[jira] Commented: (DERBY-891) derby_tests.policy file contains references to csinfo and db2j - should get cleaned up
[ http://issues.apache.org/jira/browse/DERBY-891?page=comments#action_12364930 ] Kathey Marsden commented on DERBY-891: -- I applied this patch and ran derbyall and it it passed, but I was not entirely sure about the permissions changes at this late hour. If another committer could take a look at the policy file changes and commit this I'd appreciate it as I will be out tomorrow. derby_tests.policy file contains references to csinfo and db2j - should get cleaned up -- Key: DERBY-891 URL: http://issues.apache.org/jira/browse/DERBY-891 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Myrna van Lunteren Assignee: Myrna van Lunteren Priority: Trivial Attachments: DERBY-891_013106.diff, DERBY-891_013106.stat The derby_tests.policy file uses references to csinfo and db2j. These are left-overs from pre-contribution and rename to apache and should get cleaned up. I suspect that the db2j references can simply be taken out, but that should get double-checked. The csinfo references are used in jvm.java. There referenced in the testing/README.htm. I propose to change the name of these properties as follows: csinfo.codejar - URL to the jar files when they are in the classpath change to derby.codejar csinfo.codeclasses - URL to the classes directory when it is in the classpath change to derby.codeclasses csinfo.codedir - File location of either csinfo.codejar or csinfo.codejar. the comment said : // Only required due to a BUG. Need to figure out which 'BUG' that is and document better change to derby.codedir csinfo.trustedhost change to derby.clienthost document: - specifies the clients ip address/hostName. csinfo.serverhost change to derby.serverhost document: -Host name or ip where network server is started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
[ http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12364931 ] Sunitha Kambhampati commented on DERBY-856: --- After applying the patch, I ran the entire largedata suite for embedded - which is largeDataTests suite and all tests passed (including the largedata/LobLimits.java). modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method -- Key: DERBY-856 URL: http://issues.apache.org/jira/browse/DERBY-856 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Environment: All Environments Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff A similar change to setBinaryStreamInternal is being handled as part of DERBY-599. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-891) derby_tests.policy file contains references to csinfo and db2j - should get cleaned up
[
http://issues.apache.org/jira/browse/DERBY-891?page=comments#action_12364932 ]
Daniel John Debrunner commented on DERBY-891:
-
Myrna and/or Kathey did you run the tests with jars or classes or both? On any
major policy file change I found it was best to run both combinations and in
some cases all four (sane/insane combined with jar/classes).
The only change I question is the removal of this permission from derbynet.jar
- permission java.net.SocketPermission ${csinfo.serverhost},
accept,connect;
I would have thought that was needed for remote testing, maybe the intention
was to add it back in a separate patch?
derby_tests.policy file contains references to csinfo and db2j - should get
cleaned up
--
Key: DERBY-891
URL: http://issues.apache.org/jira/browse/DERBY-891
Project: Derby
Type: Bug
Components: Test
Versions: 10.2.0.0
Reporter: Myrna van Lunteren
Assignee: Myrna van Lunteren
Priority: Trivial
Attachments: DERBY-891_013106.diff, DERBY-891_013106.stat
The derby_tests.policy file uses references to csinfo and db2j.
These are left-overs from pre-contribution and rename to apache and should
get cleaned up.
I suspect that the db2j references can simply be taken out, but that should
get double-checked.
The csinfo references are used in jvm.java. There referenced in the
testing/README.htm.
I propose to change the name of these properties as follows:
csinfo.codejar - URL to the jar files when they are in the classpath
change to derby.codejar
csinfo.codeclasses - URL to the classes directory when it is in the classpath
change to derby.codeclasses
csinfo.codedir - File location of either csinfo.codejar or csinfo.codejar.
the comment said : // Only required due to a BUG.
Need to figure out which 'BUG' that is and document better
change to derby.codedir
csinfo.trustedhost
change to derby.clienthost
document: - specifies the clients ip address/hostName.
csinfo.serverhost
change to derby.serverhost
document: -Host name or ip where network server is started.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-891) derby_tests.policy file contains references to csinfo and db2j - should get cleaned up
[ http://issues.apache.org/jira/browse/DERBY-891?page=comments#action_12364936 ] Kathey Marsden commented on DERBY-891: -- I only ran with the classes derby_tests.policy file contains references to csinfo and db2j - should get cleaned up -- Key: DERBY-891 URL: http://issues.apache.org/jira/browse/DERBY-891 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Myrna van Lunteren Assignee: Myrna van Lunteren Priority: Trivial Attachments: DERBY-891_013106.diff, DERBY-891_013106.stat The derby_tests.policy file uses references to csinfo and db2j. These are left-overs from pre-contribution and rename to apache and should get cleaned up. I suspect that the db2j references can simply be taken out, but that should get double-checked. The csinfo references are used in jvm.java. There referenced in the testing/README.htm. I propose to change the name of these properties as follows: csinfo.codejar - URL to the jar files when they are in the classpath change to derby.codejar csinfo.codeclasses - URL to the classes directory when it is in the classpath change to derby.codeclasses csinfo.codedir - File location of either csinfo.codejar or csinfo.codejar. the comment said : // Only required due to a BUG. Need to figure out which 'BUG' that is and document better change to derby.codedir csinfo.trustedhost change to derby.clienthost document: - specifies the clients ip address/hostName. csinfo.serverhost change to derby.serverhost document: -Host name or ip where network server is started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-911) Connection.setReadOnly is a no-op in Network Server. It works fine in embedded Derby.
Connection.setReadOnly is a no-op in Network Server. It works fine in embedded Derby. - Key: DERBY-911 URL: http://issues.apache.org/jira/browse/DERBY-911 Project: Derby Type: Bug Components: Network Client Versions: 10.2.0.0 Reporter: Mamta A. Satoor I have a simple test program which calls the Connection.setReadOnly(true) and then checks the readonly mode of that connection. In Network Server, the Connection.isReadOnly returns false even after Connection.setReadOnly(true). Same test program works fine when run in embedded mode, ie Connection.isReadOnly returns true after Connection.setReadOnly(true) is executed. Following is the test code snippet con = DriverManager.getConnection(jdbc:derby://localhost:1527/db7173;create=true, APP, APP); System.out.println(Check default connection.isReadOnly + con.isReadOnly()); con.setReadOnly(true); System.out.println(After connection.setReadOnly(true), what is isReadOnly + con.isReadOnly()); The output of this code in Network Server is as follows Check default connection.isReadOnly? false After connection.setReadOnly(true), what is isReadOnly? false I looked at org.apache.derby.client.am.Connection.setReadOnly method and noticed that the method simply doesn't do anything with the supplied value. In addition, it has following comment // This is a hint to the driver only, so this request is silently ignored. // PROTOCOL can only flow a set-read-only before the connection is established. In the same class, isReadOnly always returns false. This explains the current behavior of Network Server. But are we really limited by the DRDA protocol here as the comments in setReadOnly seem to imply? Anyone more familiar with DRDA specification and/or this code in Derby, can they share any information on DRDA spec and Derby behavior in this area? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
