You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dag H. Wanvik" <Da...@Sun.COM> on 2005/05/23 17:51:56 UTC
[PATCH] (DERBY-205; 2nd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Hi,
I have uploaded a second patch for derby-205 to clean up a
redundancy as per Kathey's suggestion. I have done the following:
- Removed the (redundant) reading of these stream name properties from
NetworkServerControlImpl.java:
derby.stream.error.file
derby.stream.error.method
derby.stream.error.field
- Modified DRDAConnThread.java to get the stream name via
Monitor.getStream().getName (a new method). DRDAConnThread was the
sole client and reason for the redundancy Kathey spotted.
- Augmented HeaderPrintWriter interface with a new method, getName.
- Augmented BasicHeaderPrintWriter to hold the stream name of the
error log.
- Moved hard coded constants for the stream name attributes from
SingleStream.java to the Property interface and documented them there.
- Removed the errorLogLocation field and the getErrorLogLocation from
NetworkServerControlImpl.java
- Cleaned up some Javadoc for the items I touched.
I have run derbyall with JDK1.4.2 on Solaris/x86. derbyall runs with
errors, but the same errors are present on a clean checkout as well
(parameterMapping, backupRestore1). Hope somebody cleans that up...
I could not see that the tests tested either the ".method" or the
".field" propeties in any way, and thus not the precedence relation
between them either. It could be a good idea to add tests for that,
perhaps.
I also built the Javadoc to check my doc changes.
Dag
----------------------------------------205b.stat
M java/engine/org/apache/derby/impl/services/stream/BasicHeaderPrintWriter.java
M java/engine/org/apache/derby/impl/services/stream/SingleStream.java
M java/engine/org/apache/derby/iapi/services/stream/HeaderPrintWriter.java
M java/engine/org/apache/derby/iapi/reference/Property.java
M java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java
M java/drda/org/apache/derby/impl/drda/DRDAConnThread.java
Re: [PATCH] (DERBY-205; 2nd patch) org.apache.derby.impl.drda.DB2jServerImpl
to NetworkServerControlImpl
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dag H. Wanvik wrote:
>I uploaded a new patch for 205 + comments, now including a test,
>otherwise unchanged.
>
Yes, I will take a look at it and check in if I see no issues. Thank you
so much for cleaning up and adding tests for the
derby.stream.error.* methods. I think that these are the only way to
get a proper error log with multiple class loaders and will become more
and more important. Since, they say that software without automated
tests does not exist, I am glad that these properties will finally
really exist #:)
Kathey
Re: [PATCH] (DERBY-205; 3rd patch) org.apache.derby.impl.drda.DB2jServerImpl
to NetworkServerControlImpl
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dag H. Wanvik wrote:
>Hi Kathey,
>
>I just uploaded a patch (205c.{stat,diff}) to fix the problem you saw:
>
>
>
Hi Dag.
Running the test with the new patch, I saw:
*** Start: errorStream jdk1.4.2_07 2005-06-03 10:16:44 ***
30a31
> shutdown ok: XJ015:Derby system shutdown.
38d38
< shutdown ok: XJ015:Derby system shutdown.
Test Failed.
*** End: errorStream jdk1.4.2_07 2005-06-03 10:18:21 ***
I just updated the canon and hope it is just a side effect of all the
message changes as of late rather than waiting fo rth earth to turn
again so we can talk about it.
Can you try it on Linux again and keep an eye out for any trouble in the
nightlies?
Also I did notice if you run the test twice without cleaning up first
you get a diff which might be confusing to folks even though you are
supposed to clean up before running the tests. Might be good to have
the test cleanup whatever is necessary to have it pass on a second run.
Sending
java\testing\org\apache\derbyTesting\functionTests\master\errorStream.out
Sending
java\testing\org\apache\derbyTesting\functionTests\suites\derbylang.runall
Sending
java\testing\org\apache\derbyTesting\functionTests\tests\lang\errorStream_sed.properties
Transmitting file data ...
Committed revision 179840.
$
[PATCH] (DERBY-205; 3rd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi Kathey,
I just uploaded a patch (205c.{stat,diff}) to fix the problem you saw:
This patch is a follow-up to the new test (lang/errorStream.java)
introduced by derby-205 (second patch). Its sed script was deficient,
so the test was not initially included in the suites. This patch:
- eliminates a Unix dependency in its canon file
- eliminates a locale dependent string in the canon file
- adds the test to the derbylang suite
I have run the test stand-alone (on Solaris and Windows), and as part
of the suite derbylang (on Solaris).
Dag
Re: [PATCH] (DERBY-205; 2nd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi Kathey,
>>>>> "KM" == Kathey Marsden <km...@sbcglobal.net> wrote:
KM> Thanks for working on the test. I'll pick up Derby-213.
KM> Please do let me know if you are looking for interesting network
KM> server tasks when you are done with your test.
I uploaded a new patch for 205 + comments, now including a test,
otherwise unchanged. Could you review this for me, please? I guess
since you reviewed the first version of this patch, it would make
sense if you took it on? ;-)
Thanks,
Dag
Re: [PATCH] (DERBY-205; 2nd patch) org.apache.derby.impl.drda.DB2jServerImpl
to NetworkServerControlImpl
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dag H. Wanvik wrote:
>if I
>want to test several possibilities, it would seem I need to start
>another VM or use explicit class loaders. I could use brute force and
>make a test per combination of properties settings I want to test, but
>that seems ugly.. Any ideas?
>
>
>
If you shutdown derby with
DriverManager.getConnection("jdbc:derby:;shutdown=true");
then set the next property and start it back up again, will that work?
Also you will need to add your test to these two files to exclude it
from network server testing as it is not relevant there.sut
suites/DerbyNet.exclude
suites/DerbyNetClient.exclude
Kathey
Re: [PATCH] (DERBY-205; 2nd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Dag H. Wanvik wrote:
>Hi,
>
>
>
>>>>>>"KM" == Kathey Marsden <km...@sbcglobal.net> wrote:
>>>>>>
>>>>>>
>
>KM> If you shutdown derby with
>KM> DriverManager.getConnection("jdbc:derby:;shutdown=true");
>KM> then set the next property and start it back up again, will that work?
>
>This seems to be a necessary but not sufficient condition, see
>non-obvious requirement below.
>
>
>
>>>>>>"OB" == Oyvind Bakksjo <Oy...@Sun.COM> wrote:
>>>>>>
>>>>>>
>OB> Yes, system properties are VM-wide, but they can be changed at any time.
>OB> The problem is if the properties are read and used only once, when the
>OB> driver is loaded, since it is impossible to instruct a class loader to
>OB> "unload" anything.
>
>Derby docs says this can be achieved by forcing the garbage collector to
>run, cf the hint I found here, see quote below.
>
>http://incubator.apache.org/derby/docs/devguide/tdevdvlp20349.html
>
>(quote): To restart Derby successfully, the JVM needs to unload
> org.apache.derby.jdbc.EmbeddedDriver, so that it can reload
> it when it restarts Derby. (Loading the local driver starts
> Derby.) You cannot explicitly request that the JVM unload a
> class, but you can ensure that the EmbeddedDriver class is
> unloaded by using a System.gc() to force it to garbage
> collect classes that are no longer needed. Running with -nogc
> or -noclassgc definitely prevents the class from being
> unloaded and makes you unable to restart Derby in the same
> JVM.
>
>I found the following idiom worked:
>
> <set properties>
> Class.forName(driver).newInstance(); <--- newInstance can be dropped 1. time!!
> <use derby>
> DriverManager.getConnection("jdbc:derby:;shutdown=true");
>
>
Should a finalize be forced after this happens? May be gc() can pick this?
Or deregister the driver from the DriverManager?
~ Shreyas
> System.gc(); <--- in vain?
>
> <set new properties>
> Class.forName(driver).newInstance(); <---- but necessary here!
> <use derby with new properties>
> DriverManager.getConnection("jdbc:derby:;shutdown=true");
>
>Note: newInstance() was needed the second time around. Plain
>"Class.forName(driver)" wont do, it gives:
>
> SQLException: 08001:No suitable driver
>
>when I try to make a connection, i.e. the driver has not
>(re)registered itself with the DriverManager The driver's static
>initializer hasn't been run (again), cf. description in JDBC 3.0 spec
>section 9.2. This leads me to believe the driver hasn't been evicted
>by the gc() call after all. Why not? Did I miss something?
>
>However, adding newInstance() makes it work. Checking the code, I
>found this in EmbeddedDriver, which explains why it works; the
>constructor forces a reboot.
>
> static {
>
> EmbeddedDriver.boot();
> }
>
> // Boot from the constructor as well to ensure that
> // Class.forName(...).newInstance() reboots Cloudscape
> // after a shutdown inside the same JVM.
> public EmbeddedDriver() {
> EmbeddedDriver.boot();
> }
>
>Hmm... Should Derby docs mention using newInstance? Is it Kosher? The
>JDBC spec doesnt say anything about using newInstance...
>
>Not only Derby needs this, however, cf. also this discussion I found:
>
>https://lists.xcf.berkeley.edu/lists/advanced-java/2000-September/012601.html
>
>Dag
>
>
Re: [PATCH] (DERBY-205; 2nd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
>>>>> "KM" == Kathey Marsden <km...@sbcglobal.net> wrote:
KM> If you shutdown derby with
KM> DriverManager.getConnection("jdbc:derby:;shutdown=true");
KM> then set the next property and start it back up again, will that work?
This seems to be a necessary but not sufficient condition, see
non-obvious requirement below.
>>>>> "OB" == Oyvind Bakksjo <Oy...@Sun.COM> wrote:
OB> Yes, system properties are VM-wide, but they can be changed at any time.
OB> The problem is if the properties are read and used only once, when the
OB> driver is loaded, since it is impossible to instruct a class loader to
OB> "unload" anything.
Derby docs says this can be achieved by forcing the garbage collector to
run, cf the hint I found here, see quote below.
http://incubator.apache.org/derby/docs/devguide/tdevdvlp20349.html
(quote): To restart Derby successfully, the JVM needs to unload
org.apache.derby.jdbc.EmbeddedDriver, so that it can reload
it when it restarts Derby. (Loading the local driver starts
Derby.) You cannot explicitly request that the JVM unload a
class, but you can ensure that the EmbeddedDriver class is
unloaded by using a System.gc() to force it to garbage
collect classes that are no longer needed. Running with -nogc
or -noclassgc definitely prevents the class from being
unloaded and makes you unable to restart Derby in the same
JVM.
I found the following idiom worked:
<set properties>
Class.forName(driver).newInstance(); <--- newInstance can be dropped 1. time!!
<use derby>
DriverManager.getConnection("jdbc:derby:;shutdown=true");
System.gc(); <--- in vain?
<set new properties>
Class.forName(driver).newInstance(); <---- but necessary here!
<use derby with new properties>
DriverManager.getConnection("jdbc:derby:;shutdown=true");
Note: newInstance() was needed the second time around. Plain
"Class.forName(driver)" wont do, it gives:
SQLException: 08001:No suitable driver
when I try to make a connection, i.e. the driver has not
(re)registered itself with the DriverManager The driver's static
initializer hasn't been run (again), cf. description in JDBC 3.0 spec
section 9.2. This leads me to believe the driver hasn't been evicted
by the gc() call after all. Why not? Did I miss something?
However, adding newInstance() makes it work. Checking the code, I
found this in EmbeddedDriver, which explains why it works; the
constructor forces a reboot.
static {
EmbeddedDriver.boot();
}
// Boot from the constructor as well to ensure that
// Class.forName(...).newInstance() reboots Cloudscape
// after a shutdown inside the same JVM.
public EmbeddedDriver() {
EmbeddedDriver.boot();
}
Hmm... Should Derby docs mention using newInstance? Is it Kosher? The
JDBC spec doesnt say anything about using newInstance...
Not only Derby needs this, however, cf. also this discussion I found:
https://lists.xcf.berkeley.edu/lists/advanced-java/2000-September/012601.html
Dag
Re: [PATCH] (DERBY-205; 2nd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Posted by Oy...@Sun.COM.
David Van Couvering wrote:
> Yes, this was my experience also. You can't have multiple
> configurations in a VM instance, because everything is dependent on
> system properties (both Derby itself as well as the test harness
> infrastructure). I don't *think* using classloaders will help because
> system properties, as I understand it, are VM-wide and span
> classloaders. But I haven't explicitly tested that.
>
> David
Yes, system properties are VM-wide, but they can be changed at any time.
The problem is if the properties are read and used only once, when the
driver is loaded, since it is impossible to instruct a class loader to
"unload" anything.
It is possible to load the driver multiple times with different class
loaders. However, this requires that the driver is not in the classpath
for the VM, otherwise your class loaders will delegate to the system
classloader, which finds the driver and caches it. Thus, each class
loader will return the same class, which has been initialized only once.
If it is impossible to exclude the driver from the VM's classpath (due
to the test harness), it is still possible to load the driver multiple
times (with different system property settings) using a bit of a hack:
Make your own ClassLoader which doesn't delegate to its parent
classloader for certain class names (the driver's classes).
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
Re: [PATCH] (DERBY-205; 2nd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Posted by David Van Couvering <da...@vancouvering.com>.
Yes, this was my experience also. You can't have multiple
configurations in a VM instance, because everything is dependent on
system properties (both Derby itself as well as the test harness
infrastructure). I don't *think* using classloaders will help because
system properties, as I understand it, are VM-wide and span
classloaders. But I haven't explicitly tested that.
David
Dag H. Wanvik wrote:
> Hi,
>
>
>>>>>>"KM" == Kathey Marsden <km...@sbcglobal.net> wrote:
>
>
> KM> Thanks for working on the test.
>
> I am encountering an issue making a test for the setting of
> derby.stream.error.* properties. It seems the testing harness gives me
> no easy way to test combinations of system properites; once the driver
> is loaded, I am stuck with a particular setting of system-wide
> properties, e.g.
>
> Properties p = System.getProperties();
> p.put("derby.stream.error.method",
> "org.apache.derbyTesting.functionTests.tests.lang.TestErrorStreamTarget.getStream");
> :
> Class.forName(driver).newInstance();
>
> allows the test to boot a Derby redirecting the error log, but if I
> want to test several possibilities, it would seem I need to start
> another VM or use explicit class loaders. I could use brute force and
> make a test per combination of properties settings I want to test, but
> that seems ugly.. Any ideas?
>
> Thanks,
> Dag
>
> KM> I'll pick up Derby-213.
> KM> Please do let me know if you are looking for interesting network
> KM> server tasks when you are done with your test.
Re: [PATCH] (DERBY-205; 2nd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
>>>>> "KM" == Kathey Marsden <km...@sbcglobal.net> wrote:
KM> Thanks for working on the test.
I am encountering an issue making a test for the setting of
derby.stream.error.* properties. It seems the testing harness gives me
no easy way to test combinations of system properites; once the driver
is loaded, I am stuck with a particular setting of system-wide
properties, e.g.
Properties p = System.getProperties();
p.put("derby.stream.error.method",
"org.apache.derbyTesting.functionTests.tests.lang.TestErrorStreamTarget.getStream");
:
Class.forName(driver).newInstance();
allows the test to boot a Derby redirecting the error log, but if I
want to test several possibilities, it would seem I need to start
another VM or use explicit class loaders. I could use brute force and
make a test per combination of properties settings I want to test, but
that seems ugly.. Any ideas?
Thanks,
Dag
KM> I'll pick up Derby-213.
KM> Please do let me know if you are looking for interesting network
KM> server tasks when you are done with your test.
Re: [PATCH] (DERBY-205; 2nd patch) org.apache.derby.impl.drda.DB2jServerImpl
to NetworkServerControlImpl
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dag H. Wanvik wrote:
> I am still busy making a test for the 2nd
>patch for Derby-205, so I might not be able to address Derby-213 this
>week, though, your call :)
>
>
>
Thanks for working on the test. I'll pick up Derby-213.
Please do let me know if you are looking for interesting network
server tasks when you are done with your test.
Thanks
Kathey
Re: [PATCH] (DERBY-205; 2nd patch)
org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi Kathey,
>>>>> "KM" == Kathey Marsden <km...@sbcglobal.net> wrote:
KM> looking for a next in Network Server I was wondering if you might be
KM> interested in DERBY-213. I actually want to get DERBY-213 addressed
KM> in the next week, but if you are interested and available to look at it
KM> that would be great. I will provide any support I can.
Sure, I would do that! I am still busy making a test for the 2nd
patch for Derby-205, so I might not be able to address Derby-213 this
week, though, your call :)
Dag
Re: [PATCH] (DERBY-205; 2nd patch) org.apache.derby.impl.drda.DB2jServerImpl
to NetworkServerControlImpl
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dag H. Wanvik wrote:
>Hi,
>
>I have uploaded a second patch for derby-205
>
Thanks Dag!
I will review this patch and commit if I see no issues. If you are
looking for a next in Network Server I was wondering if you might be
interested in DERBY-213. I actually want to get DERBY-213 addressed
in the next week, but if you are interested and available to look at it
that would be great. I will provide any support I can.
Kathey