felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4984) Issues in CircularReferenceTest
Date Sat, 12 Sep 2015 07:20:45 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14741946#comment-14741946
] 

Pierre De Rop commented on FELIX-4984:
--------------------------------------

Ok. I don't see anymore any errors using your patch. I also checked the bndtools version in
my sandbox, which is OK. thanks.

But about the NPE, I wonder if there is still a problem if the service becomes unavailable
immediately just right after the null check ? I mean: when we test the refPair like this:

{code}
        //TODO dynamic reluctant
        RefPair<S, T> refPair = m_tracker.getService( ref );
        if (refPair == null) {
            return; // The service is no longer available, probably because the tracker has
been closed
        }

        // at this point, the tracker is closed or the service just becomes unavailable ...
{code}

Then, assuming that the service becomes unavailable right after the null check, the " m_componentManager.invokeBindMethod(
this, refPair, trackingCount );" line 1580 will be invoked with an invalid refPair ? Then
what will happen ?

PS: I noticed a small problem in the ComponentTestBase class, which is not related to this
current issue, it just concerns how "ignorable warnings" are handled, and there is an ArrayIndexException,
which presents some warnings to be displayed ... I will open another jira issue with a small
fix about that.


> Issues in CircularReferenceTest
> -------------------------------
>
>                 Key: FELIX-4984
>                 URL: https://issues.apache.org/jira/browse/FELIX-4984
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>            Reporter: Pierre De Rop
>            Priority: Minor
>             Fix For: scr-2.0.2
>
>         Attachments: felix-4984.diff, org.apache.felix.scr.integration.CircularReferenceTest.test_A11_B0n_delayed_B_first.log,
org.apache.felix.scr.integration.Felix4984Test.test_A11_B0n_delayed_B_first_ABoundToAtMostOneB-NPE-with_patch.log.gz,
org.apache.felix.scr.integration.Felix4984Test.test_A11_B0n_delayed_B_first_ABoundToAtMostOneB.log
>
>
> This issue is described in the dev mailing list, in http://www.mail-archive.com/dev@felix.apache.org/msg37281.html
> while working on FELIX-4955, I sometimes have the CircularReferenceTest failing.
> Everything is located in my sandbox, in http://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager.ds/
> To reproduce the test:
> install eclipse Mars
> install latest bndtools using "install new software" from Eclipse, and then add latest
stable release from http://dl.bintray.com/bndtools/bndtools/latest/
> install a java8 runtime (I'm using oracle java8 1.8.0_45, 64 bit version). The whole
new dependencymanager.ds project is intented to be build in java8.
> checkout my sandbox:
> $ svn checkout http://svn.apache.org/repos/asf/felix/sandbox/pderop/dependencymanager.ds
> go to "dependencymanager.ds" directory:
> $ cd dependencymanager.ds/
> due to a pending issue, you have to first build the DM bnd annotation plugin before importing
the project into eclipse. to do so, just type:
> $ ./gradlew org.apache.felix.dependencymanager.annotation:jar
> now launch eclipse and use the the dependencymanager/ds directory as the workspace dir
for Eclipse.
> switch to BndTools perpective.
> import the bndtools project into eclipse: Import -> Existing Projects into Workspace
-> Browse -> select dependencymanager.ds directory (it is proposed by default).
> normally, and hopefully, everything should compile fine. Junit tests are left in org.apache.felix.dependencymanager.ds/
directory and integration tests are located in org.apache.felix.dependencymanager.ds.itest/
directory.
> Open under Eclipse the org.apache.felix.dependencymanager.ds.itest/src/org/apache/felix/scr/integration/CircularReferenceTest.java
> I slightly modified it in order to dump stack traces when A component is bound multiple
times to the same B instance.
> (I believe that only delayed components are concerned by the issue).
> For example, in the test_A11_B0n_delayed_A_first() method, I added a call to "assertABoundToOneB(a)"
like this:
> {code}
>     @Test
>     public void test_A11_B0n_delayed_A_first() throws InvalidSyntaxException
>     {
>         String componentNameA = "4.1.A.1.1.dynamic";
>         final ComponentConfigurationDTO componentA = findComponentConfigurationByName(
componentNameA, ComponentConfigurationDTO.SATISFIED );
>         String componentNameB = "4.1.B.0.n.dynamic";
>         final ComponentConfigurationDTO componentB = findComponentConfigurationByName(
componentNameB, ComponentConfigurationDTO.SATISFIED );
>         delay();
>         A a = getServiceFromConfiguration(componentA, A.class);
>         assertABoundToOneB(a);
>         delay(); //async binding of a to b after circular ref detected
>         B b = getServiceFromConfiguration(componentB, B.class);
>         assertEquals( 1, b.getAs().size() );
>     }
> {code}
> the "assertABoundToOneB(a)" call does this:
> {code}
>     private void assertABoundToOneB(A a) {
>         if (a.getBs().size() != 1) {
>             System.err.println("detected problem ...");
>             a.dumpStackTracesWhenBWasBound();
>         }
>         assertEquals( 1, a.getBs().size());
>     }
> {code}
> And stacktraces will be dumped in order to determine why A was bound two times to the
same B instance.
> it's possible that you have to run several times the "CircularReferenceTest" test before
having a failure (and some stacktraces).
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message