You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2014/06/26 11:54:24 UTC
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./
framework/service/lib/
Le 05/02/2014 12:07, Jacques Le Roux a écrit :
> On Wednesday, February 05, 2014 10:32 AM, pierre.smits@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?
Jacques
>
> Jacques
>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://ORRTIZ.COM>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>> On Wed, Feb 5, 2014 at 9:42 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> How would you force it to take 1.5.2 instead of 1.6.2?
>>>
>>> For CI we have Buildbot which works like a charm
>>>
>>> Jacques
>>>
>>> On Wednesday, February 05, 2014 9:17 AM, pierre.smits@gmail.com wrote
>>>> Jacques,
>>>>
>>>> This could easily be avoided if we have
>>>> https://issues.apache.org/jira/browse/OFBIZ-5464 combined with CI. The same
>>>> goes for svn commit: r1564662
>>>>
>>>> Regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://ORRTIZ.COM>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Pierre Smits <pi...@gmail.com>.
Thanks for the expanation, Jacques.
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Thu, Jun 26, 2014 at 12:48 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Indeed :D
>
> It's related to (currently) eg: http://ci.apache.org/projects/
> ofbiz/logs/13.07/html/ (if you have access)
>
> Once on 2 the testBasicDisk Junit test fails in Builbot (OFBiz ASF CI
> tool) when it's actually a false report
> So as I follow Buildbot results, every time this happens I have to check
> if there is a real error or not.
>
> Moreover Buildbot passes from a valid (no errors) to not valid state.
> So if you have this false error and then a real error, if you forget the
> last state (not valid due to the false report) you will not spot the fact
> that a real error occurred :/
>
> So again, that's why I REALLY REALLY want to disconnect the testBasicDisk
> JUnit test in trunk and all living releases, anyone against it?
>
> Here it is:
>
> public void testBasicDisk() throws Exception {
> UtilCache<String, String> cache = createUtilCache(5, 0, 0, false,
> true);
> basicTest(cache);
> }
>
> public void testSimple() throws Exception {
> UtilCache<String, String> cache = createUtilCache(5, 0, 0, false,
> false);
> basicTest(cache);
> }
>
> So, since only testBasicDisk (which uses the disk as a cache
> -useFileSystemStore parameter- when not testSimple) fails I think we can
> disconnect it
> It just shows that the disk sub-system where currently OFBiz Builbot
> operates is not safe (which is weird since all the rest is OK, but I'm fed
> up with it)
> Note that with the previous machine we used (its disk sub-system crashed
> few month ago) we NEVER had this issue, and I NEVER got it locally or on
> customers servers
>
> Jacques
>
>
> Le 26/06/2014 12:10, Pierre Smits a écrit :
>
>> Jacques,
>>
>> Your question is very ambiguous. What is it exactly that you want to
>> disconnect?
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>> On Thu, Jun 26, 2014 at 11:54 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Le 05/02/2014 12:07, Jacques Le Roux a écrit :
>>>
>>> On Wednesday, February 05, 2014 10:32 AM, pierre.smits@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?
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>> Jacques
>>>>
>>>>
>>>> Regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://ORRTIZ.COM>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>>
>>>>> On Wed, Feb 5, 2014 at 9:42 AM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> How would you force it to take 1.5.2 instead of 1.6.2?
>>>>>
>>>>>> For CI we have Buildbot which works like a charm
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> On Wednesday, February 05, 2014 9:17 AM, pierre.smits@gmail.com wrote
>>>>>>
>>>>>> Jacques,
>>>>>>>
>>>>>>> This could easily be avoided if we have
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-5464 combined with CI.
>>>>>>> The same
>>>>>>> goes for svn commit: r1564662
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *ORRTIZ.COM <http://ORRTIZ.COM>*
>>>>>>> Services & Solutions for Cloud-
>>>>>>> Based Manufacturing, Professional
>>>>>>> Services and Retail & Trade
>>>>>>> http://www.orrtiz.com
>>>>>>>
>>>>>>>
> --
>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./
framework/service/lib/
Posted by Jacques Le Roux <ja...@les7arts.com>.
Indeed :D
It's related to (currently) eg: http://ci.apache.org/projects/ofbiz/logs/13.07/html/ (if you have access)
Once on 2 the testBasicDisk Junit test fails in Builbot (OFBiz ASF CI tool) when it's actually a false report
So as I follow Buildbot results, every time this happens I have to check if there is a real error or not.
Moreover Buildbot passes from a valid (no errors) to not valid state.
So if you have this false error and then a real error, if you forget the last state (not valid due to the false report) you will not spot the fact that a real error occurred :/
So again, that's why I REALLY REALLY want to disconnect the testBasicDisk JUnit test in trunk and all living releases, anyone against it?
Here it is:
public void testBasicDisk() throws Exception {
UtilCache<String, String> cache = createUtilCache(5, 0, 0, false, true);
basicTest(cache);
}
public void testSimple() throws Exception {
UtilCache<String, String> cache = createUtilCache(5, 0, 0, false, false);
basicTest(cache);
}
So, since only testBasicDisk (which uses the disk as a cache -useFileSystemStore parameter- when not testSimple) fails I think we can disconnect it
It just shows that the disk sub-system where currently OFBiz Builbot operates is not safe (which is weird since all the rest is OK, but I'm fed up with it)
Note that with the previous machine we used (its disk sub-system crashed few month ago) we NEVER had this issue, and I NEVER got it locally or on customers servers
Jacques
Le 26/06/2014 12:10, Pierre Smits a écrit :
> Jacques,
>
> Your question is very ambiguous. What is it exactly that you want to
> disconnect?
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Thu, Jun 26, 2014 at 11:54 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Le 05/02/2014 12:07, Jacques Le Roux a écrit :
>>
>> On Wednesday, February 05, 2014 10:32 AM, pierre.smits@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?
>>
>> Jacques
>>
>>
>>
>>
>>> Jacques
>>>
>>>
>>>> Regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://ORRTIZ.COM>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>>
>>>> On Wed, Feb 5, 2014 at 9:42 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> How would you force it to take 1.5.2 instead of 1.6.2?
>>>>> For CI we have Buildbot which works like a charm
>>>>>
>>>>> Jacques
>>>>>
>>>>> On Wednesday, February 05, 2014 9:17 AM, pierre.smits@gmail.com wrote
>>>>>
>>>>>> Jacques,
>>>>>>
>>>>>> This could easily be avoided if we have
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-5464 combined with CI.
>>>>>> The same
>>>>>> goes for svn commit: r1564662
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> *ORRTIZ.COM <http://ORRTIZ.COM>*
>>>>>> Services & Solutions for Cloud-
>>>>>> Based Manufacturing, Professional
>>>>>> Services and Retail & Trade
>>>>>> http://www.orrtiz.com
>>>>>>
--
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Pierre Smits <pi...@gmail.com>.
Jacques,
Your question is very ambiguous. What is it exactly that you want to
disconnect?
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Thu, Jun 26, 2014 at 11:54 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
>
> Le 05/02/2014 12:07, Jacques Le Roux a écrit :
>
> On Wednesday, February 05, 2014 10:32 AM, pierre.smits@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?
>
> Jacques
>
>
>
>
>> Jacques
>>
>>
>>> Regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://ORRTIZ.COM>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>>
>>> On Wed, Feb 5, 2014 at 9:42 AM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> How would you force it to take 1.5.2 instead of 1.6.2?
>>>>
>>>> For CI we have Buildbot which works like a charm
>>>>
>>>> Jacques
>>>>
>>>> On Wednesday, February 05, 2014 9:17 AM, pierre.smits@gmail.com wrote
>>>>
>>>>> Jacques,
>>>>>
>>>>> This could easily be avoided if we have
>>>>> https://issues.apache.org/jira/browse/OFBIZ-5464 combined with CI.
>>>>> The same
>>>>> goes for svn commit: r1564662
>>>>>
>>>>> Regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://ORRTIZ.COM>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Adrian Crum <ad...@sandglass-software.com>.
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, pierre.smits@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.
>>>>
>>>
>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Adam Heath <do...@brainfood.com>.
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.smits@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.
>>>
>>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Adrian Crum <ad...@sandglass-software.com>.
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.smits@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.
>>
>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./
framework/service/lib/
Posted by Jacques Le Roux <ja...@les7arts.com>.
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?
>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./
framework/service/lib/
Posted by Jacques Le Roux <ja...@les7arts.com>.
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?
--
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Adam Heath <do...@brainfood.com>.
Bother. ofbiz uses jdbm-1.0-snapshot. On sf, the project is dead, it's
now JDBM3. On github, that's in maintenance mode, go to JDBM4. Nope,
that's been renamed to MapDB.
The feature set of MapDB is much larger than the original 1.0. Seems
like we should probably upgrade.
On 06/26/2014 03:30 PM, Jacques Le Roux wrote:
> 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?
>>
>> I suppose you could disable the test(the trick I use is to prefix the
>> method name with '_').
>>
>> Adrian, I saw your mail.
>>
>> I'm trying to find a way to replicate the issues, but they are
>> problematic.
>>
>> On 06/26/2014 11:34 AM, Jacques Le Roux wrote:
>>> How would I fix this random failure when I have no real access to
>>> this machine? All others I tried worked :/
>>>
>>> Jacques
>>>
>>
>>
>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./
framework/service/lib/
Posted by Jacques Le Roux <ja...@les7arts.com>.
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?
>
> I suppose you could disable the test(the trick I use is to prefix the method name with '_').
>
> Adrian, I saw your mail.
>
> I'm trying to find a way to replicate the issues, but they are problematic.
>
> On 06/26/2014 11:34 AM, Jacques Le Roux wrote:
>> How would I fix this random failure when I have no real access to this machine? All others I tried worked :/
>>
>> Jacques
>>
>
>
--
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Adam Heath <do...@brainfood.com>.
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?
I suppose you could disable the test(the trick I use is to prefix the
method name with '_').
Adrian, I saw your mail.
I'm trying to find a way to replicate the issues, but they are problematic.
On 06/26/2014 11:34 AM, Jacques Le Roux wrote:
> How would I fix this random failure when I have no real access to this
> machine? All others I tried worked :/
>
> Jacques
>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./
framework/service/lib/
Posted by Jacques Le Roux <ja...@les7arts.com>.
How would I fix this random failure when I have no real access to this machine? All others I tried worked :/
Jacques
Le 26/06/2014 17:54, Adam Heath a écrit :
> 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.smits@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.
>>
>
>
--
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Adam Heath <do...@brainfood.com>.
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.smits@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.
>
Re: svn commit: r1564663 - in /ofbiz/branches/release12.04: ./ framework/service/lib/
Posted by Adam Heath <do...@brainfood.com>.
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.smits@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.