> Am I missing something here? If anything that you should not block in activate/deactivate.
The crux in OSGi is to NEVER have statics and represent any entity as a dynamic
service. In 99% of the case I’ve seen you can do all the
activation/deactivation in the activate/deactivate method. If it blocks, tough.
However, the activate method should never return before its service is ready
and the deactivate must never return before its resources are fully cleaned up.
Correctness before performance.
The trick in my experience is to write your code as simple as possible given
the previous model. Disregard bundle boundaries. Bundle updates are rare and
imho irrelevant for general performance. Once you got your system working
correctly measure the activation performance. If you then have a problem the
solution then usually stands out rather clearly.
One solution then is to register the service manually. If you have a very
lengthy initialization then you can create an immediate component without a
service. In the activate method you just start a thread that does the
initialization and when it is done you register the service via the bundle
context you got in the activate method. This same pattern can also be used when
you have to watch a condition (network online for example). You watch the
condition and then you register/unregister the given service.
Crucial is to express the result as a service since then upstream components
can properly depend on it with a single, highly optimized, mechanism: services.
In my experience, OSGi significantly changes the landscape concerning
initialization. You get lots of local small initializations that are
automatically parallelized.
Kind regards,
Peter Kriens
> On 7 aug. 2016, at 22:36, list+org.o...@io7m.com wrote:
>
> 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
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
