That's what I thought. I'll create a new patch for aries-327 later today. Thanks, Bartek
2010/5/31 Alasdair Nottingham <[email protected]>: > Not sure how many threads may be used, but the blueprint is definitely > processed asynchronously to the thread that is used to notify that the bundle > is active, or whatever the exact state is it has to watch for. > > Alasdair Nottingham > > On 30 May 2010, at 22:45, "Bartosz Kowalewski (JIRA)" <[email protected]> wrote: > >> >> [ >> https://issues.apache.org/jira/browse/ARIES-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873497#action_12873497 >> ] >> >> Bartosz Kowalewski commented on ARIES-327: >> ------------------------------------------ >> >> I forgot to add one note. As far as I know, the Blueprint extender processes >> bundles asynchronously in several threads. Am I right? I haven't analyzed >> the extender in detail, so I'm not 100% sure. >> If the extender processes bundles in parallel, the attached patch will only >> decrease probability of reproducing issue with OBRResolverTest. In order to >> completely eliminate this issue, we would have to postpone initialization of >> some bundles (tell Pax Exam not to start them) and start them manually later >> - from the inside of the test method. >> >> Bartek >> >>> From time to time OBRResolverTest causes Aries build to fail >>> ------------------------------------------------------------ >>> >>> Key: ARIES-327 >>> URL: https://issues.apache.org/jira/browse/ARIES-327 >>> Project: Aries >>> Issue Type: Bug >>> Components: Application >>> Affects Versions: 0.1 >>> Reporter: Bartosz Kowalewski >>> Attachments: ARIES-327.diff >>> >>> >>> A good example of a build that failed because of this issue is build #497 >>> on Hudson. >>> The error log looks like this: >>> [transitive.bundle.by.reference;{deployed-version->1.0.0}] expected:<2> but >>> was:<1> >>> java.lang.AssertionError: >>> [transitive.bundle.by.reference;{deployed-version->1.0.0}] expected:<2> but >>> was:<1> >>> at org.junit.Assert.fail(Assert.java:74) >>> at org.junit.Assert.failNotEquals(Assert.java:448) >>> at org.junit.Assert.assertEquals(Assert.java:102) >>> at org.junit.Assert.assertEquals(Assert.java:323) >>> at >>> org.apache.aries.application.runtime.itests.OBRResolverTest.testBlogApp(OBRResolverTest.java:187) >>> 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) >>> 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:619) >>> The second test method defined in this test class also fails from time to >>> time. >>> This issue is caused by the fact that AriesApplicationManagerImpl is >>> sometimes provided with a wrong service instance for the >>> AriesApplicationResolver interface. Instead of obr-resolver, we get >>> no-op-resolver. >>> When the test fails, in the logs we can see: >>> [RMI TCP Connection(1)-192.168.33.2] DEBUG >>> org.apache.aries.blueprint.container.ServiceRecipe - Retrieving service for >>> bundle org.apache.aries.application.management_0.2.0.incubating-SNAPSHOT >>> [10] and service registration >>> {org.apache.aries.application.management.AriesApplicationResolver}={osgi.service.blueprint.compname=no-op-resolver, >>> service.ranking=-1, service.id=35} >>> When it succeeds: >>> [RMI TCP Connection(1)-192.168.33.2] DEBUG >>> org.apache.aries.blueprint.container.ServiceRecipe - Retrieving service for >>> bundle org.apache.aries.application.management_0.2.0.incubating-SNAPSHOT >>> [10] and service registration >>> {org.apache.aries.application.management.AriesApplicationResolver}={osgi.service.blueprint.compname=obr-resolver, >>> service.id=40} >>> It is somewhat weird that we observe this behavior as no-op-resolver has >>> service ranking -1 and obr-resolver has ranking 0. Logs suggest that from >>> time to time, AriesApplicationManagerImpl is provided with a service >>> reference before initialization of the bundle that provides the >>> obr-resolver (org.apache.aries.application.resolver.obr) completes :(. This >>> seems to exlain the weird behavior. Changing the order of bundles passed to >>> Pax Exam seems to fix this issue. >>> Note: Other testcases (i.e. OBRAppManagerTest) might also be affected by >>> this issue. >>> Side note: >>> Constants defined in the OBRResolverTest class make it hard to understand >>> what's going on inside this test - they are mixed :) : >>> public static final String TRANSITIVE_BUNDLE_BY_VALUE = >>> "transitive.bundle.by.reference"; >>> public static final String TRANSITIVE_BUNDLE_BY_REFERENCE = >>> "transitive.bundle.by.value"; >>> A patch fixing both the initial problem and the issue with constants coming >>> soon. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >
