You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Joe Bohn <jo...@gmail.com> on 2010/09/15 16:28:42 UTC
building Apache Aries trunk from the top level pom
I seem to be having lots of problems building Apache Aries trunk from
the top level pom because of test errors. And, the more tests we add
the worse the process becomes. For me it is virtually impossible to
build. Once in a while I'll get lucky and things will actually work.
However, most of the time it seems there are test failures somewhere
along the way. The failure is often a timeout waiting for a service.
However, there are a large number of other (strange) failures such as
InvocationTargetExceptions, invalid state, NPEs, etc... that are
becoming more common.
When attempting to run a build from the top level a test that passes on
one attempt will fail on the next and the one that failed on the last
run will pass on the next (if the build even gets that far). All in
all, it is pretty much impossible to build from the top level.
The only success that I have in building all of Apache Aries is to build
each module individually in the order specified in the top level pom
(which I think is now correct). As I hit failures I rebuild just that
module until successful and then I move on to the next module.
So this raises 2 questions:
1) Am I the only one seeing these types of problems? If it is just me
then I guess I just need to figure out what is wrong with my environment.
2) If it is more wide spread then it seems to me that we might have
issues that we need to address. Certainly we are dealing with a dynamic
system with loose coupling and there are very likely timing scenarios
that will arise occasionally. However, the frequency and variety of
failures I'm seeing makes me wonder if we have larger timing or
synchronization issues that have not yet been addressed. Do you agree?
If so, then we need to come up with some way to isolate and resolve
these issues.
Joe
Re: building Apache Aries trunk from the top level pom
Posted by Emily Jiang <EM...@uk.ibm.com>.
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 <jo...@gmail.com>
To: aries-dev@incubator.apache.org
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<zo...@gmail.com> 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<jo...@gmail.com> 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<EM...@uk.ibm.com> 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<hr...@gmail.com>
>>>>>>> To: aries-dev@incubator.apache.org
>>>>>>> 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<EM...@uk.ibm.com>
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<jo...@gmail.com>
>>>>>>>> To: aries-dev@incubator.apache.org
>>>>>>>> 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<cu...@uk.ibm.com>
>>>>>>>>> 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
Re: building Apache Aries trunk from the top level pom
Posted by Emily Jiang <EM...@uk.ibm.com>.
I have not seen the application itest failures recently. I will check out
the source and run the build a few times to see whether I can reproduce
the problem.
Regards
Emily
From: Alasdair Nottingham <no...@apache.org>
To: aries-dev@incubator.apache.org
Date: 22/09/2010 15:42
Subject: Re: building Apache Aries trunk from the top level pom
Sent by: alasdair.nottingham@gmail.com
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 <zo...@gmail.com> 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<jo...@gmail.com> 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<EM...@uk.ibm.com>
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<hr...@gmail.com>
>>>>>> To: aries-dev@incubator.apache.org
>>>>>> 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<EM...@uk.ibm.com>
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<jo...@gmail.com>
>>>>>>> To: aries-dev@incubator.apache.org
>>>>>>> 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<cu...@uk.ibm.com>
>>>>>>>> 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
>>>>
>>>
>>
>>
>
>
--
Alasdair Nottingham
not@apache.org
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
Re: building Apache Aries trunk from the top level pom
Posted by Holly Cummins <cu...@uk.ibm.com>.
Joe said:
> 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.
It's a shame these issues don't turn up in the main builds. It seems
perverse, but I wonder if it's worth running the Hudson builds in two
modes - a 'people with new shiny laptops' mode and a 'people with old
laptops' mode. We could do this by applying load to the system while the
build was running, or perhaps we might be able to find an open source
concurrency testing tool. The results might drive us crazy with
intermittent failures for a while, but perhaps in the long run it would
get us to a stage where an arbitrary developer could do a checkout from
subversion and get a clean maven build first time - which has to be our
long term goal, I imagine?
Holly
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
Re: building Apache Aries trunk from the top level pom
Posted by Joe Bohn <jo...@gmail.com>.
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<zo...@gmail.com> 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<jo...@gmail.com> 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<EM...@uk.ibm.com> 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<hr...@gmail.com>
>>>>>>> To: aries-dev@incubator.apache.org
>>>>>>> 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<EM...@uk.ibm.com> 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<jo...@gmail.com>
>>>>>>>> To: aries-dev@incubator.apache.org
>>>>>>>> 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<cu...@uk.ibm.com>
>>>>>>>>> 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
Re: building Apache Aries trunk from the top level pom
Posted by Alasdair Nottingham <no...@apache.org>.
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 <zo...@gmail.com> 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<jo...@gmail.com> 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<EM...@uk.ibm.com> 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<hr...@gmail.com>
>>>>>> To: aries-dev@incubator.apache.org
>>>>>> 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<EM...@uk.ibm.com> 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<jo...@gmail.com>
>>>>>>> To: aries-dev@incubator.apache.org
>>>>>>> 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<cu...@uk.ibm.com>
>>>>>>>> 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
>>>>
>>>
>>
>>
>
>
--
Alasdair Nottingham
not@apache.org
Re: building Apache Aries trunk from the top level pom
Posted by zoe slattery <zo...@gmail.com>.
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<jo...@gmail.com> 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<EM...@uk.ibm.com> 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<hr...@gmail.com>
>>>>> To: aries-dev@incubator.apache.org
>>>>> 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<EM...@uk.ibm.com> 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<jo...@gmail.com>
>>>>>> To: aries-dev@incubator.apache.org
>>>>>> 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<cu...@uk.ibm.com>
>>>>>>> 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
>>>
>>
>
>
Re: building Apache Aries trunk from the top level pom
Posted by Joe Bohn <jo...@gmail.com>.
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<jo...@gmail.com> 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<EM...@uk.ibm.com> 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<hr...@gmail.com>
>>>> To: aries-dev@incubator.apache.org
>>>> 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<EM...@uk.ibm.com> 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<jo...@gmail.com>
>>>>> To: aries-dev@incubator.apache.org
>>>>> 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<cu...@uk.ibm.com>
>>>>>> 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
Re: building Apache Aries trunk from the top level pom
Posted by Hannah Ramlee <hr...@gmail.com>.
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 <jo...@gmail.com> 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<EM...@uk.ibm.com> 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<hr...@gmail.com>
>>> To: aries-dev@incubator.apache.org
>>> 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<EM...@uk.ibm.com> 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<jo...@gmail.com>
>>>> To: aries-dev@incubator.apache.org
>>>> 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<cu...@uk.ibm.com>
>>>>> 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
>
Re: building Apache Aries trunk from the top level pom
Posted by Joe Bohn <jo...@gmail.com>.
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<EM...@uk.ibm.com> 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<hr...@gmail.com>
>> To: aries-dev@incubator.apache.org
>> 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<EM...@uk.ibm.com> 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<jo...@gmail.com>
>>> To: aries-dev@incubator.apache.org
>>> 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<cu...@uk.ibm.com> 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
Re: building Apache Aries trunk from the top level pom
Posted by Hannah Ramlee <hr...@gmail.com>.
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 <EM...@uk.ibm.com> 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 <hr...@gmail.com>
> To: aries-dev@incubator.apache.org
> 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 <EM...@uk.ibm.com> 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 <jo...@gmail.com>
> > To: aries-dev@incubator.apache.org
> > 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<cu...@uk.ibm.com> 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
>
>
>
>
>
>
Re: building Apache Aries trunk from the top level pom
Posted by Emily Jiang <EM...@uk.ibm.com>.
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 <hr...@gmail.com>
To: aries-dev@incubator.apache.org
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 <EM...@uk.ibm.com> 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 <jo...@gmail.com>
> To: aries-dev@incubator.apache.org
> 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<cu...@uk.ibm.com> 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
Re: building Apache Aries trunk from the top level pom
Posted by Hannah Ramlee <hr...@gmail.com>.
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 <EM...@uk.ibm.com> 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 <jo...@gmail.com>
> To: aries-dev@incubator.apache.org
> 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<cu...@uk.ibm.com> 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
>
>
>
>
>
>
Re: building Apache Aries trunk from the top level pom
Posted by Joe Bohn <jo...@gmail.com>.
Thank you Emily. I did pull the changes and rebuilt.
Indeed, I didn't have any application itest failures!
However, I did hit test failures in:
- Blueprint itests - QuiesceBlueprintTest (perhaps one of your references?)
- JPA itests - QuiesceJPATest (another quiesce test :-( )
- Blog itests - JdbcBlogSampleWithEbaTest
All of the failures look somewhat similar - a service timeout. But I
also see bundle resolution errors due to some package uses conflicts,
IllegalStateExceptions for an unregistered service, and
InvocationTargetExceptions in the output. I think the blog failure may
have only had the InvocationTargetException without the others referenced.
Joe
On 9/17/10 5:30 PM, Emily Jiang 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<jo...@gmail.com>
> To: aries-dev@incubator.apache.org
> 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<cu...@uk.ibm.com> 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
>
>
>
>
>
>
--
Joe
Re: building Apache Aries trunk from the top level pom
Posted by Emily Jiang <EM...@uk.ibm.com>.
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 <jo...@gmail.com>
To: aries-dev@incubator.apache.org
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<cu...@uk.ibm.com> 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
Re: building Apache Aries trunk from the top level pom
Posted by Joe Bohn <jo...@gmail.com>.
On 9/16/10 12:58 PM, Alasdair Nottingham wrote:
> On 16 September 2010 01:45, Holly Cummins<cu...@uk.ibm.com> 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
Re: building Apache Aries trunk from the top level pom
Posted by Mark Nuttall <mn...@apache.org>.
I run with -Xmx1500m and still get occasional OOM errors running a full
build as well as transient failures in the application itests.
On 16 September 2010 17:58, Alasdair Nottingham <no...@apache.org> wrote:
> On 16 September 2010 01:45, Holly Cummins <cu...@uk.ibm.com> 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.
>
> --
> Alasdair Nottingham
> not@apache.org
>
Re: building Apache Aries trunk from the top level pom
Posted by Alasdair Nottingham <no...@apache.org>.
On 16 September 2010 01:45, Holly Cummins <cu...@uk.ibm.com> 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.
--
Alasdair Nottingham
not@apache.org
Re: building Apache Aries trunk from the top level pom
Posted by Holly Cummins <cu...@uk.ibm.com>.
Joe wrote:
> For example, here are some real life results:
> - mvn clean from root
> - remove aries artifacts from maven local repo to ensure a clean
> starting point (rm -rf ./m2/repository/org/apache/aries )
> - mvn install from root
> - failures in application tests - IsolatedRuntimeTest, UpdateAppTest,
> OBRResolverTest, and OBRResolverAdvancedTest
[...]
This is very similar to what I'm seeing. Failures every single time, but
it feels like the same test never fails twice.
I believe that the quiesce tests in particular do have some concrete
timing criteria - "has everything managed to quiesce before the timeout?"
and so on.
The fact that they work reliably when run individually makes me wonder if
the performance of the build gets slower as it progresses through the
child components, and that means some tests are running slowly enough to
hit timing glitches. This could be heap fragmentation - in which case
running with a bigger heap could help. It could be that the Hudson builds
are running with a larger heap, or it could be that the absence of other
processes on the machine means the memory and disk caches are staying
clean enough that the performance is ok?
I wonder if running with a bigger heap would help?
Holly
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
Re: building Apache Aries trunk from the top level pom
Posted by Emily Jiang <EM...@uk.ibm.com>.
I am looking at the application itest failures now and try to fix it.
Many thanks and kindest regards,
Emily
===========================
Emily Jiang
From: Joe Bohn <jo...@gmail.com>
To: aries-dev@incubator.apache.org
Date: 16/09/2010 13:03
Subject: Re: building Apache Aries trunk from the top level pom
That's my understanding as well regarding -fae. It isn't that maven
does anything different as it builds - it's just that using -fae or -fn
causes the build to continue even when a failure is encountered. In the
scenario I spelled out below (without using -fae or -fn) the failure
causes the build to terminate immediately. You only get a complete
image of all modules when everything succeeds in a single run (which
practically never happens for me but seems to regularly happen on Hudson).
Joe
On 9/16/10 12:51 AM, Alasdair Nottingham wrote:
> As I understand it using -fae just says keep going if a failure occurs,
it doesn't change the way maven works.
>
> I ran with MFN clean install 4-5 times and other than the application
tests everything worked. I'll try with mvn install tomorrow and let you
know though.
>
> Alasdair Nottingham
>
> On 15 Sep 2010, at 20:04, Joe Bohn<jo...@gmail.com> wrote:
>
>>
>> Thanks for the input.
>>
>> I think building with -fn or -fae is somewhat of a different scenario
and masks the problem. If -fn or -fae are necessary then we should update
the wiki to indicate this.
>>
>> In my case I was trying to run with just mvn install (per our
directions on the wiki and what I think Hudson is doing). When a failure
is encountered I run mvn install again on the top level pom (the
definition of insanity - doing the same thing and expecting different
results :-) ). This process gets you into a potentially never ending
cycle of failures as tests that passed on the earlier attempts fail on
subsequent attempts.
>>
>> For example, here are some real life results:
>> - mvn clean from root
>> - remove aries artifacts from maven local repo to ensure a clean
starting point (rm -rf ./m2/repository/org/apache/aries )
>> - mvn install from root
>> - failures in application tests - IsolatedRuntimeTest, UpdateAppTest,
OBRResolverTest, and OBRResolverAdvancedTest
>> - mvn install from root
>> - failures in application tests - IsolatedRuntimeTest, OBRResolverTest
and OBRResolverAdvancedTest
>> - mvn install from root
>> - failures in blueprint tests - BlueprintContainer2Test and
QuiesceBlueprintTest (NOTE: didn't even get to application this time)
>> - mvn install from root
>> - failure in blueprint tests - QuiesceBlueprintTest
>> - mvn install from root
>> - failure in transaction tests - InvalidTranAttributeTest
>> - mvn install from root
>> - failure in blueprint tests - BlueprintAnnotationTest
>> - mvn install from root
>> - failure in blueprint test - QuiesceBlueprintTest
>> - on and on it goes ... where it stops ... nobody knows :-)
>>
>> I honestly don't know how the Hudson builds are working. It seems that
the best anyone on this thread has reported thus far is 50% success (and
I'm not sure if that was for a successful top level build as I was
attempting and Hudson appears to accomplish most of the time or if it was
rebuilding just a failing module individually).
>>
>> Joe
>>
>>
>> On 9/15/10 7:25 PM, Alasdair Nottingham wrote:
>>> So I've just run the build many times with the following:
>>>
>>> export MAVEN_OPTS=-Xmx512m
>>> mvn -fae clean install
>>>
>>> and the only failures I get are in the Aries Application integration
>>> tests component, I haven't looked at details. I'm running on a mac
>>> with java 6.
>>>
>>> Alasdair
>>>
>>> On 15 September 2010 09:42, Emily Jiang<EM...@uk.ibm.com> wrote:
>>>> For me, two areas are constantly failing: blueprint itests:
>>>> quiesceBlueprintTests particularly failed very often followed by some
of
>>>> application itests.
>>>>
>>>> Many thanks and kindest regards,
>>>> Emily
>>>> ===========================
>>>> Emily Jiang
>>>> WebSphere ESB Foundation Technologies
>>>>
>>>> MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN
>>>> Phone: +44 (0)1962 816278 Internal: 246278
>>>>
>>>> Email: emijiang@uk.ibm.com
>>>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>>>
>>>>
>>>>
>>>>
>>>> From: Mark Nuttall<mn...@apache.org>
>>>> To: aries-dev@incubator.apache.org
>>>> Date: 15/09/2010 17:20
>>>> Subject: Re: building Apache Aries trunk from the top level
pom
>>>>
>>>>
>>>>
>>>> I too find the application itests particularly flaky on a local mvn
>>>> command
>>>> line. I spent most of today trying to debug the sometimes-failing
tests: I
>>>> couldn't get any to fail under a debugger, and couldn't work out from
the
>>>> trace why any had failed otherwise :(
>>>>
>>>> Emily, Chris and I are going to be making changes to the application
>>>> provisioning and runtime areas for a while yet. I'm sorry if we've
>>>> introduced further problems in this area. I do think it's timing
related
>>>> based on today's investigations.
>>>>
>>>> Mark
>>>>
>>>> On 15 September 2010 17:03, Valentin Mahrwald
>>>> <vm...@googlemail.com>wrote:
>>>>
>>>>> I just checked and had a 50% success rate :)
>>>>>
>>>>> I have found some of the new tests in the application itest project
are
>>>>> flaky (maybe the timeouts are not big enough). But the rest seems to
>>>> work
>>>>> for me.
>>>>>
>>>>> Valentin
>>>>>
>>>>>
>>>>> On 15 Sep 2010, at 10:28, Joe Bohn wrote:
>>>>>
>>>>>>
>>>>>> I seem to be having lots of problems building Apache Aries trunk
from
>>>> the
>>>>> top level pom because of test errors. And, the more tests we add
the
>>>> worse
>>>>> the process becomes. For me it is virtually impossible to build.
Once
>>>> in a
>>>>> while I'll get lucky and things will actually work. However, most of
the
>>>>> time it seems there are test failures somewhere along the way. The
>>>> failure
>>>>> is often a timeout waiting for a service. However, there are a large
>>>> number
>>>>> of other (strange) failures such as InvocationTargetExceptions,
invalid
>>>>> state, NPEs, etc... that are becoming more common.
>>>>>>
>>>>>> When attempting to run a build from the top level a test that
passes
>>>> on
>>>>> one attempt will fail on the next and the one that failed on the
last
>>>> run
>>>>> will pass on the next (if the build even gets that far). All in
all, it
>>>> is
>>>>> pretty much impossible to build from the top level.
>>>>>>
>>>>>> The only success that I have in building all of Apache Aries is to
>>>> build
>>>>> each module individually in the order specified in the top level pom
>>>> (which
>>>>> I think is now correct). As I hit failures I rebuild just that
module
>>>> until
>>>>> successful and then I move on to the next module.
>>>>>>
>>>>>> So this raises 2 questions:
>>>>>> 1) Am I the only one seeing these types of problems? If it is just
me
>>>>> then I guess I just need to figure out what is wrong with my
>>>> environment.
>>>>>>
>>>>>> 2) If it is more wide spread then it seems to me that we might have
>>>>> issues that we need to address. Certainly we are dealing with a
dynamic
>>>>> system with loose coupling and there are very likely timing
scenarios
>>>> that
>>>>> will arise occasionally. However, the frequency and variety of
failures
>>>> I'm
>>>>> seeing makes me wonder if we have larger timing or synchronization
>>>> issues
>>>>> that have not yet been addressed. Do you agree? If so, then we
need to
>>>>> come up with some way to isolate and resolve these issues.
>>>>>>
>>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> 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
Re: building Apache Aries trunk from the top level pom
Posted by Joe Bohn <jo...@gmail.com>.
That's my understanding as well regarding -fae. It isn't that maven
does anything different as it builds - it's just that using -fae or -fn
causes the build to continue even when a failure is encountered. In the
scenario I spelled out below (without using -fae or -fn) the failure
causes the build to terminate immediately. You only get a complete
image of all modules when everything succeeds in a single run (which
practically never happens for me but seems to regularly happen on Hudson).
Joe
On 9/16/10 12:51 AM, Alasdair Nottingham wrote:
> As I understand it using -fae just says keep going if a failure occurs, it doesn't change the way maven works.
>
> I ran with MFN clean install 4-5 times and other than the application tests everything worked. I'll try with mvn install tomorrow and let you know though.
>
> Alasdair Nottingham
>
> On 15 Sep 2010, at 20:04, Joe Bohn<jo...@gmail.com> wrote:
>
>>
>> Thanks for the input.
>>
>> I think building with -fn or -fae is somewhat of a different scenario and masks the problem. If -fn or -fae are necessary then we should update the wiki to indicate this.
>>
>> In my case I was trying to run with just mvn install (per our directions on the wiki and what I think Hudson is doing). When a failure is encountered I run mvn install again on the top level pom (the definition of insanity - doing the same thing and expecting different results :-) ). This process gets you into a potentially never ending cycle of failures as tests that passed on the earlier attempts fail on subsequent attempts.
>>
>> For example, here are some real life results:
>> - mvn clean from root
>> - remove aries artifacts from maven local repo to ensure a clean starting point (rm -rf ./m2/repository/org/apache/aries )
>> - mvn install from root
>> - failures in application tests - IsolatedRuntimeTest, UpdateAppTest, OBRResolverTest, and OBRResolverAdvancedTest
>> - mvn install from root
>> - failures in application tests - IsolatedRuntimeTest, OBRResolverTest and OBRResolverAdvancedTest
>> - mvn install from root
>> - failures in blueprint tests - BlueprintContainer2Test and QuiesceBlueprintTest (NOTE: didn't even get to application this time)
>> - mvn install from root
>> - failure in blueprint tests - QuiesceBlueprintTest
>> - mvn install from root
>> - failure in transaction tests - InvalidTranAttributeTest
>> - mvn install from root
>> - failure in blueprint tests - BlueprintAnnotationTest
>> - mvn install from root
>> - failure in blueprint test - QuiesceBlueprintTest
>> - on and on it goes ... where it stops ... nobody knows :-)
>>
>> I honestly don't know how the Hudson builds are working. It seems that the best anyone on this thread has reported thus far is 50% success (and I'm not sure if that was for a successful top level build as I was attempting and Hudson appears to accomplish most of the time or if it was rebuilding just a failing module individually).
>>
>> Joe
>>
>>
>> On 9/15/10 7:25 PM, Alasdair Nottingham wrote:
>>> So I've just run the build many times with the following:
>>>
>>> export MAVEN_OPTS=-Xmx512m
>>> mvn -fae clean install
>>>
>>> and the only failures I get are in the Aries Application integration
>>> tests component, I haven't looked at details. I'm running on a mac
>>> with java 6.
>>>
>>> Alasdair
>>>
>>> On 15 September 2010 09:42, Emily Jiang<EM...@uk.ibm.com> wrote:
>>>> For me, two areas are constantly failing: blueprint itests:
>>>> quiesceBlueprintTests particularly failed very often followed by some of
>>>> application itests.
>>>>
>>>> Many thanks and kindest regards,
>>>> Emily
>>>> ===========================
>>>> Emily Jiang
>>>> WebSphere ESB Foundation Technologies
>>>>
>>>> MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN
>>>> Phone: +44 (0)1962 816278 Internal: 246278
>>>>
>>>> Email: emijiang@uk.ibm.com
>>>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>>>
>>>>
>>>>
>>>>
>>>> From: Mark Nuttall<mn...@apache.org>
>>>> To: aries-dev@incubator.apache.org
>>>> Date: 15/09/2010 17:20
>>>> Subject: Re: building Apache Aries trunk from the top level pom
>>>>
>>>>
>>>>
>>>> I too find the application itests particularly flaky on a local mvn
>>>> command
>>>> line. I spent most of today trying to debug the sometimes-failing tests: I
>>>> couldn't get any to fail under a debugger, and couldn't work out from the
>>>> trace why any had failed otherwise :(
>>>>
>>>> Emily, Chris and I are going to be making changes to the application
>>>> provisioning and runtime areas for a while yet. I'm sorry if we've
>>>> introduced further problems in this area. I do think it's timing related
>>>> based on today's investigations.
>>>>
>>>> Mark
>>>>
>>>> On 15 September 2010 17:03, Valentin Mahrwald
>>>> <vm...@googlemail.com>wrote:
>>>>
>>>>> I just checked and had a 50% success rate :)
>>>>>
>>>>> I have found some of the new tests in the application itest project are
>>>>> flaky (maybe the timeouts are not big enough). But the rest seems to
>>>> work
>>>>> for me.
>>>>>
>>>>> Valentin
>>>>>
>>>>>
>>>>> On 15 Sep 2010, at 10:28, Joe Bohn wrote:
>>>>>
>>>>>>
>>>>>> I seem to be having lots of problems building Apache Aries trunk from
>>>> the
>>>>> top level pom because of test errors. And, the more tests we add the
>>>> worse
>>>>> the process becomes. For me it is virtually impossible to build. Once
>>>> in a
>>>>> while I'll get lucky and things will actually work. However, most of the
>>>>> time it seems there are test failures somewhere along the way. The
>>>> failure
>>>>> is often a timeout waiting for a service. However, there are a large
>>>> number
>>>>> of other (strange) failures such as InvocationTargetExceptions, invalid
>>>>> state, NPEs, etc... that are becoming more common.
>>>>>>
>>>>>> When attempting to run a build from the top level a test that passes
>>>> on
>>>>> one attempt will fail on the next and the one that failed on the last
>>>> run
>>>>> will pass on the next (if the build even gets that far). All in all, it
>>>> is
>>>>> pretty much impossible to build from the top level.
>>>>>>
>>>>>> The only success that I have in building all of Apache Aries is to
>>>> build
>>>>> each module individually in the order specified in the top level pom
>>>> (which
>>>>> I think is now correct). As I hit failures I rebuild just that module
>>>> until
>>>>> successful and then I move on to the next module.
>>>>>>
>>>>>> So this raises 2 questions:
>>>>>> 1) Am I the only one seeing these types of problems? If it is just me
>>>>> then I guess I just need to figure out what is wrong with my
>>>> environment.
>>>>>>
>>>>>> 2) If it is more wide spread then it seems to me that we might have
>>>>> issues that we need to address. Certainly we are dealing with a dynamic
>>>>> system with loose coupling and there are very likely timing scenarios
>>>> that
>>>>> will arise occasionally. However, the frequency and variety of failures
>>>> I'm
>>>>> seeing makes me wonder if we have larger timing or synchronization
>>>> issues
>>>>> that have not yet been addressed. Do you agree? If so, then we need to
>>>>> come up with some way to isolate and resolve these issues.
>>>>>>
>>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Joe
>
--
Joe
Re: building Apache Aries trunk from the top level pom
Posted by Alasdair Nottingham <no...@apache.org>.
As I understand it using -fae just says keep going if a failure occurs, it doesn't change the way maven works.
I ran with MFN clean install 4-5 times and other than the application tests everything worked. I'll try with mvn install tomorrow and let you know though.
Alasdair Nottingham
On 15 Sep 2010, at 20:04, Joe Bohn <jo...@gmail.com> wrote:
>
> Thanks for the input.
>
> I think building with -fn or -fae is somewhat of a different scenario and masks the problem. If -fn or -fae are necessary then we should update the wiki to indicate this.
>
> In my case I was trying to run with just mvn install (per our directions on the wiki and what I think Hudson is doing). When a failure is encountered I run mvn install again on the top level pom (the definition of insanity - doing the same thing and expecting different results :-) ). This process gets you into a potentially never ending cycle of failures as tests that passed on the earlier attempts fail on subsequent attempts.
>
> For example, here are some real life results:
> - mvn clean from root
> - remove aries artifacts from maven local repo to ensure a clean starting point (rm -rf ./m2/repository/org/apache/aries )
> - mvn install from root
> - failures in application tests - IsolatedRuntimeTest, UpdateAppTest, OBRResolverTest, and OBRResolverAdvancedTest
> - mvn install from root
> - failures in application tests - IsolatedRuntimeTest, OBRResolverTest and OBRResolverAdvancedTest
> - mvn install from root
> - failures in blueprint tests - BlueprintContainer2Test and QuiesceBlueprintTest (NOTE: didn't even get to application this time)
> - mvn install from root
> - failure in blueprint tests - QuiesceBlueprintTest
> - mvn install from root
> - failure in transaction tests - InvalidTranAttributeTest
> - mvn install from root
> - failure in blueprint tests - BlueprintAnnotationTest
> - mvn install from root
> - failure in blueprint test - QuiesceBlueprintTest
> - on and on it goes ... where it stops ... nobody knows :-)
>
> I honestly don't know how the Hudson builds are working. It seems that the best anyone on this thread has reported thus far is 50% success (and I'm not sure if that was for a successful top level build as I was attempting and Hudson appears to accomplish most of the time or if it was rebuilding just a failing module individually).
>
> Joe
>
>
> On 9/15/10 7:25 PM, Alasdair Nottingham wrote:
>> So I've just run the build many times with the following:
>>
>> export MAVEN_OPTS=-Xmx512m
>> mvn -fae clean install
>>
>> and the only failures I get are in the Aries Application integration
>> tests component, I haven't looked at details. I'm running on a mac
>> with java 6.
>>
>> Alasdair
>>
>> On 15 September 2010 09:42, Emily Jiang<EM...@uk.ibm.com> wrote:
>>> For me, two areas are constantly failing: blueprint itests:
>>> quiesceBlueprintTests particularly failed very often followed by some of
>>> application itests.
>>>
>>> Many thanks and kindest regards,
>>> Emily
>>> ===========================
>>> Emily Jiang
>>> WebSphere ESB Foundation Technologies
>>>
>>> MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN
>>> Phone: +44 (0)1962 816278 Internal: 246278
>>>
>>> Email: emijiang@uk.ibm.com
>>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>>
>>>
>>>
>>>
>>> From: Mark Nuttall<mn...@apache.org>
>>> To: aries-dev@incubator.apache.org
>>> Date: 15/09/2010 17:20
>>> Subject: Re: building Apache Aries trunk from the top level pom
>>>
>>>
>>>
>>> I too find the application itests particularly flaky on a local mvn
>>> command
>>> line. I spent most of today trying to debug the sometimes-failing tests: I
>>> couldn't get any to fail under a debugger, and couldn't work out from the
>>> trace why any had failed otherwise :(
>>>
>>> Emily, Chris and I are going to be making changes to the application
>>> provisioning and runtime areas for a while yet. I'm sorry if we've
>>> introduced further problems in this area. I do think it's timing related
>>> based on today's investigations.
>>>
>>> Mark
>>>
>>> On 15 September 2010 17:03, Valentin Mahrwald
>>> <vm...@googlemail.com>wrote:
>>>
>>>> I just checked and had a 50% success rate :)
>>>>
>>>> I have found some of the new tests in the application itest project are
>>>> flaky (maybe the timeouts are not big enough). But the rest seems to
>>> work
>>>> for me.
>>>>
>>>> Valentin
>>>>
>>>>
>>>> On 15 Sep 2010, at 10:28, Joe Bohn wrote:
>>>>
>>>>>
>>>>> I seem to be having lots of problems building Apache Aries trunk from
>>> the
>>>> top level pom because of test errors. And, the more tests we add the
>>> worse
>>>> the process becomes. For me it is virtually impossible to build. Once
>>> in a
>>>> while I'll get lucky and things will actually work. However, most of the
>>>> time it seems there are test failures somewhere along the way. The
>>> failure
>>>> is often a timeout waiting for a service. However, there are a large
>>> number
>>>> of other (strange) failures such as InvocationTargetExceptions, invalid
>>>> state, NPEs, etc... that are becoming more common.
>>>>>
>>>>> When attempting to run a build from the top level a test that passes
>>> on
>>>> one attempt will fail on the next and the one that failed on the last
>>> run
>>>> will pass on the next (if the build even gets that far). All in all, it
>>> is
>>>> pretty much impossible to build from the top level.
>>>>>
>>>>> The only success that I have in building all of Apache Aries is to
>>> build
>>>> each module individually in the order specified in the top level pom
>>> (which
>>>> I think is now correct). As I hit failures I rebuild just that module
>>> until
>>>> successful and then I move on to the next module.
>>>>>
>>>>> So this raises 2 questions:
>>>>> 1) Am I the only one seeing these types of problems? If it is just me
>>>> then I guess I just need to figure out what is wrong with my
>>> environment.
>>>>>
>>>>> 2) If it is more wide spread then it seems to me that we might have
>>>> issues that we need to address. Certainly we are dealing with a dynamic
>>>> system with loose coupling and there are very likely timing scenarios
>>> that
>>>> will arise occasionally. However, the frequency and variety of failures
>>> I'm
>>>> seeing makes me wonder if we have larger timing or synchronization
>>> issues
>>>> that have not yet been addressed. Do you agree? If so, then we need to
>>>> come up with some way to isolate and resolve these issues.
>>>>>
>>>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Joe
Re: building Apache Aries trunk from the top level pom
Posted by Joe Bohn <jo...@gmail.com>.
Thanks for the input.
I think building with -fn or -fae is somewhat of a different scenario
and masks the problem. If -fn or -fae are necessary then we should
update the wiki to indicate this.
In my case I was trying to run with just mvn install (per our directions
on the wiki and what I think Hudson is doing). When a failure is
encountered I run mvn install again on the top level pom (the definition
of insanity - doing the same thing and expecting different results :-)
). This process gets you into a potentially never ending cycle of
failures as tests that passed on the earlier attempts fail on subsequent
attempts.
For example, here are some real life results:
- mvn clean from root
- remove aries artifacts from maven local repo to ensure a clean
starting point (rm -rf ./m2/repository/org/apache/aries )
- mvn install from root
- failures in application tests - IsolatedRuntimeTest, UpdateAppTest,
OBRResolverTest, and OBRResolverAdvancedTest
- mvn install from root
- failures in application tests - IsolatedRuntimeTest, OBRResolverTest
and OBRResolverAdvancedTest
- mvn install from root
- failures in blueprint tests - BlueprintContainer2Test and
QuiesceBlueprintTest (NOTE: didn't even get to application this time)
- mvn install from root
- failure in blueprint tests - QuiesceBlueprintTest
- mvn install from root
- failure in transaction tests - InvalidTranAttributeTest
- mvn install from root
- failure in blueprint tests - BlueprintAnnotationTest
- mvn install from root
- failure in blueprint test - QuiesceBlueprintTest
- on and on it goes ... where it stops ... nobody knows :-)
I honestly don't know how the Hudson builds are working. It seems that
the best anyone on this thread has reported thus far is 50% success (and
I'm not sure if that was for a successful top level build as I was
attempting and Hudson appears to accomplish most of the time or if it
was rebuilding just a failing module individually).
Joe
On 9/15/10 7:25 PM, Alasdair Nottingham wrote:
> So I've just run the build many times with the following:
>
> export MAVEN_OPTS=-Xmx512m
> mvn -fae clean install
>
> and the only failures I get are in the Aries Application integration
> tests component, I haven't looked at details. I'm running on a mac
> with java 6.
>
> Alasdair
>
> On 15 September 2010 09:42, Emily Jiang<EM...@uk.ibm.com> wrote:
>> For me, two areas are constantly failing: blueprint itests:
>> quiesceBlueprintTests particularly failed very often followed by some of
>> application itests.
>>
>> Many thanks and kindest regards,
>> Emily
>> ===========================
>> Emily Jiang
>> WebSphere ESB Foundation Technologies
>>
>> MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN
>> Phone: +44 (0)1962 816278 Internal: 246278
>>
>> Email: emijiang@uk.ibm.com
>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>
>>
>>
>>
>> From: Mark Nuttall<mn...@apache.org>
>> To: aries-dev@incubator.apache.org
>> Date: 15/09/2010 17:20
>> Subject: Re: building Apache Aries trunk from the top level pom
>>
>>
>>
>> I too find the application itests particularly flaky on a local mvn
>> command
>> line. I spent most of today trying to debug the sometimes-failing tests: I
>> couldn't get any to fail under a debugger, and couldn't work out from the
>> trace why any had failed otherwise :(
>>
>> Emily, Chris and I are going to be making changes to the application
>> provisioning and runtime areas for a while yet. I'm sorry if we've
>> introduced further problems in this area. I do think it's timing related
>> based on today's investigations.
>>
>> Mark
>>
>> On 15 September 2010 17:03, Valentin Mahrwald
>> <vm...@googlemail.com>wrote:
>>
>>> I just checked and had a 50% success rate :)
>>>
>>> I have found some of the new tests in the application itest project are
>>> flaky (maybe the timeouts are not big enough). But the rest seems to
>> work
>>> for me.
>>>
>>> Valentin
>>>
>>>
>>> On 15 Sep 2010, at 10:28, Joe Bohn wrote:
>>>
>>>>
>>>> I seem to be having lots of problems building Apache Aries trunk from
>> the
>>> top level pom because of test errors. And, the more tests we add the
>> worse
>>> the process becomes. For me it is virtually impossible to build. Once
>> in a
>>> while I'll get lucky and things will actually work. However, most of the
>>> time it seems there are test failures somewhere along the way. The
>> failure
>>> is often a timeout waiting for a service. However, there are a large
>> number
>>> of other (strange) failures such as InvocationTargetExceptions, invalid
>>> state, NPEs, etc... that are becoming more common.
>>>>
>>>> When attempting to run a build from the top level a test that passes
>> on
>>> one attempt will fail on the next and the one that failed on the last
>> run
>>> will pass on the next (if the build even gets that far). All in all, it
>> is
>>> pretty much impossible to build from the top level.
>>>>
>>>> The only success that I have in building all of Apache Aries is to
>> build
>>> each module individually in the order specified in the top level pom
>> (which
>>> I think is now correct). As I hit failures I rebuild just that module
>> until
>>> successful and then I move on to the next module.
>>>>
>>>> So this raises 2 questions:
>>>> 1) Am I the only one seeing these types of problems? If it is just me
>>> then I guess I just need to figure out what is wrong with my
>> environment.
>>>>
>>>> 2) If it is more wide spread then it seems to me that we might have
>>> issues that we need to address. Certainly we are dealing with a dynamic
>>> system with loose coupling and there are very likely timing scenarios
>> that
>>> will arise occasionally. However, the frequency and variety of failures
>> I'm
>>> seeing makes me wonder if we have larger timing or synchronization
>> issues
>>> that have not yet been addressed. Do you agree? If so, then we need to
>>> come up with some way to isolate and resolve these issues.
>>>>
>>>> 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
>>
>>
>>
>>
>>
>>
>
>
>
--
Joe
Re: building Apache Aries trunk from the top level pom
Posted by Alasdair Nottingham <no...@apache.org>.
So I've just run the build many times with the following:
export MAVEN_OPTS=-Xmx512m
mvn -fae clean install
and the only failures I get are in the Aries Application integration
tests component, I haven't looked at details. I'm running on a mac
with java 6.
Alasdair
On 15 September 2010 09:42, Emily Jiang <EM...@uk.ibm.com> wrote:
> For me, two areas are constantly failing: blueprint itests:
> quiesceBlueprintTests particularly failed very often followed by some of
> application itests.
>
> Many thanks and kindest regards,
> Emily
> ===========================
> Emily Jiang
> WebSphere ESB Foundation Technologies
>
> MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN
> Phone: +44 (0)1962 816278 Internal: 246278
>
> Email: emijiang@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Mark Nuttall <mn...@apache.org>
> To: aries-dev@incubator.apache.org
> Date: 15/09/2010 17:20
> Subject: Re: building Apache Aries trunk from the top level pom
>
>
>
> I too find the application itests particularly flaky on a local mvn
> command
> line. I spent most of today trying to debug the sometimes-failing tests: I
> couldn't get any to fail under a debugger, and couldn't work out from the
> trace why any had failed otherwise :(
>
> Emily, Chris and I are going to be making changes to the application
> provisioning and runtime areas for a while yet. I'm sorry if we've
> introduced further problems in this area. I do think it's timing related
> based on today's investigations.
>
> Mark
>
> On 15 September 2010 17:03, Valentin Mahrwald
> <vm...@googlemail.com>wrote:
>
>> I just checked and had a 50% success rate :)
>>
>> I have found some of the new tests in the application itest project are
>> flaky (maybe the timeouts are not big enough). But the rest seems to
> work
>> for me.
>>
>> Valentin
>>
>>
>> On 15 Sep 2010, at 10:28, Joe Bohn wrote:
>>
>> >
>> > I seem to be having lots of problems building Apache Aries trunk from
> the
>> top level pom because of test errors. And, the more tests we add the
> worse
>> the process becomes. For me it is virtually impossible to build. Once
> in a
>> while I'll get lucky and things will actually work. However, most of the
>> time it seems there are test failures somewhere along the way. The
> failure
>> is often a timeout waiting for a service. However, there are a large
> number
>> of other (strange) failures such as InvocationTargetExceptions, invalid
>> state, NPEs, etc... that are becoming more common.
>> >
>> > When attempting to run a build from the top level a test that passes
> on
>> one attempt will fail on the next and the one that failed on the last
> run
>> will pass on the next (if the build even gets that far). All in all, it
> is
>> pretty much impossible to build from the top level.
>> >
>> > The only success that I have in building all of Apache Aries is to
> build
>> each module individually in the order specified in the top level pom
> (which
>> I think is now correct). As I hit failures I rebuild just that module
> until
>> successful and then I move on to the next module.
>> >
>> > So this raises 2 questions:
>> > 1) Am I the only one seeing these types of problems? If it is just me
>> then I guess I just need to figure out what is wrong with my
> environment.
>> >
>> > 2) If it is more wide spread then it seems to me that we might have
>> issues that we need to address. Certainly we are dealing with a dynamic
>> system with loose coupling and there are very likely timing scenarios
> that
>> will arise occasionally. However, the frequency and variety of failures
> I'm
>> seeing makes me wonder if we have larger timing or synchronization
> issues
>> that have not yet been addressed. Do you agree? If so, then we need to
>> come up with some way to isolate and resolve these issues.
>> >
>> > 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
>
>
>
>
>
>
--
Alasdair Nottingham
not@apache.org
Re: building Apache Aries trunk from the top level pom
Posted by Emily Jiang <EM...@uk.ibm.com>.
For me, two areas are constantly failing: blueprint itests:
quiesceBlueprintTests particularly failed very often followed by some of
application itests.
Many thanks and kindest regards,
Emily
===========================
Emily Jiang
WebSphere ESB Foundation Technologies
MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang@uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: Mark Nuttall <mn...@apache.org>
To: aries-dev@incubator.apache.org
Date: 15/09/2010 17:20
Subject: Re: building Apache Aries trunk from the top level pom
I too find the application itests particularly flaky on a local mvn
command
line. I spent most of today trying to debug the sometimes-failing tests: I
couldn't get any to fail under a debugger, and couldn't work out from the
trace why any had failed otherwise :(
Emily, Chris and I are going to be making changes to the application
provisioning and runtime areas for a while yet. I'm sorry if we've
introduced further problems in this area. I do think it's timing related
based on today's investigations.
Mark
On 15 September 2010 17:03, Valentin Mahrwald
<vm...@googlemail.com>wrote:
> I just checked and had a 50% success rate :)
>
> I have found some of the new tests in the application itest project are
> flaky (maybe the timeouts are not big enough). But the rest seems to
work
> for me.
>
> Valentin
>
>
> On 15 Sep 2010, at 10:28, Joe Bohn wrote:
>
> >
> > I seem to be having lots of problems building Apache Aries trunk from
the
> top level pom because of test errors. And, the more tests we add the
worse
> the process becomes. For me it is virtually impossible to build. Once
in a
> while I'll get lucky and things will actually work. However, most of the
> time it seems there are test failures somewhere along the way. The
failure
> is often a timeout waiting for a service. However, there are a large
number
> of other (strange) failures such as InvocationTargetExceptions, invalid
> state, NPEs, etc... that are becoming more common.
> >
> > When attempting to run a build from the top level a test that passes
on
> one attempt will fail on the next and the one that failed on the last
run
> will pass on the next (if the build even gets that far). All in all, it
is
> pretty much impossible to build from the top level.
> >
> > The only success that I have in building all of Apache Aries is to
build
> each module individually in the order specified in the top level pom
(which
> I think is now correct). As I hit failures I rebuild just that module
until
> successful and then I move on to the next module.
> >
> > So this raises 2 questions:
> > 1) Am I the only one seeing these types of problems? If it is just me
> then I guess I just need to figure out what is wrong with my
environment.
> >
> > 2) If it is more wide spread then it seems to me that we might have
> issues that we need to address. Certainly we are dealing with a dynamic
> system with loose coupling and there are very likely timing scenarios
that
> will arise occasionally. However, the frequency and variety of failures
I'm
> seeing makes me wonder if we have larger timing or synchronization
issues
> that have not yet been addressed. Do you agree? If so, then we need to
> come up with some way to isolate and resolve these issues.
> >
> > 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
Re: building Apache Aries trunk from the top level pom
Posted by Mark Nuttall <mn...@apache.org>.
I too find the application itests particularly flaky on a local mvn command
line. I spent most of today trying to debug the sometimes-failing tests: I
couldn't get any to fail under a debugger, and couldn't work out from the
trace why any had failed otherwise :(
Emily, Chris and I are going to be making changes to the application
provisioning and runtime areas for a while yet. I'm sorry if we've
introduced further problems in this area. I do think it's timing related
based on today's investigations.
Mark
On 15 September 2010 17:03, Valentin Mahrwald <vm...@googlemail.com>wrote:
> I just checked and had a 50% success rate :)
>
> I have found some of the new tests in the application itest project are
> flaky (maybe the timeouts are not big enough). But the rest seems to work
> for me.
>
> Valentin
>
>
> On 15 Sep 2010, at 10:28, Joe Bohn wrote:
>
> >
> > I seem to be having lots of problems building Apache Aries trunk from the
> top level pom because of test errors. And, the more tests we add the worse
> the process becomes. For me it is virtually impossible to build. Once in a
> while I'll get lucky and things will actually work. However, most of the
> time it seems there are test failures somewhere along the way. The failure
> is often a timeout waiting for a service. However, there are a large number
> of other (strange) failures such as InvocationTargetExceptions, invalid
> state, NPEs, etc... that are becoming more common.
> >
> > When attempting to run a build from the top level a test that passes on
> one attempt will fail on the next and the one that failed on the last run
> will pass on the next (if the build even gets that far). All in all, it is
> pretty much impossible to build from the top level.
> >
> > The only success that I have in building all of Apache Aries is to build
> each module individually in the order specified in the top level pom (which
> I think is now correct). As I hit failures I rebuild just that module until
> successful and then I move on to the next module.
> >
> > So this raises 2 questions:
> > 1) Am I the only one seeing these types of problems? If it is just me
> then I guess I just need to figure out what is wrong with my environment.
> >
> > 2) If it is more wide spread then it seems to me that we might have
> issues that we need to address. Certainly we are dealing with a dynamic
> system with loose coupling and there are very likely timing scenarios that
> will arise occasionally. However, the frequency and variety of failures I'm
> seeing makes me wonder if we have larger timing or synchronization issues
> that have not yet been addressed. Do you agree? If so, then we need to
> come up with some way to isolate and resolve these issues.
> >
> > Joe
>
>
Re: building Apache Aries trunk from the top level pom
Posted by Valentin Mahrwald <vm...@googlemail.com>.
I just checked and had a 50% success rate :)
I have found some of the new tests in the application itest project are flaky (maybe the timeouts are not big enough). But the rest seems to work for me.
Valentin
On 15 Sep 2010, at 10:28, Joe Bohn wrote:
>
> I seem to be having lots of problems building Apache Aries trunk from the top level pom because of test errors. And, the more tests we add the worse the process becomes. For me it is virtually impossible to build. Once in a while I'll get lucky and things will actually work. However, most of the time it seems there are test failures somewhere along the way. The failure is often a timeout waiting for a service. However, there are a large number of other (strange) failures such as InvocationTargetExceptions, invalid state, NPEs, etc... that are becoming more common.
>
> When attempting to run a build from the top level a test that passes on one attempt will fail on the next and the one that failed on the last run will pass on the next (if the build even gets that far). All in all, it is pretty much impossible to build from the top level.
>
> The only success that I have in building all of Apache Aries is to build each module individually in the order specified in the top level pom (which I think is now correct). As I hit failures I rebuild just that module until successful and then I move on to the next module.
>
> So this raises 2 questions:
> 1) Am I the only one seeing these types of problems? If it is just me then I guess I just need to figure out what is wrong with my environment.
>
> 2) If it is more wide spread then it seems to me that we might have issues that we need to address. Certainly we are dealing with a dynamic system with loose coupling and there are very likely timing scenarios that will arise occasionally. However, the frequency and variety of failures I'm seeing makes me wonder if we have larger timing or synchronization issues that have not yet been addressed. Do you agree? If so, then we need to come up with some way to isolate and resolve these issues.
>
> Joe
Re: building Apache Aries trunk from the top level pom
Posted by Joe Bohn <jo...@gmail.com>.
Thank you Holly & Zoe.
It may be related to the local repo. I have gotten into the habit to
cleaning my local repo of aries artifacts prior to building to verify
that the build order is correct and that I'm not using anything from a
previous build. Does anybody know if Hudson starts with a clean repo?
BTW, I'm seen these issues for a while (prior to last weekend) but they
have recently increased by an order of magnitude.
Joe
On 9/15/10 11:25 AM, zoe slattery wrote:
> On 15/09/2010 15:37, Holly Cummins wrote:
>> Hi Joe,
>>
>>
>>> When attempting to run a build from the top level a test that passes on
>>> one attempt will fail on the next and the one that failed on the last
>>> run will pass on the next (if the build even gets that far). All in
>>> all, it is pretty much impossible to build from the top level.
>> I have exactly the same problem. No one else was complaining about it, so
>> I assumed it was just me!
> No - I hit it at the weekend. I think it must be comparatively new
> because it was not an issue when I was testing the 0.2-incubating
> branch. I eventually got it to build by repeatedly running 'mvn install
> -fn' but did not have time to go back over the process and figure out
> what it was...although... I had just cleaned out my local mvn repo, not
> sure if that was relevant
>>
>>> So this raises 2 questions:
>>> 1) Am I the only one seeing these types of problems? If it is just me
>>> then I guess I just need to figure out what is wrong with my
>> environment.
>>
>> I have the same problem as well. However, I do wonder if it's in some way
>> environment-related, because the Hudson builds seem pretty stable. It
>> would be interesting to work out what's different between the Hudson
>> build
>> environment and my laptop. One thing that leaps out, of course, is that
>> there's other work running on my laptop, so that's perhaps evidence for
>> timing-related issues causing the problems we're seeing.
>>
>> Holly
>>
>>
>>
>>
>>
>>
>>
>>
>> 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
Re: building Apache Aries trunk from the top level pom
Posted by zoe slattery <zo...@gmail.com>.
On 15/09/2010 15:37, Holly Cummins wrote:
> Hi Joe,
>
>
>> When attempting to run a build from the top level a test that passes on
>> one attempt will fail on the next and the one that failed on the last
>> run will pass on the next (if the build even gets that far). All in
>> all, it is pretty much impossible to build from the top level.
> I have exactly the same problem. No one else was complaining about it, so
> I assumed it was just me!
No - I hit it at the weekend. I think it must be comparatively new
because it was not an issue when I was testing the 0.2-incubating
branch. I eventually got it to build by repeatedly running 'mvn install
-fn' but did not have time to go back over the process and figure out
what it was...although... I had just cleaned out my local mvn repo, not
sure if that was relevant
>
>> So this raises 2 questions:
>> 1) Am I the only one seeing these types of problems? If it is just me
>> then I guess I just need to figure out what is wrong with my
> environment.
>
> I have the same problem as well. However, I do wonder if it's in some way
> environment-related, because the Hudson builds seem pretty stable. It
> would be interesting to work out what's different between the Hudson build
> environment and my laptop. One thing that leaps out, of course, is that
> there's other work running on my laptop, so that's perhaps evidence for
> timing-related issues causing the problems we're seeing.
>
> Holly
>
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
Re: building Apache Aries trunk from the top level pom
Posted by Holly Cummins <cu...@uk.ibm.com>.
Hi Joe,
> When attempting to run a build from the top level a test that passes on
> one attempt will fail on the next and the one that failed on the last
> run will pass on the next (if the build even gets that far). All in
> all, it is pretty much impossible to build from the top level.
I have exactly the same problem. No one else was complaining about it, so
I assumed it was just me!
> So this raises 2 questions:
> 1) Am I the only one seeing these types of problems? If it is just me
> then I guess I just need to figure out what is wrong with my
environment.
I have the same problem as well. However, I do wonder if it's in some way
environment-related, because the Hudson builds seem pretty stable. It
would be interesting to work out what's different between the Hudson build
environment and my laptop. One thing that leaps out, of course, is that
there's other work running on my laptop, so that's perhaps evidence for
timing-related issues causing the problems we're seeing.
Holly
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