Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/

[Adrian Crum-3]

Those same tests fail every time. There was one exception - when I had
other CPU-intensive tasks running at the same time.

Windows XP, 32 bit, dual processor, 4 GB RAM, 8 GB virtual memory, SSD.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 7/1/2014 8:59 AM, Adam Heath wrote:

> 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, [hidden email]
>>>>>> 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.
>>>>
>>>
>

[Jacques Le Roux]

I have asked infra at https://issues.apache.org/jira/browse/INFRA-7994

 >What version of java does this happen most on?
Actually it does not depend on Java version, it sometimes happens in trunk (Java 7) and releases (Java 6)

I don't have this problem on my machine (Windows 7)

Jacques

Le 26/06/2014 22:30, Jacques Le Roux a écrit :

> Good questions, I will ask infra!
>
> Jacques
>
> Le 26/06/2014 19:27, Adam Heath a écrit :
>> What filesystem type?  ext2/3/4, reiserfs, btrfs?  What mount options? These may sound like odd questions, but not if you follow kernel development
>> on lwn.net.
>>
>> How much memory?  How many cpus?  What level of cpu cache?  What speed cpu?  32-bit/64-bit?
>>
>> What version of java does this happen most on?

--

[Jacques Le Roux]

They answered: Ext4. No CPU cache as virtualised. RAM varies across different build slaves. As does CPU speed. 64bit arch.

HTH

Jacques

Le 02/07/2014 10:04, Jacques Le Roux a écrit :

> I have asked infra at https://issues.apache.org/jira/browse/INFRA-7994
>
> >What version of java does this happen most on?
> Actually it does not depend on Java version, it sometimes happens in trunk (Java 7) and releases (Java 6)
>
> I don't have this problem on my machine (Windows 7)
>
> Jacques
>
> Le 26/06/2014 22:30, Jacques Le Roux a écrit :
>> Good questions, I will ask infra!
>>
>> Jacques
>>
>> Le 26/06/2014 19:27, Adam Heath a écrit :
>>> What filesystem type?  ext2/3/4, reiserfs, btrfs?  What mount options? These may sound like odd questions, but not if you follow kernel
>>> development on lwn.net.
>>>
>>> How much memory?  How many cpus?  What level of cpu cache? What speed cpu?  32-bit/64-bit?
>>>
>>> What version of java does this happen most on?
>