Blueprint service damping is one of those things that will always polarise opinions. I think it has it's uses - we use it in WebSphere to limit application churn during update. Damping enables updates to downstream bundles to be isolated to those bundles, with a brief pause in throughput instead of Service Unavailable. That said, there's always the potential for a window, so you do still have to handle these conditions. Damping isn't for everyone, though, and this is why Blueprint 1.1 is being worked [1], to cover non-damping behaviour.
[1] https://github.com/osgi/design/tree/master/rfcs/rfc0184 Regards, Graham. Graham Charters PhD CEng MBCS CITP STSM, WebSphere OSGi Applications Lead Architect, Master Inventor IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN, UK Tel: (Ext) +44-1962-816527 (Int) 7-246527 (Fax) +44-1962-816527 Internet: [email protected] From: Balázs Zsoldos <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 13/09/2013 11:45 Subject: Re: [osgi-dev] Fabric Service Model - Request for feedback Sent by: [email protected] Hi Neil, I have been thinking a lot about this behavior. It causes new issues but it also gives more possibility in design. Therefore I would not say that is a bad feature in Blueprint. As many developers come from Spring they will choose blueprint instead of DS at the first time. In case you are against blueprint features I think it would be nice to somehow express your thoughts about them in a way that OSGi juniors will understand as well. What I found out till now: Pros: Service wirings are much more lazy so in case of a service change not the whole application has to restart but only that crumb. This makes deployment time much faster so development will be better In case of a live server bundle updates can be done in lower levels in the way that users will not notice it at all. Imagine that there is 3 secs timeout and version upgrades are done in one sec. The front-end users will notice only that there is one sec lag but they will not see any downtime. Cons: There can be issues. For example if someone wants to use a "lazy wired service" in the destroy method or the service uses a lazy wired service the bundle will not be able to stop but will wait for timeout. We experienced this with activiti-blueprint usage. The DataSource service went away before activiti started to stop. Activiti wanted to write records into the database but no DataSource was available but only a proxy reference. The logic is a bit strange and brings issues but also brings many new possibilities. What a developer has to concider is that if he/she uses this technique very strict rules has to be kept: No service usage in the stopping functions Developers should not think in OSGi services when special libraries are implemented as use like Loggers. Logger should be instantiated as it was before, just by calling a constructor or a factory class. Till now I think that the possibility I call "lazy service wiring" gives so much improvement that I can live with the rules and issues it raises. Those were my thoughts but I would be very interested in others opinion. Maybe there is a better solution to speed up version upgrades and the possibility to replace only one service in a big application without affecting the other parts. Regards, Balazs On Fri, Sep 13, 2013 at 12:19 PM, Neil Bartlett <[email protected]> wrote: Christian, I consider that to be one of the worst features of Blueprint, so I would be very opposed to adding it to DS! Regards Neil On Fri, Sep 13, 2013 at 11:17 AM, Christian Schneider <[email protected]> wrote: > I think you can take a look at what aries blueprint does for these cases. > They create a proxy for each injected service and switch the service if the > original one goes away. If no service is available then I think it > waits for some time for a new one to come and throws an exception if a time > out happens. > > Perhaps a similar behaviour can also be added for DS. Not sure if it matches > the DS ideas though. > > Christian > > > On 13.09.2013 12:10, Thomas Diesler wrote: > > Thank you all for your replies. We ended up with three measures > > #1 assert that the component is still valid on entry of every public method > (AtomicBoolean set by activate/deactivate) > #2 Use a ValidatingReference to hold unary references to dependent services > (prevents NPE when a dependent service goes away) > #3 Throw an InvalidComponentException runtime exception on #1 and #2 > > The idea is that access to a deactivated reference never throws NPE > Access to the public API is prevented from deactivated service instances > > cheers > --thomas > > On Sep 11, 2013, at 11:11 AM, Richard S. Hall <[email protected]> wrote: > > Resending my reply from yesterday since my original message didn't seem to > go through... > > ---- > > Yes, you can do some of these sorts of things with iPOJO. > > First, iPOJO has the notion of a service-level service dependency as well as > an implementation-level service dependency (which is the level of DS > dependencies). Second, iPOJO caches services references within a service > method invocation so that a thread calling a method on a service will see > the same injected services until the thread exits the invoked service > method. > > It doesn't deal with configuration locking (at least not of which I am > aware). > > -> richard > > On 9/10/13 06:41 , Thomas Diesler wrote: > > Hi Folks, > > in Fabric we have a service model whereby services have interdependencies, > are configurable and dynamic by nature - all of which is managed in OSGi > with the help of Declarative Services. To illustrate I use a simple example > > ServiceT { > > @Reference > ServiceA serviceA; > > @Reference > ServiceB serviceB; > > public doStuff() { > // that uses serviceA & serviceB > } > } > > > The injection is handled by the DS framework - there are various callbacks > involved. > > Lets assume the system is fully configured and a client makes a call on > ServiceT > > ServiceT serviceT = getServiceT(); > serviceT.doStuff(); > > > Due to the dynamic nature of OSGi services and their respective > configuration ServiceT must deal with the following possible/likely > situations > > #1 An instance of a referenced service is not available at the point of > access (i.e. serviceA is null) > #2 In the context of a single call the service instance may change (i.e. > call may span multiple instances of serviceA) > #3 In the context of a single call the configuration of a service instance > may change (i.e. serviceA is not immutable, sequential operations on A may > access different configurations) > > In OSGi there is no notion of global lock for service/configurations nor a > notion of lock of a given set of services/configurations - I cannot do > > lock(T, A, B); > try { > ServiceT serviceT = getServiceT(); > serviceT.doStuff(); > } finally { > unlock(T, A, B); > } > > This code is also flawed because it assumes that the caller of doStuff() is > aware of the transitive set of services involved in the call and that this > set will not change. > > As a conclusion we can say that the behaviour of doStuff() is only defined > when we assume stability in service availability and their respective > configuration, which happens to be true most of the time - nevertheless, > there are no guarantees for defined behaviour. > > How about this … > > The functionality of A and B and its respective configuration is decoupled > from OSGi and its dynamicity > > > A { > final Map config; > public doStuffInA() { > } > } > > B { > final Map config; > public doStuffInB() { > } > } > > > ServiceA and ServiceB are providers of immutable instances of A and B > respectively. There is a notion of CallContext that provides an idempotent > set of instances involved in the call. > > CallContext { > public T get(Class<T> type); > } > > This guarantees that throughout the duration of a call we always access the > same instance, which itself is immutable. CallContext also takes care of > instance availability and may have appropriate timeouts if a given instance > type cannot be provided. It would still be the responsibility of A/B to > decide wether an operation is permissible on stale configuration. > > Changes to the system would be non-trival and before I do any prototyping > I'd like to hear what you think. > > cheers > --thomas > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
