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-3721) Configuration not always provided upon initial service registration
Date Fri, 19 Oct 2012 18:05:12 GMT

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

Felix Meschberger commented on FELIX-3721:
------------------------------------------

Fixed another timing issue happening in our integration tests in Rev. 1400198:

When a ManagedService[Factory] updates the service.pid property of its service registration,
the new configurations may not properly be recorded for them to be later updated (or removed
if deleted). This happened in the test_ManagedService_change_pid and test_ManagedServiceFactory_change_pid
tests of the ConfigurationBaseTest class on Linux and Windows platforms.
                
> Configuration not always provided upon initial service registration
> -------------------------------------------------------------------
>
>                 Key: FELIX-3721
>                 URL: https://issues.apache.org/jira/browse/FELIX-3721
>             Project: Felix
>          Issue Type: Bug
>          Components: Configuration Admin, Specification compliance
>    Affects Versions: configadmin-1.6.0
>         Environment: Java 6 on Linux platforms
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>            Priority: Blocker
>             Fix For: configadmin-1.6.0
>
>
> With the changes to implement Targeted PIDs and refactoring of the service trackers for
FELIX-3577 and FELIX-3481 a race condition has been introduced which may cause ManagedService
and ManagedServiceFactory services to not be called back  on initial registration.
> This has been exhibited by test build of the yet unpublished OSGi CT for Configuration
Admin, for example:
>     (1) ManagedService PID 1 registered
>     (2) ManagedService PID 2 registered
>     (3) ManagedService PID 2 called back
> The problem is, that before the call back to ManagedService PID 2, the call back to ManagedService
PID 1 is expected.
> Turns out that this race condition takes place, which may primarily be reproduced on
Linux platforms, probably due to different threading implementations on the platform:
>    T1: register service
>    T1: call ServiceTracker.addingService
>    T1: schedule service update task
>    T2: run update task
>    T2: terminate update task without calling the service
>    T1: return from ServiceTracker.addingService returning ConfigurationMap
> This is expected since the service update task in T2 expects the ConfigurationMap stored
in the ServiceTracker. But this is not the case yet because the ServiceTracker.addingService
method has not yet returned it for it to be stored in the ServiceTracker. Therefore T2 is
not able to call back the service and thus the update call never takes place.
> The fix is either to delay the task execution in T2 or to prepare the ConfigurationMap
in T1 and hand it over to the task to be executed in T2. The first solution is suboptimal
because we cannot find a timing value which (a) does not delay too much bug (b) still makes
sure the ConfigurationMap will ultimately be available.

--
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

Mime
View raw message