db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1091) Test harness does not pass jvm flags properly if there are more than 1 property in jvm flags
Date Mon, 26 Jun 2006 21:44:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1091?page=comments#action_12417897 ] 

Myrna van Lunteren commented on DERBY-1091:
-------------------------------------------

I've been pecking away at this issue, and I've had some struggles with it.

I am not ready with a patch yet but to show some activity on this issue here a few of my findings
and thoughts.

- I found that Manjula's report that the -Xjit:count=0 (which is similiar to using any other
non-'-D' kind of flag, like -d32 / -D64) works, actually only holds true for Windows. That
is, using the -jvmflags=-Xjit:count:0  with an ibm 15 jvm worked for me on Windows, but not
on Linux. The problem was that somehow, adding quotes as was done in RunList.java caused the
jvm on (at least) Linux to think a class name was being passed in. Because I couldn't work
my way through this bug fast enough this issue was handled separately in bug DERBY-1444.

- I noticed that 123 of the .java tests do the following ij invocation: 
	ij.getPropertyArg(argv); 
  This makes the .java test look at a properties file listed with -p. And this explains why
even with a .java test the harness passes on a -p <test_app.properties> to the jvm.
I have no idea how many of these tests actually depend on the properties in the _app.properties
files, but getting rid of the _app.property file for .java files could get pretty involved.

- one requirement for use of jvmflags is twofold:
- to pass on any and all flags and have them be added to whatever flags are already present
- to overwrite specific flags that have been set in any kind of property file (with precedence
rule: commandline over suite properties over derby.properties or test_app.properties).

Jvmflags are hard to deal with because they can be non-standard, and can be used to mean anything.
For instance, the -Dpropertykey=propertyvalue is pretty standard, and the harness could go
through the list in jvmflags, evaluate wether the propertykey is already present, and let
the commandline item overwrite the suite setting overwrite the test setting. But if we're
talking about a -Xmx value, or like the -mx512M, the harness would need special knowledge
about that to overwrite settings for that. 
Judging from the mechanisms in place, the folks initially creating the harness gave a swing
at doing this, but it looks like it doesn't quite work correctly. (see Raman's report re -mx
etc).
However, there is no logic in place to evaluate this in the test harness. I assume the jvm
has some logic - i.e. if a jvm is confronted with two -X values, what does it take? If a jvm
that accepts -Xmx as well as -mx, and both properties are passed in, and they're different,
what will get used?

Another question, is try to totally revamp the test property mechanisms in place, or just
try to make something work for now. There are currently three sort of properties that get
passed about from RunSuite via Runlist to RunTest: 
- jvmflags
- testJavaFlags
- testSpecialProps
Not all of these get passed on correctly or appropriately. The entire handling is severly
convoluted because RunTest itself adds things to the local variable jvmflags, and because
it tries to evaluate jvmflags as well for test harness properties.

The harness (RunTest/jvm.java) currently adds -D to jvmflags not starting with -X or -D.

The harness currently adds some jvmflags to both the test_app.properties file and to the commandline
for the jvm.

The harness (RunTest/SpecialFlags.java) currently splits the jvmflags into either ij-related
properties, to go into the <test>_app.properties file, and 'server'-related properties
(apparently any starting with 'derby'), which (?) either get passed on to the jvm or get placed
into the derby.properties file.
It's not clear what happens to properties that don't start with ij nor derby.

RunTest.java (for multi tests) and NetServer.java explicitly set the mx and ms values if jvmflags
doesn't have anything for them...but it's looking for the -ms or -mx value, not for the now
also valid -Xmx or -Xms...

After lengthy (and including various abortive derbyall runs) this is my plan:
- for now, leave the testJavaFlags and testSpecialProps unchanged, but no longer use them
in any tests/suite properties, instead, use jvmflags. document.
- leave the <test>_app.properties in place (even though it's counter-intuitive to use
ij in a .java test) because of the limitations to the length of a commandline string on windows
platform (I don't actually know what the limits are, but I know it's there).
- make jvmflags property take a '^' separated list rather than a space-separated list as a
propertyvalue, which gets converted into a space-separated list in the local variable in RunTest.java.

i.e. you pass the properties like so:[ -Djvmflags=-Da=1^-Db=2^-Xblah^-yo  ] to RunSuite/RunTest.

- modify padding with 'D'to only when there is no '-'
- make the command line flags be passed after the suite flags and the suite flags after the
test flags, so that the jvm follows the desired precedence of commandline-suite-test because
the jvm (supposedly) picks up the 'last' setting. 
- for harness properties (properties the harness evaluates) ensure this sequence is kept in
mind too - to ensure precedence/overwriting.
- adjust NetServer and RunTest to check for -Xmx and -Xms as well as -mx and -ms


> Test harness does not pass jvm flags properly if there are more than 1 property in jvm
flags
> --------------------------------------------------------------------------------------------
>
>          Key: DERBY-1091
>          URL: http://issues.apache.org/jira/browse/DERBY-1091
>      Project: Derby
>         Type: Test

>   Components: Test
>     Versions: 10.2.0.0
>  Environment: Windows 2000
>     Reporter: Ramandeep Kaur
>     Assignee: Myrna van Lunteren
>     Priority: Minor

>
> To run Derby tests with EMMA for Code coverage, there is a need to set up emma flag -Djvmflags=-Demma.verbosity.level=silent.
This is basically to enable EMMA not to print out any messages to avoid having any diffs.
This all works fine when running Derby tests with EMMA for jdk142, jdk15, jdk131 etc because
there is no other jvm flag that is passed while calling RunSuite Command. 
> Now, while running tests with j2me/cdc/foundation, another value needs to be passed as
jvmflag which is
> -Djvmflags="Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource".
> I tried to combine values for both jvm flags as following, but it did not work properly:
> 1. -Djvmflags='-Demma.verbosity.level=silent -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource'
> During this run, the value that was further passed while running one test was Djvmflags="'-Demma.verbosity.level=silent".
> As you can notice it took jvm flag as '-Demma.verbosity.level=silent 
> 2. -Djvmflags="-Demma.verbosity.level=silent -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource"
> During this run, the value that was further passed while running one test was Djvmflags=""-Demma.verbosity.level=silent".
> As you can notice it took jvm flag as "-Demma.verbosity.level=silent 
> From the above it looks like test harness needs to be changed so that it can parse multiple
values for jvm flags properly.

-- 
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


Mime
View raw message