'Ello. On 2016-08-08T15:11:05 +0200 Peter Kriens <peter.kri...@aqute.biz> wrote:
> As you seem to have found out the problems disappears when you just > do the simple thing … block until your resource R is ready. On this implementation, for this problem, sure! :D It is in fact what I ended up putting into the example: https://github.com/io7m/osgi-example-reverser/blob/master/tcp-server/src/main/java/com/io7m/reverser/tcp_server/TCPServerService.java#L47 Blocking initialization happens in the TCPServer constructor. There's no exponential backoff or retrying yet, so it's still fragile to other network problems relating to bind(). > So now we have the case that you raise: T1 is deactivated while T2 is > activated before T1 has finished deactivating. Looking at the SCR/DS > implementations and >activities involved as well as experience it is > not something I generally worry about. I always write my servers > assuming they can fail. I just write the activate method to start a > loop that initializes and then does work. If an exception is thrown, > I wait with exponential back-off and try again. Right. I think it's fairly common outside of OSGi (and more common outside of Java due to the [not very accurately] perceived problem of VM startup times) to let entire processes crash early and then use process supervision systems (daemontools, runit, etc) to restart the processes. Obviously this approach doesn't apply to OSGi as the whole point is to not have to keep restarting whole systems. > My general philosophy in life is that it is better to accept failures > and handle them instead of trying to prevent them in all possible > theoretical cases. It makes for MUCH simpler systems that are more > reliable. I agree in general. This had the feel of a bug in my code (or worse, a problem with the way OSGi is specified) rather than an acceptable failure, though. > That said, if I would be given this answer I would probably think it > is a cop-out. So how could we solve this race condition without > statics in OSGi? > > It would require a new service that handles the atomicity. The > component should have no dependencies so it only depends on its > bundle life cycle which will avoid the T1/T2 overlap since a bundle > cannot start before it has been fully stopped. It should provide a > lock method that is taken in activate and released in deactivate. So > that would ensure atomicity. > It feels like in order for this LockImpl solution to work, you'd have to be relying on the same assumption that you'd be relying on if you simply blocked in activate()/deactivate()... The assumption that if the bundle is restarted/refreshed, then the activate() method of the new instances won't be called concurrently with the deactivate() methods of the old instances. If that assumption doesn't hold, then it seems that the LockImpl would not have the right effect. There'd effectively be two lock instances. > However, I would not bother, making your server loop resilient by > reinitializing after a failure is much more robust against many more > error cases. The chance that you get overlapping > T1.deactivate/T2.activate is in my experience magnitudes smaller than > getting a network problem, which in the end can be handled with the > same code. The chance might even be zero but I’ve no time to crawl > through the spec to proof that right now. I agree, I wouldn't bother. > If you really feel strong about this race condition then you should > file a bug on the public OSGi Bugzilla, the expert group will then > take a look if the DS specification should be amended. I don't know enough to feel that strongly. :D I think it would be nice if the spec had something unambiguous to say about this case. Given that the point of OSGi is to be standardized, it'd be better if we weren't relying on unspecified assumptions for something like this. The fact that I had to ask the question(s) at all might indicate a problem (or maybe I'm being overly pedantic). M
pgplcujQark4h.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
