On 2016-08-07T17:37:59 +0200 Simon Chemouil <ecli...@mithrandir.net> wrote: > > Ideally, TCPServerManager's thread dealing with binding/closing sockets > should not be held statically, but it's a bit tricky to deal with the > restarting of TCPServerManager instances otherwise.
The more I think about this, the less it seems like a DS issue and more like something more fundamental instead. Ignoring DS for now and assuming that only the direct OSGi service APIs are being used: You have a service S in bundle B. S needs to do some fairly long-running work on both startup and shutdown before it can be used. Bundle B can be restarted at any time, so the startup and shutdown code in S must be protected against multiple instances of S executing concurrently. I must admit that I'm not yet familiar with the core OSGi service APIs, but I assume that they have similar constraints to DS in that you're not supposed to block the runtime when it makes calls into your code. The workaround you've described involves offloading that startup/shutdown work to a separate service T, where T ensures that execution happens serially. However, if S and T are both in B, then a restart of B will destroy and create new instances of both S and T and therefore the original problem remains (the new T can't guarantee that the startup code won't be running concurrently with work queued on the old instance of T). The workaround to this workaround is to store something statically, such as a Thread or an ExecutorService that is shared between all instances of T. This seems nightmarish to me though, in a system with as much dynamism as OSGi. Another option is to place S and T in separate bundles so that S can be restarted independently of T and therefore T is not recreated and can continue keeping things serial. This seems pretty nasty though... Creating entire new bundles just to work around a concurrency issue. Every single server application I've written in the past eight years or so has involved moderately lengthy initialization and shutdown work. I feel like I'll be running into this issue again and again. I'm quite disturbed that I've run into something like this in the very first "could not be simpler" OSGi program I've written. Am I missing something here? M
pgpVaTYOkzS2Q.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
