[
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
