felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3645) SCR could not obtain lock in 5000 ms
Date Wed, 05 Sep 2012 22:26:09 GMT

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

Felix Meschberger commented on FELIX-3645:

Sorry, your refactoring broke functionality around service binding.

This is manifest in a CT test failure: The test declares a DS 1.0 component. DS 1.0 only allows
the Service instance or the ServiceReference as an argument to the bind method. The test component,
though has a method taking the Service plus a Map (service props). The test expects the component
to *not* register because the bind method is not found.

The implementation (in the BindMethod) also correctly analyzes the situation and logs, that
an appropriate bind method cannot be found. But later the DependencyManager.bind(Map) method
just does a BindMethod.invoke and ignores the result. Thus the DependencyManager does not
pass back the situation of not being able to call a missing bind method and thus the component
is activated, where it shouldn't.

I would assume the DependencyManager.bind(Map) method must record whether the bind method
can be called or not as it was before:

                    // success is if we have the minimal required number of services bound
                    if ( invokeBindMethod( refs[index] ) )
                        // of course, we have success if the service is bound
                        success = true;

> SCR could not obtain lock in 5000 ms
> ------------------------------------
>                 Key: FELIX-3645
>                 URL: https://issues.apache.org/jira/browse/FELIX-3645
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>         Environment: linux fc16, bipro, Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
>            Reporter: Pierre De Rop
>            Assignee: David Jencks
>         Attachments: TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml
> I finally made an integration test and committed it in the trunk.
> This test sounds to reproduce the problem described in http://www.mail-archive.com/dev@felix.apache.org/msg26360.html.
> the test contains the following files:
> src/test/resources/integration_test_component_concurrency.xml
> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/A.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/B.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/C.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/AFactory.java
> src/test/java/org/apache/felix/scr/integration/components/concurrency/CFactory.java
> I also slightly modified src/test/java/org/apache/felix/scr/integration/ComponentTestBase.java
> in order to use the apache log service, and also to declare the new package from org/apache/felix/scr/integration/components/concurrency.
> The test does the following:
> A optionally depends on B (dynamic=true, cardinality=0..N)
> B depends on C
> A is a factory component and is created by the AFactory class, in an infinite loop and
in a dedicated thread.
> C is also a factory component and is created/disposed for ever, by the CFactory class.
> the integration test uses the log service in order to track logged errors, and runs 30
> If after 30 seconds, some errors are detected, then the test fail.
> It seems that we have many exceptions when the test fail, which I did not reproduced
so far. (see many IllegalMonitorState Exceptions).
> The initial exception discussed from the post in the @dev list is also reproduced.
> For example, I attached to this post my target/failsafe-reports/TEST-org.apache.felix.scr.integration.ComponentConcurrencyTest.xml,
when the problem takes place.
> Please take a look starting at line 951, as well as at the corresponding dumpstack at
line 713, and also the "Locking activity before IllegalMonitorStateException" log, line 887.
> Hope this will help.
> /pierre

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message