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 |
Administrator
|
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, [hidden email] 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 |
Jacques,
First you should answer the question for what we are using Buildbot.. Is it for testing or for building? 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. 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 < [hidden email]> 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, [hidden email] 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 > |
Administrator
|
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. 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 < > [hidden email]> 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, [hidden email] 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 |
Jacques,
The main aspect of testing is to ensure that the changes committed don't break the functionality, before it gets implemented in a nightly or release build. I have - in a separate checkout - a complete working setup with IVY for all jars. Not just the main libs, but also in the components. With a proper configuration of your build.xml and your CI you can inject/trigger any setup configuration to build for testing (against accepted jar-version, against latest sub release of jar-version, against latest release and against latest available) and based on that it can be decided what version to include in nightly and release builds before creating the zip files. This would alleviate the need to commit manually the jars and update the dependent docs, and revert the commits when testing fails. Which, with over 200+ jars is a cumbersome feat. And which is best handled in a CI system. In the case of generating nightly and release builds you would just change the version/revision number of the jar in the configuration setting. Regards, Pierre Smits *ORRTIZ.COM <http://ORRTIZ.COM>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
By the way, why did you commit the jar(s) upgrade to the 12.x release? Did
some bug fix in 12.x warrant the upgrade due to test failure? Pierre Smits *ORRTIZ.COM <http://ORRTIZ.COM>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
Administrator
|
In reply to this post by Pierre Smits
This is interesting, but I fear I will not have enough time to engage such an effort, at least for the moment...
inline... On Wednesday, February 05, 2014 1:39 PM, [hidden email] wrote > Jacques, > > The main aspect of testing is to ensure that the changes committed don't > break the functionality, before it gets implemented in a nightly or release > build. Yes, this is what Buildbot ensures. > I have - in a separate checkout - a complete working setup with IVY for all > jars. Not just the main libs, but also in the components. Would it make sense to share it, in relation with the recent Ivy Jira issues you created? > With a proper configuration of your build.xml and your CI you can > inject/trigger any setup configuration to build for testing (against > accepted jar-version, against latest sub release of jar-version, against > latest release and against latest available) and based on that it can be > decided what version to include in nightly and release builds before > creating the zip files. I have to think about it, all is automated for now. > This would alleviate the need to commit manually the jars and update the > dependent docs, and revert the commits when testing fails. Which, with over > 200+ jars is a cumbersome feat. And which is best handled in a CI system. > In the case of generating nightly and release builds you would just change > the version/revision number of the jar in the configuration setting. How would you update the related files (mostly .classpath and LICENSE)? Jacques > Regards, > > Pierre Smits > > *ORRTIZ.COM <http://ORRTIZ.COM>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com |
Jacques,
Better is it to discuss this via https://issues.apache.org/jira/browse/OFBIZ-5464 But I will summarize your questions here and post them in a comment at the issue. - Are you taking into account the security, I mean the possible vulnerabilties? - Would it make sense to share it, in relation with the recent Ivy Jira issues you created? - How would you update the related files (mostly .classpath and LICENSE)? Regards, Pierre Smits *ORRTIZ.COM <http://ORRTIZ.COM>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
Administrator
|
In reply to this post by Jacques Le Roux
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? 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 < >> [hidden email]> 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, [hidden email] 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 |
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 < [hidden email]> 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? > > 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 < >>> [hidden email]> 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, [hidden email] 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 >>>>> >>>> |
Administrator
|
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 < > [hidden email]> 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? >> >> 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 < >>>> [hidden email]> 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, [hidden email] 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 >>>>>> -- |
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 < [hidden email]> 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 < >> [hidden email]> 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? >>> >>> 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 < >>>>> [hidden email]> 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, [hidden email] 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 >>>>>>> >>>>>>> > -- > |
In reply to this post by Jacques Le Roux
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. |
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. > |
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. >> > |
Administrator
|
In reply to this post by Adam Heath-2
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, [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. >> > > -- |
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 > |
Administrator
|
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 >> > > -- |
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 >>> >> >> > |
In reply to this post by Adrian Crum-3
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. >>> >> |
Free forum by Nabble | Edit this page |