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
pgp01z7ubPqfZ.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
