felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [jira] [Commented] (FELIX-3645) SCR could not obtain lock in 5000 ms
Date Wed, 05 Sep 2012 23:33:03 GMT
I think I restored the previous behavior, but the more i think about it the less I like it.

It only obstructs activation for required dependencies.  I think that if we're going to prevent
activation due to a missing bind method, it shouldn't matter whether the dependency is optional.
 In either case the component isn't getting info it expects.  And in all cases the component
can get the dependency using the lookup strategy.

we'll see what happens with arguing with the experts ;-)

david jencks

On Sep 5, 2012, at 4:17 PM, Felix Meschberger wrote:

> Hi,
> Am 05.09.2012 um 17:06 schrieb David Jencks:
>> As noted in the issue i can't find where the DS 1.0 or 1.2 spec describes this behavior.
 It looks to me like the specs say if a bind method is specified but missing, you just don't
call it. (after logging that it's missing).
> Hmm, yeah. I want to prove you wrong but instead proved myself wrong: This is what the
spec says:
>> If no suitable method is located, SCR must log an error message with the Log Service,
if present, and there will be no bind, updated, or unbind notification.
> This has been added in DS 1.1 obviously to clarify. But then it looks like the CT has
wrong expectation.
> I think I go ask the experts before rushing ;-)
> Regards
> Felix
>> Anyway I'll look into restoring the behavior....
>> thanks
>> david jencks
>> On Sep 5, 2012, at 3:28 PM, Felix Meschberger wrote:
>>> 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
>>>> 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
>>>>>        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 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
>>>>> 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