db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Embretsen <John.Embret...@Sun.COM>
Subject Re: enabling tracing info while running tests
Date Tue, 18 Jul 2006 11:20:45 GMT
Myrna van Lunteren wrote:
> On 7/17/06, Mayuresh Nirhali <Mayuresh.Nirhali@sun.com> wrote:
>> >>Hello,
>> >>
>> >>I am trying to get tracing info for a test run in standalone
>> >>manner. The test runs fine, but I do not see the traceFile being
>> >>created.
>> I tried following but didn't get the trace file.
>> java -cp $CLASSPATH -Djvmflags=derby.drda.traceFile=trace.out
>> org.apache.derby.drda.NetworkServerControl start
> Oops! just my 2 cents on that one...(note that I'm not really
> following the discussion, too wrapped up at the moment with other
> tasks, sorry).
> -Djvmflags will do anything for NetworkServerControl, it only works
> with the test harness
> (org.apache.derbyTesting.functionTests.harness.RunTest or RunSuite).

That is true. I also think that the "-D"-prefix has to be included for
all system properties passed to the harness as part of the jvmflags
property, e.g.:


org.apache.derbyTesting.... etc.

> Apologies if I confused the issue. With NetworkServerControl you want
> to just use -Dderby.drda.traceFile=, I think, if that property is
> valid at all. 

As far as I can tell from the docs (adminguide), derby.drda.traceFile is
not a valid property on the server side (at least not documented as such).

traceFile and traceLevel are connection URL attributes to be used for
client side tracing. See

I was not able to see any mention of such properties on the server side.
And they had no effect when I tried them...

To enable server side tracing, I found it easiest to follow the approach
described by Knut Anders in

Specifically, start the Network Server manually with the property
derby.drda.traceAll=true, e.g:

java -Dderby.drda.traceAll=true -jar derbyrun.jar server start

Then start the test:

java -Dverbose=true -Dframework=DerbyNetClient

Trace files end up as Server<SESSION_NUMBER>.trace files in the
derby.system.home directory (default is the directory where you started
the server), unless you also specify the derby.drda.traceDirectory
property when starting the server.

Server properties are documented here:


> When you run a test with RunTest, you can use -Dverbose=true
> -Dkeepfiles=true to see the actual command it is using, then look at
> the *_app.properties and *_derby.properties file within the test
> subdirectory to see the actual properties it has picked up...Then work
> your modifications from there.

I tried passing the derby.drda.traceAll property to the harness via
jvmflags, but the test hung, probably due to lack of (SecurityManager)
write permissions when writing the trace files. That might be something
to keep in mind if this path is pursued further.


View raw message