[jira] Updated: (DERBY-326) Improve streaming of large objects for network server and client
[ http://issues.apache.org/jira/browse/DERBY-326?page=all ] Tomohito Nakayama updated DERBY-326: Attachment: DERBY-326_8.patch I upload DERBY-326_8.patch. --- Description of patch : * Remove processing to expand data from InputStream of blob/clob to memory before sending to client. * Implement layer B streaming at NetworkServer. * As written in this issue firstly, almost rewrite whole org.apache.derby.impl.drda.DDMWriter#writeScalarStream. Here , "almost" means that code was not wrote from scratch, but was wrote as reform. Remarkable point is as next : Original code was using variable "bytesToRead" to handle remaining amount of data sent and remaining roon in DSS segment . Now this variable "bytesToRead" was removed from. New code, instead, have variable "spareDssLength" to handle remaining room in DSS segment . * Add call to ensureLength in writeScalarStream expecting appropriate buffer size. * Move comment in java/drda/org/apache/derby/impl/drda/DDMWriter.java about client driver implementation to java/client/org/apache/derby/client/net/Request.java. * Modify org.apache.derby.impl.drda.EXTDTAInputStream to stream InputStream retrieved from ResultSet directly. * The source stream is read twice, first for seeing whether source stream is/is not empty, second for streaming it. * To keep reference to valid stream, EXTDTAInputStream have reference to resultset and blob/clob also. * Modify master file of result for blobclob4BLOB. * Now as same as result of embed driver, dead lock will be happen in clobTest92. * Different expected exception was happen in negative test in blobclob4BLOB. * Added asserting code. * Added negative test to kill streaming. * Place buffer before lob object was streamed out to client. * Added test to stream with the stream out buffer configuration. * Remove the code for handling byte[]. * Other improvements from DERBY-326_7.patch were as next. * Add comment to explain the test of OutBufferedStream.java * Set svn:eol-style property of newly added files as native. Testing : * Executed derbyall and found no error except found in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-397966.html > Improve streaming of large objects for network server and client > > > Key: DERBY-326 > URL: http://issues.apache.org/jira/browse/DERBY-326 > Project: Derby > Type: Improvement > Components: Network Client, Performance, Network Server > Reporter: Kathey Marsden > Assignee: Tomohito Nakayama > Attachments: ClobTest.zip, DERBY-326.patch, DERBY-326_2.patch, > DERBY-326_3.patch, DERBY-326_4.patch, DERBY-326_5.patch, > DERBY-326_5_indented.patch, DERBY-326_6.patch, DERBY-326_7.patch, > DERBY-326_8.patch, ReEncodedInputStream.java.modifiedForLongRun > > Currently the stream writing methods in network server and client require a > length parameter. This means that we have to get the length of the stream > before sending it. For example in network server in EXTDTAInputStream we have > to use getString and getbytes() instead of getCharacterStream and > getBinaryStream so that we can get the length. > SQLAM Level 7 provides for the enhanced LOB processing to allow streaming > without indicating the length, so, the writeScalarStream methods in > network server DDMWriter.java and network client Request.java can be changed > to not require a length. > Code inspection of these methods seems to indicate that while the length is > never written it is used heavily in generating the DSS. One strange thing is > that it appears on error, the stream is padded out to full length with zeros, > but an actual exception is never sent. Basically I think perhaps these > methods need to be rewritten from scratch based on the spec requirements for > lobs. > After the writeScalarStream methods have been changed, then EXTDAInputStream > can be changed to properly stream LOBS. See TODO tags in this file for more > info. I am guessing similar optimizations available in the client as well, > but am not sure where that code is. -- 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: [Db-derby Wiki] Update of "CodingProjects" by KatheyMarsden
Thanks, Kathey. You may already know this, but note that putting it here does not make it publicly available for students, you have to put it on the main SummerOfCode wiki referenced on the CodingProjects page. David Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification. The following page has been changed by KatheyMarsden: http://wiki.apache.org/db-derby/CodingProjects -- ||Add incremental support for JMX||David Van Couvering||Start with something simple like "is the server up or down" and grow from there.|| || || ||Automatic copying of log from the log directory to an archive|| || || || ||Implement an LRU-based cache manager to replace the current clock algorithm||Øystein Grøvlen?|| Derby currently uses a clock algorithm to determine which pages to replace in its page cache. We have indications that this algorithm is far from optimal for some type of loads. Many other database systems use variants of an LRU-based algorithm, i.e. the pages that are least recently used will be candidates for replacement. || ["LRUCache"] || + ||Network client Quality Improvements|| Kathey Marsden|| Derby introduced the network client JDBC driver with its 10.1.1.0 release. There is still important quality work pending to match the robustness of our embedded Driver. This is a great opportunity to learn about JDBC, XA, and DRDA protocol and become active in the Apache Derby development community.||NetworkClientQualityImprovements||??||
[jira] Reopened: (DERBY-395) Server-side "trace on" and "trace off" commands do not appear to be working correctly.
[ http://issues.apache.org/jira/browse/DERBY-395?page=all ] Bryan Pendleton reopened DERBY-395: --- Reopening to merge fix to 10.1 > Server-side "trace on" and "trace off" commands do not appear to be working > correctly. > -- > > Key: DERBY-395 > URL: http://issues.apache.org/jira/browse/DERBY-395 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.1.0, 10.0.2.2 > Environment: Running Derby Network Server with either JCC or Derby client. > Reporter: A B > Assignee: Bryan Pendleton > Fix For: 10.2.0.0 > Attachments: svn.status, svn_jan_27_2006.diff > > Documentation in the Server & Admin guide talks about a "derby.drda.traceAll" > system property and two trace commands available from the > NetworkServerControl API: "trace on" and "trace off". The "trace on" > command is supposed to turn tracing on for all server sessions, unless a > specific session number is passed in via the "-s" parameter. Similarly, the > "trace off" command is supposed to turn tracing off for all server sessions, > unless a specific session number is passed in via the "-s" parameter. > However, I've noticed the following behavior, which appears to be incorrect. > 1) if the server is started with derby.drda.traceAll=true, then subsequent > attempts to turn tracing off do not work. For example: > // Start the server with 'traceAll' set to true. > > java -Dderby.drda.traceAll=true org.apache.derby.drda.NetworkServerControl > > start > Server is ready to accept connections on port 1527. > // Try to turn tracing off. > > java org.apache.derby.drda.NetworkServerControl trace off > Trace turned off for all sessions. > But then, despite the message saying that trace was turned off, tracing is > still enabled for all connections thereafter: if I connect three more times, > I will see a 'ServerX.trace' file for each connection. > 2) If the server is started with derby.drda.traceAll=false, then attempts to > turn tracing on _only_ affect the connection that enables tracing; tracing > will NOT be done for any subsequent connections. For ex: > // Start the server with 'traceAll' set to false (which is also the default) > > java -Dderby.drda.traceAll=false org.apache.derby.drda.NetworkServerControl > > start > Server is ready to accept connections on port 1527. > // Turn tracing on. > > java org.apache.derby.drda.NetworkServerControl trace on > Trace turned on for all sessions. > Now I see a 'ServerX.trace' for the connection that was made to turn tracing > on. However, if I then connect three more times, I will _not_ see any > 'ServerX.trace' files for those connections. -- 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: Build warning
On 4/28/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote: Of course, we might not want to turn off compiler warnings. Actually, we already comple with --nowarn in both sane and insane mode to suppress the long compiler output and just get the number of warnings. Sounds like it might be an issue with the 1.6 javac compiler if we're passing in -nowarn and it still prints the long output for this particular warning. andrew
[jira] Commented: (DERBY-1229) sysinfo and sysinfo_withproperties.java fail with java.lang.RuntimePermission getProtectionDomain when db2jcc.jar is in same dir as the derby-jars
[ http://issues.apache.org/jira/browse/DERBY-1229?page=comments#action_12377114 ] Andrew McIntyre commented on DERBY-1229: One minor comment after rereading the patch, i'm pretty sure that the message SIF03.C was only used in the one location where you've replaced it with SIF03.D, so it might make sense to just reuse the old SIF03.C message id. > sysinfo and sysinfo_withproperties.java fail with java.lang.RuntimePermission > getProtectionDomain when db2jcc.jar is in same dir as the derby-jars > -- > > Key: DERBY-1229 > URL: http://issues.apache.org/jira/browse/DERBY-1229 > Project: Derby > Type: Test > Components: Security, Test, Tools > Versions: 10.2.0.0 > Environment: Solaris 10 x86 > Sun JDK > java version "1.5.0_06" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) > Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) > Reporter: Vemund Østgaard > Assignee: Bryan Pendleton > Priority: Minor > Attachments: derby-1229.diff, notes.html > > The problem I've been seeing is that if I run: > java -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest derbynet/sysinfo.java > in a configuration where my db2jcc.jar is located in the same directory as > all the other derby-jars, then the test fails with a diff caused by a > RuntimeException. If I change nothing else then moving that db2jcc.jar out of > that directory (and making the appropriate classpath change) then the test > succeeds. > The reason is that the test fails to get the permission for doing > getProtectionDomain().getCodeSource() on class com.ibm.db2.jcc.DB2Driver. > Below follows relevant output from my system that might be useful to debug > this: > --- > [EMAIL PROTECTED]:~/tmp/test> env |grep CLAS > CLASSPATH=/home/vo136787/derby/tmp/testbuild/lib/derby.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyTesting.jar:/home/vo136787/derby/tmp/testbuild/lib/derbytools.jar:/home/vo136787/derby/tmp/testbuild/lib/derbynet.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyclient.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyrun.jar:/home/vo136787/derby/tmp/testbuild/lib/junit.jar:/home/vo136787/derby/tmp/testbuild/lib/db2jcc.jar:/home/vo136787/derby/tmp/testbuild/lib/db2jcc_license_c.jar:/home/vo136787/derby/tmp/testbuild/lib/jakarta-oro-2.0.8.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_de_DE.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_es.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_fr.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_it.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_ja_JP.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_ko_KR.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_pt_BR.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_zh_CN.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_zh_TW.jar > [EMAIL PROTECTED]:~/tmp/test> java -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest derbynet/sysinfo.java > *** Start: sysinfo jdk1.5.0_06 DerbyNetClient 2006-04-19 13:00:33 *** > Initialize for framework: DerbyNetClient > java -Dderby.system.home=/home/vo136787/tmp/test/DerbyNetClient/sysinfo > -Djava.security.manager > -Djava.security.policy=/home/vo136787/tmp/test/derby_tests.policy > -DderbyTesting.codejar=file:/home/vo136787/derby/tmp/testbuild/lib/ > -DderbyTesting.codedir=/home/vo136787/derby/tmp/testbuild/lib > -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost > -DderbyTesting.codeclasses=file://unused/ > org.apache.derby.drda.NetworkServerControl start > -- SecurityManager not installed -- > Attempt to shutdown framework: DerbyNetClient > 14a15 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > 41a43 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > 69a72 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > Test Failed. > *** End: sysinfo jdk1.5.0_06 DerbyNetClient 2006-04-19 13:00:40 *** > [EMAIL PROTECTED]:~/tmp/test> java org.apache.derby.tools.sysinfo > -- Java Information -- > Java Version:1.5.0_06 > Java Vendor: Sun Microsystems Inc. > Java home: /usr/jdk/instances/jdk1.5.0/jre > Java classpath: > /home/vo136787/derby/tmp/testbuild/lib/derby.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyTesting.jar:/home/vo136787/derby/tmp/testbuild/lib/
[jira] Commented: (DERBY-1229) sysinfo and sysinfo_withproperties.java fail with java.lang.RuntimePermission getProtectionDomain when db2jcc.jar is in same dir as the derby-jars
[ http://issues.apache.org/jira/browse/DERBY-1229?page=comments#action_12377111 ] Andrew McIntyre commented on DERBY-1229: Bryan, thanks again for the detailed analysis. I agree that the correct thing to do in this case is to properly report the exception (and then sed it out), not add the getProtectionDomain permission to the test. I'd say go ahead and commit this. > sysinfo and sysinfo_withproperties.java fail with java.lang.RuntimePermission > getProtectionDomain when db2jcc.jar is in same dir as the derby-jars > -- > > Key: DERBY-1229 > URL: http://issues.apache.org/jira/browse/DERBY-1229 > Project: Derby > Type: Test > Components: Security, Test, Tools > Versions: 10.2.0.0 > Environment: Solaris 10 x86 > Sun JDK > java version "1.5.0_06" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) > Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) > Reporter: Vemund Østgaard > Assignee: Bryan Pendleton > Priority: Minor > Attachments: derby-1229.diff, notes.html > > The problem I've been seeing is that if I run: > java -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest derbynet/sysinfo.java > in a configuration where my db2jcc.jar is located in the same directory as > all the other derby-jars, then the test fails with a diff caused by a > RuntimeException. If I change nothing else then moving that db2jcc.jar out of > that directory (and making the appropriate classpath change) then the test > succeeds. > The reason is that the test fails to get the permission for doing > getProtectionDomain().getCodeSource() on class com.ibm.db2.jcc.DB2Driver. > Below follows relevant output from my system that might be useful to debug > this: > --- > [EMAIL PROTECTED]:~/tmp/test> env |grep CLAS > CLASSPATH=/home/vo136787/derby/tmp/testbuild/lib/derby.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyTesting.jar:/home/vo136787/derby/tmp/testbuild/lib/derbytools.jar:/home/vo136787/derby/tmp/testbuild/lib/derbynet.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyclient.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyrun.jar:/home/vo136787/derby/tmp/testbuild/lib/junit.jar:/home/vo136787/derby/tmp/testbuild/lib/db2jcc.jar:/home/vo136787/derby/tmp/testbuild/lib/db2jcc_license_c.jar:/home/vo136787/derby/tmp/testbuild/lib/jakarta-oro-2.0.8.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_de_DE.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_es.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_fr.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_it.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_ja_JP.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_ko_KR.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_pt_BR.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_zh_CN.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_zh_TW.jar > [EMAIL PROTECTED]:~/tmp/test> java -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest derbynet/sysinfo.java > *** Start: sysinfo jdk1.5.0_06 DerbyNetClient 2006-04-19 13:00:33 *** > Initialize for framework: DerbyNetClient > java -Dderby.system.home=/home/vo136787/tmp/test/DerbyNetClient/sysinfo > -Djava.security.manager > -Djava.security.policy=/home/vo136787/tmp/test/derby_tests.policy > -DderbyTesting.codejar=file:/home/vo136787/derby/tmp/testbuild/lib/ > -DderbyTesting.codedir=/home/vo136787/derby/tmp/testbuild/lib > -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost > -DderbyTesting.codeclasses=file://unused/ > org.apache.derby.drda.NetworkServerControl start > -- SecurityManager not installed -- > Attempt to shutdown framework: DerbyNetClient > 14a15 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > 41a43 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > 69a72 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > Test Failed. > *** End: sysinfo jdk1.5.0_06 DerbyNetClient 2006-04-19 13:00:40 *** > [EMAIL PROTECTED]:~/tmp/test> java org.apache.derby.tools.sysinfo > -- Java Information -- > Java Version:1.5.0_06 > Java Vendor: Sun Microsystems Inc. > Java home: /usr/jdk/instances/jdk1.5.0/jre > Java classpath: > /home/vo136787/derby/tmp/testbuild/lib/derby.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyTesting.jar:/home/vo136787/d
[jira] Updated: (DERBY-892) add mechanism for specifying policy file for individual function tests
[ http://issues.apache.org/jira/browse/DERBY-892?page=all ]
Andrew McIntyre updated DERBY-892:
--
Attachment: derby-892_pre.diff
Attached is a patch which updates derby_tests.policy if there is a
{test}.policy in the functionTests/tests dir for this test. Included is a
sample policy for derbynet/sysinfo.java. The patch is not ready to be
committed, but I thought I would put it out there for others to review.
However, I can't seem to get derbynet/sysinfo.java to fail (or pass) in any of
the ways that I'm expecting at the moment and its driving me slightly insane.
For instance, I can't get the test to fail as expected by removing the
permissions noted in DERBY-622 (along with those added by Rick for 955), the
circumstances mentioned in DERBY-1129, and the locale jar files output fails to
appear even though I've granted the permissions noted in DERBY-622 which
allowed the test to pass before. Maybe the jvm on Mac OS X is just not
cooperating. I'll try it on Windows later.
> add mechanism for specifying policy file for individual function tests
> --
>
> Key: DERBY-892
> URL: http://issues.apache.org/jira/browse/DERBY-892
> Project: Derby
> Type: Bug
> Components: Test
> Versions: 10.2.0.0
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: derby-892_pre.diff
>
> It would be nice to be able to specify a test-specific policy file.
> This should get handled similar to existing properties, i.e. get specified in
> a test_app.properties file (or, for a suite, in the suite.properties file).
> The file should then be copied into the correct place.
> Note, that the 'old' functionTests harness (as opposed to junit tests)
> includes a check for a property called 'serverPolicyFile' (in
> harness/jvm.java). The name is a left over from when the policy file was only
> used for/by network server, and should be renamed - derbyTestPolicyFile, for
> instance. It is not used anywhere at present, and not specific to network
> server. It would be nice if this could be expanded, or, if not used, removed.
> The default policy file used is the derby_tests.policy file under
> functionTests/util.
> Also, currently, the property can only be used with RunTest - for further
> traction, it should probably get passed on through RunSuite/RunList.
> Once confirmed to be working, the property should get documented in
> /java/testing/README.htm.
--
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
Derbyall runtimes, 10.1, and Security Manager
I had occasion recently to be porting a few bug fixes from the trunk to 10.1, and so I happened to be running derbyall on 10.1. I don't really want to re-ignite the debate over derbyall runtime, but the difference in duration between a derbyall run on the trunk, and a derbyall run on 10.1, was really remarkable. Then, as part of working on DERBY-1229, I happened to be running a lot of interactive experiments both with and without the security manager. And I noticed that when I ran Derby code with the security manager enabled, the runtime speed was noticeably slower. So I'm wondering, is it possible that a significant portion of the derbyall slowdown in the trunk is due to running with the security manager enabled, and, if so, is there anything we can do with that knowledge? thanks, bryan
[jira] Updated: (DERBY-1229) sysinfo and sysinfo_withproperties.java fail with java.lang.RuntimePermission getProtectionDomain when db2jcc.jar is in same dir as the derby-jars
[ http://issues.apache.org/jira/browse/DERBY-1229?page=all ] Bryan Pendleton updated DERBY-1229: --- Attachment: notes.html derby-1229.diff Attached is a proposed patch (derby-1229.diff) and a discussion of the patch (notes.html). Please read the notes.html (it's a quick read), and let me know what you think. If it sounds reasonable, I'd love to hear from a few reviewers whether this patch works successfully in their environment, since we all seem to have radically different classpath configurations. thanks, bryan > sysinfo and sysinfo_withproperties.java fail with java.lang.RuntimePermission > getProtectionDomain when db2jcc.jar is in same dir as the derby-jars > -- > > Key: DERBY-1229 > URL: http://issues.apache.org/jira/browse/DERBY-1229 > Project: Derby > Type: Test > Components: Security, Test, Tools > Versions: 10.2.0.0 > Environment: Solaris 10 x86 > Sun JDK > java version "1.5.0_06" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) > Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) > Reporter: Vemund Østgaard > Assignee: Bryan Pendleton > Priority: Minor > Attachments: derby-1229.diff, notes.html > > The problem I've been seeing is that if I run: > java -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest derbynet/sysinfo.java > in a configuration where my db2jcc.jar is located in the same directory as > all the other derby-jars, then the test fails with a diff caused by a > RuntimeException. If I change nothing else then moving that db2jcc.jar out of > that directory (and making the appropriate classpath change) then the test > succeeds. > The reason is that the test fails to get the permission for doing > getProtectionDomain().getCodeSource() on class com.ibm.db2.jcc.DB2Driver. > Below follows relevant output from my system that might be useful to debug > this: > --- > [EMAIL PROTECTED]:~/tmp/test> env |grep CLAS > CLASSPATH=/home/vo136787/derby/tmp/testbuild/lib/derby.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyTesting.jar:/home/vo136787/derby/tmp/testbuild/lib/derbytools.jar:/home/vo136787/derby/tmp/testbuild/lib/derbynet.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyclient.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyrun.jar:/home/vo136787/derby/tmp/testbuild/lib/junit.jar:/home/vo136787/derby/tmp/testbuild/lib/db2jcc.jar:/home/vo136787/derby/tmp/testbuild/lib/db2jcc_license_c.jar:/home/vo136787/derby/tmp/testbuild/lib/jakarta-oro-2.0.8.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_de_DE.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_es.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_fr.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_it.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_ja_JP.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_ko_KR.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_pt_BR.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_zh_CN.jar:/home/vo136787/derby/tmp/testbuild/lib/derbyLocale_zh_TW.jar > [EMAIL PROTECTED]:~/tmp/test> java -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest derbynet/sysinfo.java > *** Start: sysinfo jdk1.5.0_06 DerbyNetClient 2006-04-19 13:00:33 *** > Initialize for framework: DerbyNetClient > java -Dderby.system.home=/home/vo136787/tmp/test/DerbyNetClient/sysinfo > -Djava.security.manager > -Djava.security.policy=/home/vo136787/tmp/test/derby_tests.policy > -DderbyTesting.codejar=file:/home/vo136787/derby/tmp/testbuild/lib/ > -DderbyTesting.codedir=/home/vo136787/derby/tmp/testbuild/lib > -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost > -DderbyTesting.codeclasses=file://unused/ > org.apache.derby.drda.NetworkServerControl start > -- SecurityManager not installed -- > Attempt to shutdown framework: DerbyNetClient > 14a15 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > 41a43 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > 69a72 > > [Unable to access Protection Domain or Code Source for class class > > com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission > > getProtectionDomain)] 2.4 - (17) > Test Failed. > *** End: sysinfo jdk1.5.0_06 DerbyNetClient 2006-04-19 13:00:40 *** > [EMAIL PROTECTED]:~/tmp/test> java org.apache.derby.tools.sysinfo > -- Java Information -- > Java Version:1.5.0_06 > Java Vendor: Sun Microsystems Inc. > Java home: /usr/jdk
[jira] Resolved: (DERBY-1270) pt_BR translation DTD directory (../dtd/ -> ../../dtd/)
[ http://issues.apache.org/jira/browse/DERBY-1270?page=all ]
Andrew McIntyre resolved DERBY-1270:
Fix Version: 10.2.0.0
(was: 10.1.2.3)
Resolution: Fixed
Derby Info: (was: [Patch Available])
I noticed this yesterday when looking at the DTD files. Thanks for fixing this
Halley. Committed revision 398181.
> pt_BR translation DTD directory (../dtd/ -> ../../dtd/)
> ---
>
> Key: DERBY-1270
> URL: http://issues.apache.org/jira/browse/DERBY-1270
> Project: Derby
> Type: Bug
> Components: Documentation
> Versions: 10.1.2.3
> Environment: DITA-sourced documentation
> Reporter: Halley Pacheco de Oliveira
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: pt_BR_dtd.diff, pt_BR_dtd.diff.html
>
> Getting Started with Derby and Derby Reference Manual were translated into
> Brazilian Portuguese overwriting the original files written in English in the
> original directories created by svn, so the DTDs files could be found in
> directory "../dtd/".
> Once the directories for the translated files were created under directory
> "src/pt_BR/", and not directly under directory "src/", the DTDs files for the
> translated files are no more in directory "../dtd/", they are now in
> directory "../../dtd/".
> The diff file I'm sending substitutes "../dtd/" by "../../dtd/" in all files
> under pt_BR directory, as shown below:
> - "../dtd/reference.dtd">
> + "../../dtd/reference.dtd">
> The script used to modify the files was:
> --
> mkdir sed
> find . -maxdepth 1 -type f -exec sh -c "cat {} | sed -e
> 's/\"..\/dtd\//\"..\/..\/dtd\//g' > sed/{}" \;
> mv -f sed/* .
> rmdir sed
> --
> This script was executed in directories "src/pt_BR/ref/" and
> "src/pt_BR/getstart/".
> It doesn't affect doc building, but is important when editing these files
> using jEdit.
--
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-1269) Description of place where DITA-OT1.1.2.1_bin-ASL.zip is placed seems to be worng.
[ http://issues.apache.org/jira/browse/DERBY-1269?page=comments#action_12377093 ] Andrew McIntyre commented on DERBY-1269: There seems to have been some confusion when writing the page as to whether the checkout was done to a directory called trunk: svn checkout https://svn.apache.org/repos/asf/db/derby/docs/trunk/ or to the local directory (.): svn checkout https://svn.apache.org/repos/asf/db/derby/docs/trunk/ . Since most of the document refers to the first way, I suggest that we change the incorrect references to reference %DOC_ROOT%/trunk/ as suggested. The following wording should also be changed: 2. Extract the DITA source files, Apache FOP, and the build.xml file from svn using the command described above. We will call the extraction home directory %DOC_ROOT%/trunk. > Description of place where DITA-OT1.1.2.1_bin-ASL.zip is placed seems to be > worng. > -- > > Key: DERBY-1269 > URL: http://issues.apache.org/jira/browse/DERBY-1269 > Project: Derby > Type: Bug > Components: Web Site > Environment: [EMAIL PROTECTED]:~$ cat /proc/version > Linux version 2.6.12-1-386 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050917 > (prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 12:41:08 JST 2005 > Reporter: Tomohito Nakayama > > Description of next url says that DITA-OT1.1.2.1_bin-ASL.zip should be placed > to "%DOC_ROOT%/lib" > http://db.apache.org/derby/manuals/dita.html#Setting%2Bup%2Byour%2Benvironment > However,I could not run the command "ant html" in this configuration. > Error message tells that expanding DITA-OT1.1.2.1_bin-ASL.zip was failed. > It seems that "%DOC_ROOT%/lib" is not correct and "%DOC_ROOT%/trunk/lib" is > correct place. > In that configration, I could run "ant html". -- 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-1235) Move isPoolable() and setPoolable() from PreparedStatement to Statement
[ http://issues.apache.org/jira/browse/DERBY-1235?page=all ] Dyre Tjeldvoll updated DERBY-1235: -- Derby Info: [Patch Available] > Move isPoolable() and setPoolable() from PreparedStatement to Statement > --- > > Key: DERBY-1235 > URL: http://issues.apache.org/jira/browse/DERBY-1235 > Project: Derby > Type: Improvement > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Dyre Tjeldvoll > Fix For: 10.2.0.0 > Attachments: derby-1235.v1.diff, derby-1235.v1.stat, derby-1235.v2.diff, > derby-1235.v2.stat, derby-1235.v3.diff, derby-1235.v3.stat, > derbyall_report.v1.txt, derbyall_report.v3.txt > > An upcoming release of jdk1.6 will move isPoolable() and setPoolable() from > PreparedStatement to Statement. We should conform. -- 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-1235) Move isPoolable() and setPoolable() from PreparedStatement to Statement
[ http://issues.apache.org/jira/browse/DERBY-1235?page=all ] Dyre Tjeldvoll updated DERBY-1235: -- Attachment: derby-1235.v3.diff derby-1235.v3.stat derbyall_report.v3.txt The failure seen by Knut Anders was caused by not initializing the isPoolable variable in one of the PreparedStatement constructors on the client side. Since then, I have also learned that BrokeredXXXStatements40 need to implement (override) the xPoolable methods. I'm attaching a third patch (v3) that addresses the above issues, and also adds a new junit-test to test these methods for BrokeredXXXStatements (jdbc4/XA40Tests.java). Ran derbyall and jdbc4 in embedded and DerbyNetClient successfully. Please review. > Move isPoolable() and setPoolable() from PreparedStatement to Statement > --- > > Key: DERBY-1235 > URL: http://issues.apache.org/jira/browse/DERBY-1235 > Project: Derby > Type: Improvement > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Dyre Tjeldvoll > Fix For: 10.2.0.0 > Attachments: derby-1235.v1.diff, derby-1235.v1.stat, derby-1235.v2.diff, > derby-1235.v2.stat, derby-1235.v3.diff, derby-1235.v3.stat, > derbyall_report.v1.txt, derbyall_report.v3.txt > > An upcoming release of jdk1.6 will move isPoolable() and setPoolable() from > PreparedStatement to Statement. We should conform. -- 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-1270) pt_BR translation DTD directory (../dtd/ -> ../../dtd/)
[ http://issues.apache.org/jira/browse/DERBY-1270?page=all ]
Halley Pacheco de Oliveira updated DERBY-1270:
--
Attachment: pt_BR_dtd.diff
pt_BR_dtd.diff.html
diff file and HTMLized diff file to substitute "../dtd/" by "../../dtd/"
> pt_BR translation DTD directory (../dtd/ -> ../../dtd/)
> ---
>
> Key: DERBY-1270
> URL: http://issues.apache.org/jira/browse/DERBY-1270
> Project: Derby
> Type: Bug
> Components: Documentation
> Versions: 10.1.2.3
> Environment: DITA-sourced documentation
> Reporter: Halley Pacheco de Oliveira
> Priority: Minor
> Fix For: 10.1.2.3
> Attachments: pt_BR_dtd.diff, pt_BR_dtd.diff.html
>
> Getting Started with Derby and Derby Reference Manual were translated into
> Brazilian Portuguese overwriting the original files written in English in the
> original directories created by svn, so the DTDs files could be found in
> directory "../dtd/".
> Once the directories for the translated files were created under directory
> "src/pt_BR/", and not directly under directory "src/", the DTDs files for the
> translated files are no more in directory "../dtd/", they are now in
> directory "../../dtd/".
> The diff file I'm sending substitutes "../dtd/" by "../../dtd/" in all files
> under pt_BR directory, as shown below:
> - "../dtd/reference.dtd">
> + "../../dtd/reference.dtd">
> The script used to modify the files was:
> --
> mkdir sed
> find . -maxdepth 1 -type f -exec sh -c "cat {} | sed -e
> 's/\"..\/dtd\//\"..\/..\/dtd\//g' > sed/{}" \;
> mv -f sed/* .
> rmdir sed
> --
> This script was executed in directories "src/pt_BR/ref/" and
> "src/pt_BR/getstart/".
> It doesn't affect doc building, but is important when editing these files
> using jEdit.
--
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-1270) pt_BR translation DTD directory (../dtd/ -> ../../dtd/)
pt_BR translation DTD directory (../dtd/ -> ../../dtd/)
---
Key: DERBY-1270
URL: http://issues.apache.org/jira/browse/DERBY-1270
Project: Derby
Type: Bug
Components: Documentation
Versions: 10.1.2.3
Environment: DITA-sourced documentation
Reporter: Halley Pacheco de Oliveira
Priority: Minor
Fix For: 10.1.2.3
Getting Started with Derby and Derby Reference Manual were translated into
Brazilian Portuguese overwriting the original files written in English in the
original directories created by svn, so the DTDs files could be found in
directory "../dtd/".
Once the directories for the translated files were created under directory
"src/pt_BR/", and not directly under directory "src/", the DTDs files for the
translated files are no more in directory "../dtd/", they are now in directory
"../../dtd/".
The diff file I'm sending substitutes "../dtd/" by "../../dtd/" in all files
under pt_BR directory, as shown below:
- "../dtd/reference.dtd">
+ "../../dtd/reference.dtd">
The script used to modify the files was:
--
mkdir sed
find . -maxdepth 1 -type f -exec sh -c "cat {} | sed -e
's/\"..\/dtd\//\"..\/..\/dtd\//g' > sed/{}" \;
mv -f sed/* .
rmdir sed
--
This script was executed in directories "src/pt_BR/ref/" and
"src/pt_BR/getstart/".
It doesn't affect doc building, but is important when editing these files using
jEdit.
--
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
Regression Test Failure! - Derby 397966 - Sun DBTG
[Auto-generated mail] *Derby* 397966/2006-04-28 19:46:06 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 130668538 0 104.97% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-397966.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/397966.html *Jvm: 1.5* 4654650 1 108.15% CYGWIN_NT-5.1_i686-unknown 1654653 1 112.66% CYGWIN_NT-5.2_i686-unknown 0654654 1 114.76% Linux-2.6.14-1.1644_FC4_i686-i686 0654654 199.64% Linux-2.6.9-34.ELsmp_x86_64-x86_64 0654654 1 106.15% SunOS-5.10_i86pc-i386 0654654 1 133.35% SunOS-5.10_sun4u-sparc NA NA NANA SunOS-5.11_i86pc-i386 0654654 1 107.29% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-397966.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/397966.html *Jvm: 1.4* 5648643 3 102.61% CYGWIN_NT-5.1_i686-unknown 1648647 3 112.54% Linux-2.6.14-1.1644_FC4_i686-i686 0648648 399.08% Linux-2.6.9-34.ELsmp_x86_64-x86_64 0648648 3 110.40% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-397966.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/397966.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/397966.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client
[ http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12377069 ] Tomohito Nakayama commented on DERBY-326: - Working in DERBY-1268, I found that svn:eol-style was not native in next files which was added in this task. added files: java/drda/org/apache/derby/impl/drda/ReEncodedInputStream.java java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/SuicideOfStreaming.out java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/SuicideOfStreaming.out java/testing/org/apache/derbyTesting/functionTests/master/OutBufferedStream.out java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/OutBufferedStream_app.properties java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/OutBufferedStream.java java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SuicideOfStreaming_app.properties java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SuicideOfStreaming.java java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/SwitchablePrintStream.java .subversion/config was not configured in my environment ... I set attributes to those files in next patch. > Improve streaming of large objects for network server and client > > > Key: DERBY-326 > URL: http://issues.apache.org/jira/browse/DERBY-326 > Project: Derby > Type: Improvement > Components: Network Client, Performance, Network Server > Reporter: Kathey Marsden > Assignee: Tomohito Nakayama > Attachments: ClobTest.zip, DERBY-326.patch, DERBY-326_2.patch, > DERBY-326_3.patch, DERBY-326_4.patch, DERBY-326_5.patch, > DERBY-326_5_indented.patch, DERBY-326_6.patch, DERBY-326_7.patch, > ReEncodedInputStream.java.modifiedForLongRun > > Currently the stream writing methods in network server and client require a > length parameter. This means that we have to get the length of the stream > before sending it. For example in network server in EXTDTAInputStream we have > to use getString and getbytes() instead of getCharacterStream and > getBinaryStream so that we can get the length. > SQLAM Level 7 provides for the enhanced LOB processing to allow streaming > without indicating the length, so, the writeScalarStream methods in > network server DDMWriter.java and network client Request.java can be changed > to not require a length. > Code inspection of these methods seems to indicate that while the length is > never written it is used heavily in generating the DSS. One strange thing is > that it appears on error, the stream is padded out to full length with zeros, > but an actual exception is never sent. Basically I think perhaps these > methods need to be rewritten from scratch based on the spec requirements for > lobs. > After the writeScalarStream methods have been changed, then EXTDAInputStream > can be changed to properly stream LOBS. See TODO tags in this file for more > info. I am guessing similar optimizations available in the client as well, > but am not sure where that code is. -- 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-1269) Description of place where DITA-OT1.1.2.1_bin-ASL.zip is placed seems to be worng.
[ http://issues.apache.org/jira/browse/DERBY-1269?page=comments#action_12377068 ] Tomohito Nakayama commented on DERBY-1269: -- Similar problem seems to exist in next url. http://db.apache.org/derby/manuals/dita.html#Creating%2Boutput Output was generated not to "%DOC_ROOT%/out/" but to "%DOC_ROOT%/trunk/out/" > Description of place where DITA-OT1.1.2.1_bin-ASL.zip is placed seems to be > worng. > -- > > Key: DERBY-1269 > URL: http://issues.apache.org/jira/browse/DERBY-1269 > Project: Derby > Type: Bug > Components: Web Site > Environment: [EMAIL PROTECTED]:~$ cat /proc/version > Linux version 2.6.12-1-386 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050917 > (prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 12:41:08 JST 2005 > Reporter: Tomohito Nakayama > > Description of next url says that DITA-OT1.1.2.1_bin-ASL.zip should be placed > to "%DOC_ROOT%/lib" > http://db.apache.org/derby/manuals/dita.html#Setting%2Bup%2Byour%2Benvironment > However,I could not run the command "ant html" in this configuration. > Error message tells that expanding DITA-OT1.1.2.1_bin-ASL.zip was failed. > It seems that "%DOC_ROOT%/lib" is not correct and "%DOC_ROOT%/trunk/lib" is > correct place. > In that configration, I could run "ant html". -- 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-1269) Description of place where DITA-OT1.1.2.1_bin-ASL.zip is placed seems to be worng.
Description of place where DITA-OT1.1.2.1_bin-ASL.zip is placed seems to be worng. -- Key: DERBY-1269 URL: http://issues.apache.org/jira/browse/DERBY-1269 Project: Derby Type: Bug Components: Web Site Environment: [EMAIL PROTECTED]:~$ cat /proc/version Linux version 2.6.12-1-386 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050917 (prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 12:41:08 JST 2005 Reporter: Tomohito Nakayama Description of next url says that DITA-OT1.1.2.1_bin-ASL.zip should be placed to "%DOC_ROOT%/lib" http://db.apache.org/derby/manuals/dita.html#Setting%2Bup%2Byour%2Benvironment However,I could not run the command "ant html" in this configuration. Error message tells that expanding DITA-OT1.1.2.1_bin-ASL.zip was failed. It seems that "%DOC_ROOT%/lib" is not correct and "%DOC_ROOT%/trunk/lib" is correct place. In that configration, I could run "ant html". -- 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
