uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Updated: (UIMA-1249) CasManager_impl logic for lazy merge of the type system could lead to excessive work or missed errors
Date Fri, 02 Oct 2009 20:24:23 GMT

     [ https://issues.apache.org/jira/browse/UIMA-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Marshall Schor updated UIMA-1249:

    Affects Version/s:     (was: 2.2.2)

defer past 2.3.0

> 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
>            Priority: Minor
> 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 is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message