Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
2.3
-
None
-
None
Description
The CasManager_impl class is sometimes (mostly?) (but not always) used when assembling a pipeline of UIMA components.
There is one instance of this associated with each Resource Manager instance. (PearWrapper versions of the ResourceManager share this component).
It has 2 phases. At "initialization", its method addMetaData is repeatedly called as a part of the initialization phase of components being assembled to run under one ResourceManager instance, to collect all the metadata from the components (e.g., their individual type systems, type priorities, and index definitions).
At the first call that requires the merged result, e.g. getCasDefinition(), the class merges all the collected metadata and uses it to produce the CAS's type system, indexes, etc.
After this first call, additional calls to addMetaData which attempt to add new things not already in the merge, should result in an error.
In the current implementation, the call to addMetaData in this case not only won't result in any error, but it will reset the class instance, so that a subsequent call to get the CAS definition will result in merging being again called, and a new, non-identical merged result will be returned. This could result in CASes in a pool, for instance, having different type systems.
Normally, this sequence will never happen; however, in the multi-threaded case, where initialization and processing could occur at the same time across multiple instances, it could happen that addMetaData could be called by a thread still initializing, while another thread has already obtained the "final" merged CAS definition. In these cases, the addMetaData call could be "ignored", but in the general case, one would need to check to see if the metaData being added would change the existing type system, and throw an error if it did.
