Optimize adapter registry initialization
Conditions for reinitializing the adapter cache from scratch
-
Optimize checksumming (MD5) of adapters.xml files in the following way: - A property file (or binary file) is stored in the workspace that lists MD5sums for each known adapters.xml file. This data is assumed to be as up-to-date as the file's last modified date is. Let's call this file
TIMESTAMPS
. - If any adapters.xml file in the workspace has a last modified timestamp later than the last modified timestamp of
TIMESTAMPS
, then the adapter cache shall be be completely reinitialized. - Otherwise, we can trust that adapters.xml files have not changed.
- A property file (or binary file) is stored in the workspace that lists MD5sums for each known adapters.xml file. This data is assumed to be as up-to-date as the file's last modified date is. Let's call this file
-
Ensure that the adapter cache is reinitialized if any ontology installation/merging happens during platform startup.
Initializing without cache and forming the adapter cache
-
Instead of always reading XML adapter definitions from scratch, create serializable binary representations of all available adapter definitions that can be read with one databoard file read. - Ensure the serialized binary representations do not contain URIs that need to be resolved into resources, only serialized resource IDs that can be directly and more quickly deserialized into Resources. Otherwise this cache will be useless performance-wise.
-
First, normal initialization is done as follows, preferably using parallel streams as much as possible: -
Find all adapters.xml files in the current environment -
Process all found XML file textual representation with OntologyVersions -
Parse all XML files: form AdapterInstallers that both add the adapters to the AdaptionService and add a serializable object representation of themselves to the formed adapter cache structure -
Run the AdapterInstallers in a read transaction (just as currently). This is the part that currently takes most time due to all the URI ➡ Resource resolutions going on. -
Write the adapter cache to disk
-
Initializing from the cache
-
Read single adapter cache file and add all the contained adapters to AdaptionService via the API: public interface AdaptionService { <T> void declareAdapter(Resource type, Class<T> targetClass); <T> void declareAdapter(Resource type, Class<T> targetClass, Class<?> contextClass); <T> void addAdapter(Resource type, Class<T> targetClass, Adapter<T, ?> adapter); <T> void addAdapter(Resource type, Class<T> targetClass, Class<?> contextClass, Adapter<T, ?> adapter); <T> void addInstanceAdapter(Resource resource, Class<T> targetClass, Adapter<T, ?> adapter); <T> void addInstanceAdapter(Resource resource, Class<T> targetClass, Class<?> contextClass, Adapter<T, ?> adapter);
This should shave the time consumption of adaption service initialization from 1-2 seconds to hopefully less than 200ms which in turn removes plenty of wasted time from each platform initialization.
Edited by Tuukka Lehtonen