Hi Hannah,
I ran 'mvn clean install' from trunk and got quiesce test failures quite
frequently. Below is the error I got for the QuiesceBlueprintTest from a
recent test run.
-------------------------------------------------------------------------------
Test set: org.apache.aries.blueprint.itests.QuiesceBlueprintTest
-------------------------------------------------------------------------------
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 20.616 sec
<<< FAILURE!
testMultiBundleQuiesce
[equinox/3.5.0](org.apache.aries.blueprint.itests.QuiesceBlueprintTest)
Time elapsed: 3.409 sec <<< FAILURE!
junit.framework.AssertionFailedError: Quiesce callback should have
occurred once for bundle a but not for bundle q; calls should be 1, but it
is 2
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at
org.apache.aries.blueprint.itests.QuiesceBlueprintTest.testMultiBundleQuiesce(QuiesceBlueprintTest.java:376)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134)
at
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:310)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at
java.security.AccessController.doPrivileged(AccessController.java:284)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:898)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:920)
at java.lang.Thread.run(Thread.java:736)
Regards,
Emily
From: Hannah Ramlee <[email protected]>
To: [email protected]
Date: 18/09/2010 23:39
Subject: Re: building Apache Aries trunk from the top level pom
Hi Emily,
I have been trying to reproduce the intermittent quiesce failures to debug
them, however on my system they don't fail :(
I'm not sure what is different about my environment that means I do not
see
these issues - will continue to investigate.
Hannah
On 17 September 2010 22:30, Emily Jiang <[email protected]> wrote:
> I have fixed the application itests intermittent failures. After you
have
> pulled the latest changes into your local repository, you should not see
> application itests failures any more. If it is not the case, please let
me
> know. The fix does not fix the quiesce test failures though:(.
>
> Has someone started looking at the intermittent quiesce test failures?
>
> Thanks
> Emily
>
>
>
> From: Joe Bohn <[email protected]>
> To: [email protected]
> Date: 16/09/2010 18:11
> Subject: Re: building Apache Aries trunk from the top level pom
>
>
>
> On 9/16/10 12:58 PM, Alasdair Nottingham wrote:
> > On 16 September 2010 01:45, Holly Cummins<[email protected]> wrote:
> >> I wonder if running with a bigger heap would help?
> >
> > That is plausible. I don't have these issues and I have to run with a
> > non-default heap size or the build fails with OOM errors on my mac.
> > Perhaps 512m is big enough not to see these errors.
> >
>
> My MAVEN_OPTS="-XX:MaxPermSize=512m -Xms1024m -Xmx1024m"
>
> I'm also using mac ... which I was wondering for a time if it was
> related to the mac jdk - but it seems that is not the case given others
> are seeing similar issues on other environments.
>
> ---
> Joe
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
>
>
>
>
>
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
