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:39:18 GMT
On Mon, 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

Neil, thanks.

To begin with, I'm going to have a static collection of services
present in the Karaf container via the Karaf assembly mechanism. I
just need to start up in an orderly way with them. I may never need or
want to add or subtract on the fly.


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


Mime
View raw message