camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Windows build completely working now
Date Mon, 15 Mar 2010 15:39:52 GMT
On Mon, Mar 15, 2010 at 4:21 PM, Hadrian Zbarcea <> 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 <> 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 <>
>>>>>>> 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
>>>>>> 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
>>>>>>>> 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:
>> Open Source Integration:
>> Blog:
>> Twitter:

Claus Ibsen
Apache Camel Committer

Author of Camel in Action:
Open Source Integration:

View raw message