[
https://issues.apache.org/jira/browse/UIMA-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-1249.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.6.0SDK
Assignee: Marshall Schor
> CasManager_impl logic for lazy merge of the type system could lead to
> excessive work or missed errors
> -----------------------------------------------------------------------------------------------------
>
> Key: UIMA-1249
> URL: https://issues.apache.org/jira/browse/UIMA-1249
> Project: UIMA
> Issue Type: Improvement
> Affects Versions: 2.3
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 2.6.0SDK
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
