Daniel John Debrunner wrote:
Kathey Marsden (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497457
]
Kathey Marsden commented on DERBY-2644:
---------------------------------------
I can no longer reproduce the failures. I think in fact that the
failures I was seeing were in different tests. If upgrade is causing
the problem, it would seem sensible to either move the Encryption
suite before the upgrade tests or remove it all together since it is
not very functional.
The EncryptionKeyXXXTest failures that I have been seeing have been
resolved in my client by adding
permission java.util.PropertyPermission "user.dir", "read";
permission.
So, I propose the following approach:
Today I will disable the Encryption suite.
Tuesday I will reenable the EncryptionKeyXXXTests with the new
permission.
Does that sound reasonable?
-1
I don't see any reason to disable working tests, the Encryption suite.
It does produce a somewhat useful function, ensure that databases can be
created with various encryption algorithms. It is also a initial step in
duplicating that old harness that run a number of standard tests with
encryption. Ie. the idea was that once old harness store tests that run
with & without encryption were converted to JUnit they could be added to
the Encryption suite. If certain environments are having trouble running
tests then the problems should be tracked down in those environments,
not by making changes to svn to see the effect in those environments.
On adding the property I agree with Kristian, the reason why this
property is suddenly needed should be tracked down.
FYI - running the tests through ant junit-all gives me clean runs using
a 1.5 jvm as of the latest check-in (Revision: 540150). Running the
tests using ant is different to running them using suites.All.
The Encryption suite is failing on a number of platforms, as of a friday
night build it failed on ibm15 and ibm142 on windows. And on ibm142 on
linux (I don't have ibm15 results on linux for that build). It failed
today under an for me ibm15, windows XP, SANE classes - but I only
tested a modified suite run where I only ran the upgrade tests, store
junit tests (both with the encryption junit test enabled and disabled),
and the encryption suite. I haven't had time to run the full suite to
test it out.
It looks like it is failing in same way in tinderbox regression suite,
And a quick scan leads me to believe it is also failing in every
environment (I think 15 or so between jvm and OS/machine combinations)
currently reported for the trunk under:http://dbtg.thresher.com/derby/test/
I don't think all the errors in the sun JVM reports are related to
this issue, but with the new junit suite it is hard to tell if one
failure in one test is affecting other tests. It is clear whatever
this issue is, the failure in one set of tests is affected by
running/not running some completely separate set of tests in the same
suite. As dan pointed out it seems also to come and go depending on
what way you run the tests.
In the past I thought it was ok to stop running a test under nightly
tests, if the failure was reported in JIRA - especially if someone was
actively working on it. I agree it is not as clear when a bug only
reproduces in a single environment, then I probably would not advocate
eliminating the test. For me this current issue is so widespread that
it would be ok with me to comment out the encryption suite while trying
to figure out how to fix the issue. It would also be ok with me to
mark this issue such that we don't make a release unless we resolve it.
Also I think there are actually at least 2 different issues here, the
encryption suite failures, and the EncryptionKeyXXXTests. Maybe we
should be tracking under separate issues.
Dan.
