You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Bartosz Kowalewski (JIRA)" <ji...@apache.org> on 2010/05/30 23:45:44 UTC
[jira] Commented: (ARIES-327) From time to time OBRResolverTest
causes Aries build to fail
[ 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.
Re: [jira] Commented: (ARIES-327) From time to time OBRResolverTest
causes Aries build to fail
Posted by Bartosz Kowalewski <ko...@gmail.com>.
That's what I thought. I'll create a new patch for aries-327 later today.
Thanks,
Bartek
2010/5/31 Alasdair Nottingham <no...@apache.org>:
> 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)" <ji...@apache.org> 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.
>>
>
Re: [jira] Commented: (ARIES-327) From time to time OBRResolverTest causes Aries build to fail
Posted by Alasdair Nottingham <no...@apache.org>.
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)" <ji...@apache.org> 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.
>