I opened FELIX-5621 <https://issues.apache.org/jira/browse/FELIX-5621> about
this. I still think returning service properties from event methods cannot be
made thread safe.
As noted in the issue, I think ExtComponentContext can be used safely with code
like:
final AtomicReference<Dictionary<String, Object>> propRef;
...
Dictionary<String, Object> oldProps;
Dictionary<String, Object> newProps;
do {
synchronized(propRef) {
oldProps = propRef.get();
newProps = new Hashtable<>(oldProps);
}
//update newProps with new information
extComponentContext.setServiceProperties(newProps);
} while ( propsRef.compareAndSet( oldProps, newProps)}
I think all we can do in code now is to say not to use the annotation on event
methods.
thanks
david jencks
> On Apr 11, 2017, at 9:09 PM, David Jencks <[email protected]> wrote:
>
> We seem to be thinking along similar lines…. earlier today I wrote this but
> got distracted before sending:
>
> At the moment I don’t see how returning the new service properties from
> bimd/updated/unbind methods can be thread safe. I think the
> activate/modify/deactivate methods are ok.
>
> I wonder if using the ExtComponentContext to modify the properties and
> synchronizing access would lead to deadlocks. Better than this would be a
> compare-and-set method of some sort on ExtComponentContext, perhaps based on
> a change count
>
> int cc;
> Dictionary<String, Object> newProps;
> do {
> cc = etc.getChangeCount();
> newProps = new Hashtable<>(ecc.getProperties());
> //update properties
> } while (!ecc.compareAndSet(cc, newProps)}
>
> david jencks
>
>
>> On Apr 11, 2017, at 10:25 AM, Brent Daniel <[email protected]> wrote:
>>
>> I agree that serializing everything would be counterproductive (though the
>> impact could be reduced by limiting synchronization to methods with the Map
>> return signature.) I wonder if it would be possible to implement a
>> lightweight scheme using update counts, though.
>>
>> Otherwise it's probably a bad idea to ever have lifecycle and bind methods
>> that both update service properties. And, unfortunately, that may not be
>> all that obvious because the updates will happen in the expected order most
>> of the time. I'm not sure if modifying service properties is documented
>> somewhere (I couldn't find anything), but if it is this should probably be
>> mentioned there.
>>
>> On Mon, Apr 10, 2017 at 3:28 PM, David Jencks <[email protected]>
>> wrote:
>>
>>> I don’t think this is a bug. To avoid this behavior I think we’d have to
>>> serialize all lifecycle method invocations which I believe to be very
>>> undesirable.
>>>
>>> I could be wrong.
>>>
>>> david jencks
>>>
>>>> On Apr 10, 2017, at 2:39 PM, Brent Daniel <[email protected]>
>>> wrote:
>>>>
>>>> Should there be any guarantees on the ordering of service property
>>> updates
>>>> across methods?
>>>>
>>>> For example, say I have an activate method that simply returns the
>>> current
>>>> service properties and a bind method that adds "active=true" to the
>>> current
>>>> properties and returns the updated properties. Both methods are
>>>> synchronized.
>>>>
>>>> Let's say activate() is invoked first and exits. Before Felix updates the
>>>> service properties, another thread calls the bind method, and Felix
>>> updates
>>>> the service properties to contain "active=true". Then the first thread
>>>> updates the service properties to the set returned from the activate()
>>>> method, thus blowing away the changes from the bind method.
>>>>
>>>> Is this a bug? Or should we not be relying on the property updates from
>>> the
>>>> first method being called taking effect before the second method's
>>> updates?
>>>
>>>
>
