On Mon, Mar 15, 2010 at 4:21 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > I have nothing against that, but I was making a slightly different point. > > Coding a framework is different than coding an application. With the latter, > one pretty much knows what to expect. With frameworks things are a bit more > complicated. I can see how a developer in a long running, managed > application, would create/start/stop a camel context multiple times. We > should not have side effects from previous executions of the camel context, > i.e. camel should cleanup after itself. Done right, it will also have the > fringe benefit of not needing to instantiate a jvm pertest. Having 2 profiles > with different testing strategies is fine. >
Camel does cleanup the JMX stuff when its shutdown. Its most likely other "stuff" which influence this which have a unforseen and weird side effect which causes tests to not run reliable across all OS in any time you you run it. Of course giving the shutdown logic a review in Camel is of course a good thing in case anyone can spot a weak spot. > Cheers, > Hadrian > > > On Mar 15, 2010, at 8:53 AM, Claus Ibsen wrote: > >> On Mon, Mar 15, 2010 at 1:10 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: >>> I would also like to see a more aggressive testing strategy, probably using >>> 'once' instead of 'pertest'. The only major offender is indeed jmx which >>> does not cleanup properly on shutdown, you are correct. We should >>> definitely look into the jmx cleanup, because we cannot always assume the >>> lifetime of the camel context to match the one of the hosting process. >>> >> >> No I dont think this is a good way. We end up with having unforseen >> side effects which causes all kind of pain trying to look into it and >> thinking there is a real problem. >> >> I would suggest if its possible with Maven to have a profile for >> testing without "per test" that people can run if they like to run a >> faster test, but with the potential of unforseen sideeffects. >> Then all the CI servers can chunk using per test and have a longer but >> reliable test run. >> >> >> >>> My $0.02, >>> Hadrian >>> >>> On Mar 15, 2010, at 3:33 AM, Christian Schneider wrote: >>> >>>> Hi Willem, >>>> >>>> that is probably a good idea. I guess there are other modules that need >>>> this setting too. I can report where I have failures now and you can then >>>> also set these modules to fork per test. >>>> Many modules like core and spring do not seem to need the setting. So I >>>> guess it is a good idea to keep the fork mode in a faster setting for them. >>>> >>>> Another possibility would be to set fork per test as default and set to a >>>> faster setting for specific modules. I guess Claus would prefer this >>>> variant. >>>> >>>> Greetings >>>> >>>> Christian >>>> >>>> >>>> Am 15.03.2010 07:41, schrieb Willem Jiang: >>>>> The test became long because I changed the surefire plugin's fork mode to >>>>> be "pertest" from the camel root pom.xml. That is not necessary for most >>>>> case, so I reverted my change and let the camel-jetty module's fork mode >>>>> to be "pertest". >>>>> >>>>> Willem >>>>> >>>>> Claus Ibsen wrote: >>>>>> On Mon, Mar 15, 2010 at 3:15 AM, Willem Jiang <willem.ji...@gmail.com> >>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I just change the fork mode in the camel-jetty to be pertest, it will >>>>>>> save >>>>>>> us some time of running the test. >>>>>>> >>>>>> >>>>>> Why did you do that? Testing camel-jetty does not take that long. >>>>>> I would rather have a more stable and reliable build and test, than >>>>>> something that in some mysterious ways have errors which are caused by >>>>>> some side effects. >>>>>> >>>>>> I would like it to be reverted. >>>>>> >>>>>> >>>>>>> Willem >>>>>>> >>>>>>> Christian Schneider wrote: >>>>>>>> Am 14.03.2010 10:42, schrieb Claus Ibsen: >>>>>>>>> Great this is good news. You can really get on a wild goose chase if >>>>>>>>> testing is done without forking the JVM. >>>>>>>>> >>>>>>>>> The bad news it takes much longer to test. >>>>>>>>> Well it does not take around 150 min to do a full build on my Mac. It >>>>>>>>> used to be 120-130 min. >>>>>>>>> >>>>>>>>> >>>>>>>> Yes I also noticed the build takes longer now (about 240 minutes on my >>>>>>>> notebook). Perhaps the fork per test can be switched to a more moderate >>>>>>>> setting >>>>>>>> where we know the tests will work anyway. There is another thing I >>>>>>>> also >>>>>>>> noticed. The fork per test hides some unclean shutdown sequences where >>>>>>>> not >>>>>>>> all >>>>>>>> things are cleaned up. But I guess these could also be tested >>>>>>>> explicitly >>>>>>>> which is cleaner anyway. An example are the JMX tests which failed >>>>>>>> without >>>>>>>> the fork. >>>>>>>> I did not look into it in detail but I guess the JMX beans are not >>>>>>>> completely cleaned up on shutdown. Still I think it is a good thing >>>>>>>> that the >>>>>>>> build runs stable now. >>>>>>>> >>>>>>>> Greetings >>>>>>>> >>>>>>>> Christian >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Author of Camel in Action: http://www.manning.com/ibsen/ >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
