[
https://issues.apache.org/jira/browse/FELIX-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749174#action_12749174
]
Felix Meschberger commented on FELIX-1542:
------------------------------------------
Add lastModificationTime and lastUpdateTime fields to ensure only single update
of configuration properties. From the concurrency notes in the
ConfigurationImpl class:
* This concurrency safety is implemented with the help of the
* lastModificationTime field updated by the configure(Dictionary) method
* when setting the properties field and the lastUpdatedTime field updated
* in the Update Thread after calling the update(Dictionary) method of
* the ManagedService[Factory] service.
*
* The UpdateConfiguration task compares the lastModificationTime to the
* lastUpdateTime. If the configuration has been modified after being
* updated the last time, it is updated in the ManagedService[Factory]. If
* the configuration has already been updated since being modified (as in
* the case above), the UpdateConfiguration thread does not call the update
* method (but still sends the CM_UPDATED event).
Fixed in Rev. 809194
> Configuration may be supplied twice in certain situations
> ---------------------------------------------------------
>
> Key: FELIX-1542
> URL: https://issues.apache.org/jira/browse/FELIX-1542
> Project: Felix
> Issue Type: Bug
> Components: Conditional Permission Admin, Specification compliance
> Affects Versions: configadmin-1.2.0, configadmin-1.2.2
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: configadmin-1.2.4
>
>
> An issue reported in FELIX-1146 and presumably fixed in configadmin 1.2.0 is
> not really fixed: With the fix for 1.2.0 in Rev. 805668 the window for the
> race condition is much smaller than before, but it still exists:
> Consider this:
> T1. create and update configuration
> ConfigurationImpl.update persists configuration and sets field
> Thread preempted
> T2. ManagedServiceUpdate constructor reads configuration
> Uses configuration already persisted by T1 for update
> Schedules task to update service with the configuration
> T1. Runs again creating the UpdateConfiguration task with the
> configuration persisted earlier
> Schedules task to update service
> UpdateTask:
> updates ManagedService with configuration prepared by T2
> updates ManagedService with configuration prepared by T1
> In this small window a race condition occurred, which caused the
> ManagedService to be supplied with the same configuration twice. It would
> have been ok for the ManagedService to first get null (for the service
> registration and configuration not available yet) and in a second call to get
> the configuration. But it is not ok to get the same configuration twice.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
