[jira] [Resolved] (UIMA-1249) CasManager_impl logic for lazy merge of the type system could lead to excessive work or missed errors

["Marshall Schor (JIRA)" <de...@uima.apache.org>]

     [ 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)