From your description, it sounds like a reasonable amount of work to do synchronously to the event delivery.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
----- Original message -----
From: Mark Raynsford <list+org.o...@io7m.com>
Sent by: osgi-dev-boun...@mail.osgi.org
To: osgi-dev@mail.osgi.org
Cc:
Subject: Re: [osgi-dev] Racing the BundleTracker
Date: Thu, Jun 1, 2017 6:34 AM
On 2017-05-31T22:27:59 +0000
"BJ Hargrave" <hargr...@us.ibm.com> wrote:
>
> The BundleTracker uses SynchronousBundleListener to be able to see all the BundleEvent types including RESOLVED. So your use of the BundleTracker must follow the advice for users of SynchronousBundleListener. See the doc for SynchronousBundleListener.
Understood, thank you.
> Since SynchronousBundleListener are synchronously called by the framework, it is important that SynchronousBundleListeners do not take a long time to return or attempt to manipulate the life cycle of the bundle whose BundleEvent is being delivered. This basically means that your BundleTracker should queue any long running work for another thread when an event occurs.
Got it.
In my case, the work performed is the following:
1. Parse a very simple line-based declaration format. The format is
designed to be extremely quick to parse, and I would be very surprised
if doing this took more than a millisecond.
https://github.com/io7m/callisto/blob/feature/interfaces-sketch-00/com.io7m.callisto.resources.main/src/main/java/com/io7m/callisto/resources/main/CoResourceBundleParserProvider.java#L119
2. For each file referenced in the parsed declaration above, check that
the file actually exists in the bundle (Bundle#getResource) and record
the name and URL in a map. The time taken to perform this step is
obviously proportional to the number of resources declared and the
speed of access to entries in the bundle.
3. Examine the wires of the bundle and check that each package (if any)
listed by the Provide-Capability header has actually been declared in
the parsed file above. Any package that appears in the
Provide-Capability header is marked as exported. This is entirely
CPU-bound and should be very quick to execute. It's basically a list
traversal and some HashMap retrievals and puts.
I believe that the above work needs to be performed synchronously: If
any errors occur in the above, they will be logged, and it's acceptable
if resource lookups that occur afterwards yield errors. It wouldn't be
acceptable, however, if all of the above work occurred without errors
and yet resource lookups failed anyway because they were taking place
before the above work had completed.
> In that case, you have all the usual race condition concerns. When doing the processing asynchronously to the synchronous event delivery, the bundle, since it is now RESOLVED, can be called by other bundles and can proceed in its lifecycle to be activated.
>
> Anything you do synchronous to the event in the tracker will happen-before the bundle's life cycle can proceed since the SynchronousBundleListener must first return to allow that to happen.
>
> So there is a tension between getting the work done synchronously to the event and doing too much work synchronous to the event. You will need to figure out the best tradeoff for you needs.
Does the above seem like a reasonable tradeoff?
It feels OK to me, but I'm nervous about there being lingering problems
that don't show up until everything is in production (with many more
bundle files and larger resource declaration files).
M
attc5lhf.dat
Type: application/pgp-signature
Name: attc5lhf.dat_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
attgbpw5.dat
Description: Binary data
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
