Hi Thanks alot. This looks great.
Unfortunately your refactoring of binding services broke existing functionality: If a bind method cannot be called a component must not be activated (at least if it involves required services). See my comment in the issue. Regards Felix Am 05.09.2012 um 16:20 schrieb David Jencks (JIRA): > > [ > https://issues.apache.org/jira/browse/FELIX-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449194#comment-13449194 > ] > > David Jencks commented on FELIX-3645: > ------------------------------------- > > I made a lot of changes and think I have this problem solved. > > I think your integration test can produce some expected errors and warnings > as services disappear between the time we think a component is satisfied and > when we actually get the service from the service reference. Felix logs an > error in this case, and we do some logging too. So I modified the test to > ignore the "expected" errors due to this. > > I also moved the very useful logging code into the base itest so I could use > it for all the other problems I was having :-) > > The current state of the code is that we release all locks (including read > locks) when registering the service and when collecting dependencies for a > component instance. Then we take a write lock to actually create the > component instance using these collected dependencies. > > I'm storing the collected dependencies in a map in AbstractComponentManager. > This now holds most of the state for the dependency managers. I think we > could move the rest of the state into this map and make the > bind/unbind/updated methods even more permanent and share the dependency > managers between ImmediateComponentManagers for different configurations for > the same Component. > >> 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/[email protected]/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 seconds. >> 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
