[
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.
