felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <ben...@basistech.com>
Subject Re: How to 'let the dust settle' with DS?
Date Mon, 07 Sep 2015 16:46:36 GMT
On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
<david_jencks@yahoo.com.invalid> wrote:
> I think both of those suggestions are rather inappropriate to be used in a DS component
activate method, which generally should not block….. although having it take a long time
is also very much less than ideal.
>
> Certainly the second method seems to imply someone knows how many B2s there  are so the
minimum cardinality can be set based on that knowledge, possibly by whatever code has that
knowledge.  The (proprietary) metatype/config admin I work with does this, it can count how
many cm Configurations there are for B2 and set properties based on that.
>
> If you make B3 expose a service and not be immediate, then it won’t be activated until
someone needs it and will pick up however many are then available, even without the cardinality
set.

Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
which does not involve publishing an OSGi service. So I may need to
stick with one of these less-than-ideal alternatives.


>
> david jencks
>
>> On Sep 7, 2015, at 11:46 AM, Neil Bartlett <njbartlett@gmail.com> wrote:
>>
>> Just to add a bit of detail…
>>
>> If you wait for 5 service instances before performing your initialisation, that’s
great. But bear in mind that you might get a 6th and a 7th very soon afterwards, and depending
on your implementation you may have to re-initialise each time that happens.
>>
>> If your (re)initialisation is expensive, you might want to avoid doing it too many
times, especially if there is a rapid sequence of changes. This is typically the case during
application startup for example. There are two general solutions to this:
>>
>> 1) You could start a timer each time the service set changes. If there are no further
changes before the timer expires, then you do your reinitialisation. If there *are* changes
then you cancel the existing timer and start a new one.
>>
>> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). Whoever
is making changes to the set of installed bundles — e.g. the launcher, or some kind of management
agent like FileInstall — should start a Coordination before it does anything, and end the
coordination after that series of changes. Your component should be a Participant which detects
whether there is a current coordination. If there is NO current coordination then it should
immediately action any changes in the service set. However if there is a current coordination,
then those changes should only be actioned when the coordination ends. This has the advantage
that you don’t waste time waiting for an arbitrary-length timer to expire.
>>
>> Hope that helps. Regards,
>> Neil
>>
>>
>>
>>> On 7 Sep 2015, at 16:16, Benson Margulies <benson@basistech.com> wrote:
>>>
>>> That is precisely what I needed. Thanks.
>>> On Sep 7, 2015 11:06 AM, "David Jencks" <david_jencks@yahoo.com.invalid>
>>> wrote:
>>>
>>>> Hi Benson,
>>>>
>>>> I don’t really understand what you are asking, but I’m going to guess.
>>>>
>>>> I think you have say 5  B2 services and you want B3 to wait to activate
>>>> until all 5 B2’s are available?
>>>>
>>>> There is a way to do this with DS 1.3, but you have to make B3
>>>> configuration-policy=REQUIRE.
>>>>
>>>> So you have in B3:
>>>> @Component(configuration-policy=REQUIRE)
>>>> public class B3 {
>>>>
>>>> @Reference(cardinality=MULTIPLE)
>>>> void setB2(B2 b2) {}
>>>> }
>>>> In your (required) configuration for B3 you put a property
>>>>
>>>> B2.cardinality.minimum: 5
>>>>
>>>> that is, <reference-name>.cardinality.minimum = <number of required
B2’s>
>>>>
>>>> Don’t mess with start levels, they will be unreliable for this purpose.
>>>> There’s no guarantee that a bundle starting will start all the DS services
>>>> it provides.  They might have all sorts of unsatisfied dependencies…..
such
>>>> as missing configurations.
>>>>
>>>> Let me know if this guess is a total miss :-)
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>>>> On Sep 7, 2015, at 10:52 AM, Benson Margulies <benson@basistech.com>
>>>> wrote:
>>>>>
>>>>> I am hoping that David Jencks will continue his charity to strangers
>>>> here.
>>>>>
>>>>> David, if you have any gogo jiras you'd like help with in return, just
>>>> ask.
>>>>>
>>>>> Three bundles:
>>>>>
>>>>> B1 registers service S1.
>>>>>
>>>>> B2 consumes S1 and uses it in the implementation of S2. That is to
>>>>> say, it picks up a reference to S1 with a DS @Reference with
>>>>> cardinality MANDATORY.
>>>>>
>>>>> B3 consumes B2, but it anticipates that B2 will have siblings. So it
>>>>> consumes a reference to a List<S2> with cardinality AT_LEAST_ONE.
>>>>>
>>>>> It can take B2 and buddies a bit of time to activate.
>>>>>
>>>>> I appreciate that the most general case is intended to be that
>>>>> services come and go, and B3 should dynamically reconfigure itself.
>>>>> I'd rather not do that yet; I'd like to arrange things so that B3
>>>>> waits to finish starting itself until all the B2-ish guys are fully
>>>>> set up.
>>>>>
>>>>> Assuming that B2 and friends are all started at an earlier start
>>>>> level, is there an 'esthetic' way to arrange this? Or should I really
>>>>> suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
>>>>> B2 service x=y, block until it's available?'
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message