[
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
