Does this happen every single time you run the cache tests, or only if
not, how frequently? Have you upgraded your computer/OS, and still get
the problem? Windows(I'm guessing, based on other mails), or something
else? 32-bit, or 64-bit?
I was staring at these areas last night(while playing with the entity
transaction cache, which plays into upgrading jdbm to mapdb, the latter
of which is radically different, and might have workable transactional
support natively), and the basic scenario is this:
* The cache in question starts out with no TTL set on it; nothing will
expire automatically.
* Tests are run, they pass.
* I change the TTL to 100ms, while the cache is empty.
* I add a new item.
* I wait 200ms.
* The test fails, because the item hasn't yet been removed.
On windows, it has a base clock of 1000ms. It divides this by 64, to
give 15.6ms at the basic interrupt frequency. Even with that slush
factor, I don't know how the item wouldn't be removed. I've thought
about increasing the times, or changing the test algo to run in a loop,
polling for the removal, and then comparing how long it took to remove
to some window of time; this will then show up nicely in error reports,
that it took too long to remove, and would point the problem as being
somewhere else.
When the error occurs, please check further back in the stdout/stderr,
and look for an exception that was thrown while inside the
ExecutionPool.ExecutionPoolPulseWorker.run(). While playing with the
new library above, any exceptions thrown while processing the delayQueue
items were aborting the background worker. I'll fix this particular
problem soon.
On 06/26/2014 11:21 AM, Adrian Crum wrote:
Btw, I still get consistent, repeated failures in those tests. I
mentioned that to you years ago.
<testcase
classname="org.ofbiz.base.util.cache.test.UtilCacheTests"
name="testBasicDisk" time="0.235">
<failure message="not-found"
type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError:
not-found
at
org.ofbiz.base.util.cache.test.UtilCacheTests.assertNoSingleKey(UtilCacheTests.java:236)
at
org.ofbiz.base.util.cache.test.UtilCacheTests.basicTest(UtilCacheTests.java:305)
at
org.ofbiz.base.util.cache.test.UtilCacheTests.testBasicDisk(UtilCacheTests.java:321)
at
org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:147)
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:239)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:340)
at org.ofbiz.base.start.Start.start(Start.java:382)
at org.ofbiz.base.start.Start.main(Start.java:122)
</failure>
</testcase>
<testcase
classname="org.ofbiz.base.util.cache.test.UtilCacheTests"
name="testSimple" time="0.203">
<failure message="not-found"
type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError:
not-found
at
org.ofbiz.base.util.cache.test.UtilCacheTests.assertNoSingleKey(UtilCacheTests.java:236)
at
org.ofbiz.base.util.cache.test.UtilCacheTests.basicTest(UtilCacheTests.java:305)
at
org.ofbiz.base.util.cache.test.UtilCacheTests.testSimple(UtilCacheTests.java:326)
at
org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:147)
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:239)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:340)
at org.ofbiz.base.start.Start.start(Start.java:382)
at org.ofbiz.base.start.Start.main(Start.java:122)
</failure>
</testcase>
<testcase
classname="org.ofbiz.base.util.cache.test.UtilCacheTests"
name="testExpire" time="2.5">
<failure message="no-key(0)"
type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError:
no-key(0)
at
org.ofbiz.base.util.cache.test.UtilCacheTests.expireTest(UtilCacheTests.java:410)
at
org.ofbiz.base.util.cache.test.UtilCacheTests.testExpire(UtilCacheTests.java:424)
at
org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:147)
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:239)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:340)
at org.ofbiz.base.start.Start.start(Start.java:382)
at org.ofbiz.base.start.Start.main(Start.java:122)
</failure>
</testcase>
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 6/26/2014 8:54 AM, Adam Heath wrote:
I'm the original author of the sophisticated UtilCache tests, btw.
On 06/26/2014 10:45 AM, Adam Heath wrote:
On 06/26/2014 04:54 AM, Jacques Le Roux wrote:
Le 05/02/2014 12:07, Jacques Le Roux a écrit :
On Wednesday, February 05, 2014 10:32 AM, pierre.sm...@gmail.com
wrote
Jacques,
First you should answer the question for what we are using
Buildbot.. Is it
for testing or for building?
It builds,tests and package nightly snapshots
http://ci.apache.org/projects/ofbiz/snapshots/
http://ci.apache.org/
http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk
http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-branch13
http://ci.apache.org/projects/ofbiz/logs/
With the appriopriate IVY configuration you can inject latest,
latest
release, latest in version (e.g. 1.5.x), or whatever external
(replacement
jar) to test.
How do you configure that?
Also I think that systematically using Yvy could prove to be
difficult, we have 200+ external libs in OFBiz.
Not only to set it (but also to track which version to keep, etc.)
This said it could be useful for the main libs, but then I wonder if
it's to easier/more-simple to do it manually from time to time.
The advantages would be that we would be sure to have the last
version, the drawback we need to check it compiles and tests when
automatically changed. With Buildbot, this should be OK.
Though at the moment, since we had to change the machine, the
current Buildbot has a problem with the testBasicDisk test as shows
the branch13 HTML report above.
So this is a question to All, could we not deconnect this test? It
keeps ransomy throwing false test alerts.
Because once on 2 testBasicDisk fails in Builbot I REALLY REALLY want
to disconnect it in trunk and all living releases, anyone against it?
Hrm? Then fix the random failures. Note how I just fixed the random
failures when run underneath java 1.7, because they were actually real
failures.
Don't do this yet.
