hmmm. I am hitting the following Quiesce itest a couple of times today:(.
-------------------------------------------------------------------------------
Test set: org.apache.aries.quiesce.manager.itest.QuiesceManagerTest
-------------------------------------------------------------------------------
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 56.951
sec <<< FAILURE!
testOverlappedQuiesces [equinox
/3.5.0](org.apache.aries.quiesce.manager.itest.QuiesceManagerTest) Time
elapsed: 4.695 sec <<< FAILURE!
java.lang.AssertionError: Participant 3 should finished twice as it should
have waited a short time before returning from it's two quiesce requests
at org.junit.Assert.fail(Assert.java:74)
at org.junit.Assert.assertTrue(Assert.java:37)
at
org.apache.aries.quiesce.manager.itest.QuiesceManagerTest.testOverlappedQuiesces(QuiesceManagerTest.java:281)
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: Joe Bohn <[email protected]>
To: [email protected]
Date: 22/09/2010 16:21
Subject: Re: building Apache Aries trunk from the top level pom
I'm certain it is timing issues. I have a mac as well but only 2 cores
so perhaps that is why I hit problems so easily and so frequently.
Joe
On 9/22/10 10:41 AM, Alasdair Nottingham wrote:
> I don't have any problems. I'm wondering if it is because my mac has 4
> cores. If so it would definitely point to a timing issue to these
> problems.
>
> On 22 September 2010 07:36, zoe slattery<[email protected]> wrote:
>> Here are my failures today, with a clean checkout.
>>
>> 1)
>> Running org.apache.aries.transaction.itests.InvalidTranAttributeTest
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.704
sec
>> <<< FAILURE!
>>
>> 2)
>> Running org.apache.aries.application.runtime.itests.UpdateAppTest
>> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 59.503
sec
>> <<< FAILURE!
>>
>> 3)
>> I got lucky!
>>
>> Zoė
>>
>>
>>
>>> Hi Hannah,
>>>
>>> It would be difficult for you to access the machine (my laptop) ...
and
>>> I'm not yet certain if this is something that will be easy to
reproduce or
>>> not. I'll post back here if it appears to be consistent. On a
subsequent
>>> build I didn't hit this failure again.
>>>
>>> That said, I'm still hitting quite a number of build failures - not
just
>>> this one. Most of them are the timeout waiting for service failures
that
>>> I've gotten used to ignoring. There are a few that look a bit more
>>> suspicious (such as this one).
>>>
>>> Joe
>>>
>>> On 9/21/10 10:51 AM, Hannah Ramlee wrote:
>>>>
>>>> Hi Joe,
>>>>
>>>> Thanks for the information. There are four blueprint queiesce tests
all
>>>> bundled up into QuiesceBlueprintTest.
>>>> Emily reported previously that she was seeing errors in
>>>> testMultiBundleQuiesce. My change in ARIES-412 was for this test, as
I
>>>> managed to reproduce the failure. However, the test you're reporting
as
>>>> failing below is a different one - testMultiRequestQuiesce. I'm not
>>>> seeing
>>>> this failing on my machine, with or without the fix, so I didn't put
in
>>>> the
>>>> corresponding change for that one.
>>>>
>>>> I have very strong suspicions that this is a test timing issue, which
>>>> isn't
>>>> ideal :(
>>>> I can suggest a patch for this... however as I can't reproduce it
myself,
>>>> would it be possible to try it on an affected machine?
>>>>
>>>> Thanks,
>>>> Hannah
>>>>
>>>>
>>>>
>>>> On 21 September 2010 15:24, Joe Bohn<[email protected]> wrote:
>>>>
>>>>>
>>>>> It may not be directly related to Hannah's changes or fix ... but I
just
>>>>> hit another failure in the QuiesceBlueprintTest even with the fix
for
>>>>> ARIES-412 applied. Also, I don't know how consistent this failure
is
>>>>> since
>>>>> this is the first time I built with the fix and a clean repo ... but
>>>>> here is
>>>>> some information I see in the output log:
>>>>>
>>>>>
>>>>> [System Bundle Shutdown] DEBUG
>>>>> org.apache.aries.blueprint.container.BlueprintEventDispatcher -
Sending
>>>>> blueprint container event BlueprintEvent[type=DESTROYING] for bundle
>>>>> org.apache.aries.blueprint.testquiescebundle
>>>>> [System Bundle Shutdown] DEBUG
>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher - Releasing bundle
>>>>> [org.apache.aries.blueprint.testquiescebundle]
>>>>> [Framework Event Dispatcher] DEBUG org.apache.aries.blueprint -
>>>>> FrameworkEvent ERROR
>>>>> java.lang.IllegalStateException: The service has been unregistered
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:204)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:800)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.container.BlueprintExtender.destroyContext(BlueprintExtender.java:221)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:213)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:402)
>>>>> at
>>>>>
>>>>>
org.apache.aries.util.tracker.InternalRecursiveBundleTracker.modifiedBundle(InternalRecursiveBundleTracker.java:89)
>>>>> at
>>>>>
>>>>>
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:453)
>>>>> at
>>>>>
org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:237)
>>>>> at
>>>>>
>>>>>
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:413)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:916)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.publishBundleEventPrivileged(Framework.java:1350)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1301)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:470)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:546)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1098)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:593)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:261)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:216)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:266)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:685)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:583)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.InternalSystemBundle$1.run(InternalSystemBundle.java:243)
>>>>> at java.lang.Thread.run(Thread.java:637)
>>>>> [System Bundle Shutdown] DEBUG
>>>>> org.apache.aries.blueprint.container.BlueprintExtender - Destroying
>>>>> BlueprintContainer for bundle org.apache.aries.blueprint.testbundlea
>>>>> [Framework Event Dispatcher] DEBUG
>>>>> org.apache.aries.blueprint.testquiescebundle - BundleEvent STOPPED
>>>>> [System Bundle Shutdown] DEBUG
>>>>> org.apache.aries.blueprint.container.BlueprintEventDispatcher -
Sending
>>>>> blueprint container event BlueprintEvent[type=DESTROYING] for bundle
>>>>> org.apache.aries.blueprint.testbundlea
>>>>> [Framework Event Dispatcher] DEBUG org.apache.aries.blueprint -
>>>>> FrameworkEvent ERROR
>>>>> java.lang.IllegalStateException: The service has been unregistered
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:204)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:800)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.container.BlueprintExtender.destroyContext(BlueprintExtender.java:221)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:213)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:402)
>>>>> at
>>>>>
>>>>>
org.apache.aries.util.tracker.InternalRecursiveBundleTracker.modifiedBundle(InternalRecursiveBundleTracker.java:89)
>>>>> at
>>>>>
>>>>>
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:453)
>>>>> at
>>>>>
org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:237)
>>>>> at
>>>>>
>>>>>
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:413)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:916)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.publishBundleEventPrivileged(Framework.java:1350)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1301)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:470)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:546)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1098)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:593)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:261)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:216)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:266)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:685)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:583)
>>>>> at
>>>>>
>>>>>
org.eclipse.osgi.framework.internal.core.InternalSystemBundle$1.run(InternalSystemBundle.java:243)
>>>>> at java.lang.Thread.run(Thread.java:637)
>>>>> [System Bundle Shutdown] DEBUG
>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher - Releasing bundle
>>>>> [org.apache.aries.blueprint.testbundlea]
>>>>> [Framework Event Dispatcher] DEBUG
>>>>> org.apache.aries.blueprint.testbundlea -
>>>>> BundleEvent STOPPED
>>>>>
>>>>>
>>>>> .... skipping lots of apparently normal messages ...
>>>>>
>>>>>
>>>>> [Blueprint Extender: 1] DEBUG
>>>>> org.apache.aries.blueprint.container.BlueprintEventDispatcher -
Sending
>>>>> blueprint container event BlueprintEvent[type=CREATED] for bundle
>>>>> org.apache.aries.blueprint
>>>>> [Blueprint Extender: 1] DEBUG
>>>>> org.apache.aries.blueprint.container.BlueprintContainerImpl -
Running
>>>>> blueprint container for bundle org.apache.aries.blueprint in state
>>>>> Created
>>>>> Woken up
>>>>> Woken up
>>>>> [RMI TCP Connection(1)-9.37.240.141] DEBUG sun.rmi.server.call - RMI
TCP
>>>>> Connection(1)-9.37.240.141: [9.37.240.141] exception:
>>>>> java.lang.reflect.InvocationTargetException
>>>>>
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
>>>>> at
>>>>>
>>>>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>
>>>>> at
>>>>>
>>>>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>>
>>>>> 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:39)
>>>>>
>>>>> at
>>>>>
>>>>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>> at
>>>>> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
>>>>>
>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:159)
>>>>> at java.security.AccessController.doPrivileged(Native
Method)
>>>>>
>>>>> 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:886)
>>>>> at
>>>>>
>>>>>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>>>> at java.lang.Thread.run(Thread.java:637)
>>>>> Caused by: java.lang.reflect.InvocationTargetException
>>>>>
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
>>>>> at
>>>>>
>>>>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>
>>>>> at
>>>>>
>>>>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>>
>>>>> 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)
>>>>> ... 19 more
>>>>> Caused by: junit.framework.AssertionFailedError: Quiesce callback
should
>>>>> have occurred once; calls should be 1, but it is 0
>>>>>
>>>>> at junit.framework.Assert.fail(Assert.java:47)
>>>>> at junit.framework.Assert.assertTrue(Assert.java:20)
>>>>> at
>>>>>
>>>>>
org.apache.aries.blueprint.itests.QuiesceBlueprintTest.testMultiRequestQuiesce(QuiesceBlueprintTest.java:373)
>>>>> ... 25 more
>>>>> [org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer] :
>>>>> Shutting down the test container (Pax Runner)
>>>>> [RMI TCP Connection(1)-9.37.240.141] DEBUG sun.rmi.transport.tcp -
RMI
>>>>> TCP
>>>>> Connection(1)-9.37.240.141: (port 1099) op = 80
>>>>> [org.ops4j.pax.runner.platform.DefaultJavaRunner] : Waiting for
>>>>> framework
>>>>> exit.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 9/21/10 8:39 AM, Hannah Ramlee wrote:
>>>>>
>>>>>> Hi Emily,
>>>>>>
>>>>>> Thanks for the extra information. I managed to reproduce this a few
>>>>>> times,
>>>>>> and put in some changes to the blueprint quiesce test which has
stopped
>>>>>> the
>>>>>> issue on my machine.
>>>>>>
>>>>>> I have attached the patch to jira ARIES-412.
>>>>>>
>>>>>> Thanks,
>>>>>> Hannah
>>>>>>
>>>>>> On 19 September 2010 22:55, Emily Jiang<[email protected]> wrote:
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
--
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
