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-599) Service Registration Lock: Do not release not-owned lock and don't wait so long for the lock
Date Fri, 06 Jun 2008 13:23:44 GMT

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

Felix Meschberger commented on FELIX-599:

Mutliple changes to service registration locking:
- only log once (at info level) when waiting for the lock release
- wait at most 10 * 1 seconds
- unlock only allowed for the lock owner
- prevent calling the unlock method if lock acquisition failed

Fixed in Rev. 663930.

> Service Registration Lock: Do not release not-owned lock and don't wait so long for the
> --------------------------------------------------------------------------------------------
>                 Key: FELIX-599
>                 URL: https://issues.apache.org/jira/browse/FELIX-599
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.0.1
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: scr-1.0.1
> While fixing a asynchronicity issue in the AbstractComponentManager class, I introduced
a locking mechanism for the service registration field. This implementation has two issues:
> (1) The unlockServiceRegistration lock simply releases the lock regardless of who is
calling the method. This causes wrong threads to be able to release the lock of other threads.
A secondary to this issue is, that the unlockServiceRegistration method is called by the getServiceReference()
and unregisterComponentService methods, regardless of whether the lock could be acquired or
> (2) When trying to acquire the lock, the lockServiceRegistration method tries to acquire
the lock and if not possible waits for 10 * 10 seconds (at most) until giving up. This is
probably too much. If the lock cannot be acquired within a short time frame, chances are,
the lock will never be acquirable. Therefore, this time frame is cut down to 10 * 1 second
before failing.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message